From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 To: make-initrd@lists.altlinux.org References: <20190426123558.GM9023@dhcp129-178.brq.redhat.com> <0e3a3ef2-8637-4ca4-1e95-a5c39841996f@complife.ru> <20190429121835.GV9023@dhcp129-178.brq.redhat.com> <20190429144901.GW9023@dhcp129-178.brq.redhat.com> From: "Michael A. Kangin" Message-ID: Date: Mon, 29 Apr 2019 17:39:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190429144901.GW9023@dhcp129-178.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru-RU Content-Transfer-Encoding: 8bit Subject: Re: [make-initrd] master updated X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 15:39:23 -0000 Archived-At: List-Archive: On 04/29/2019 04:49 PM, Alexey Gladkov wrote: >>> root=/dev/nfs это не моё изобретение: >>> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 >> >> Я просто задумался, если NFS (и другие фичи) рассматривать и как >> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи >> наверное есть :) > > В каком смысле чей будет ? Мм, мне трудновато с непривычки выразиться корректно и понятно :) Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут и использовать друг-друга в качестве промежуточного транспорта - как они договорятся, которая из них будет обрабатывать параметр root=? Ну вот допустим есть некая фича "squash-boot", которая использует nfsroot как транспорт. Мы говорим root=/dev/nfs, чтобы у нас nfs вообще заработало. Тогда этой squash-boot мы должны дать какой-то другой параметр вместо root= ? Хорошо, допустим мы ей будем давать squash-root= А в ситуации, когда "squash-boot" будет пользоваться как транспортом http или iSCSI - мы вообще без root= останемся? Или разделить нынешнюю nfsroot на транспортную фичу, которая будет хотеть nfsroot= и непосредственно монтировочную (как бы назвать такую финальную фичу - которая предоставляет подготовленный /root), которая будет активироваться root=/dev/nfs? т.е. например если мы скажем nfsroot=192.168.0.1:/nfsshare/mysystem root=/dev/nfs то, как сейчас, 192.168.0.1:/nfsshare/mysystem смонтируется на /root а если nfsroot=192.168.0.1:/nfsshare/images root=nfs:/image1.squash тогда 192.168.0.1:/nfsshare/images должно быть смонтировано куда-то не в /root, а дальше пусть разбирается "squash-boot" со своим параметром root=, который она поймёт как процессить Кстати, в каком объёме нужна будет поддержка NFS? tcp/udp? v. 3 / 4? kerberos? >> Если закомментить упоминания syslog: > А куда у тебя логи идут в этом случае ? Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. Cейчас с сетью, мне кажется нужно думать за ремотные сислоги. Вот, говорят, busybox'ный syslog вроде как умеет отсылать: https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging И у меня есть смутная идея - возможно удалось бы экспортировать по сети /dev/log какой-нибудь хитрой магией netcat/socat