* [make-initrd] master updated
@ 2019-04-26 12:35 Alexey Gladkov
2019-04-29 11:02 ` Michael A. Kangin
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-26 12:35 UTC (permalink / raw)
To: make-initrd
Привет!
Я обновил master.
* Вернул из make-initrd-1x возможность запустить скрипты до и после
сервисов.
* Вернул потерянную возможность вызвать скрипт перед предзагружаемыми
модулями.
* DHCPv6-клиент учитывает ipv6.disable и ipv6.disable_ipv6 и не пытается
запуститься.
* Линк и маршруты настраиваются.
* В resolv.conf только уникальные значения.
* В route= имя интерфейса обязательно.
* Добавлен ifname= параметр для переименования интерфейсов.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-26 12:35 [make-initrd] master updated Alexey Gladkov
@ 2019-04-29 11:02 ` Michael A. Kangin
2019-04-29 12:18 ` Alexey Gladkov
0 siblings, 1 reply; 13+ messages in thread
From: Michael A. Kangin @ 2019-04-29 11:02 UTC (permalink / raw)
To: make-initrd
On 04/26/2019 02:35 PM, Alexey Gladkov wrote:
> Я обновил master.
Замечательно! Всё прям работает, даже почти не придраться :)
>
> * Вернул из make-initrd-1x возможность запустить скрипты до и после
> сервисов.
Хотел уточнить:
> Скрипты из директории /lib/initrd/all вызываются перед и после каждого
> сервиса.
> Все скрипты вызываются с аргументами {start|stop} <servicename> [retcode]
Из этой директории, насколько я понял, они вызываются перед стартом
каждого сервиса, и непосредственно после старта сервиса, и во втором
случае им еще передаётся третьим параметром retcode. Я правильно понял?
Вызываются ли они (из /all/ ) еще при остановке сервисов? (я не знаю как
протестировать сценарий остановки сервисов, если просто сказать
/etc/init.d/service stop, этого недостаточно).
> * В route= имя интерфейса обязательно.
Насколько я понял, сейчас все три параметра обязательно? сеть, шлюз,
интерфейс.
Когда я пытаюсь нарисовать link-маршрут route=172.16.0.0/12::eth2, он не
применяется.
> Изменил обработку macaddr в ip. Теперь MAC меняется у интерфейса, а не
> переименовывает интерфейс. Это совпадает с поведением в fedora;
Но запрос на DHCP приходит со старого мака. И адрес выдаётся
соответственно для старого. Интересно будет посмотреть событие
обновление лизы, как бы посреди работы новый IP не схватила.
>
> Если считать, что утилита nfsroot работает, то используя фичу nfsroot ты
> получишь просто корень по NFS.
Вот интересно, с этими последними релизами из master она хоть
запускаться пытается (при указании заклинания root=/dev/nfs, кстати
зачем, nfsroot не хватило бы?)
Но таки не работает, ошибки из логов:
/var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Running
nfsroot handler ...
/var/log/ueventd.log:/lib/uevent/handlers/040-nfsroot: line 7:
/tmp/net-eth1.conf: No such file or directory
/var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Event handler
failed: nfsroot
И напоминаю, фича dropbear тоже сломана, сислога хочет.
--
Michael A. Kangin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 11:02 ` Michael A. Kangin
@ 2019-04-29 12:18 ` Alexey Gladkov
2019-04-29 14:37 ` Michael A. Kangin
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-29 12:18 UTC (permalink / raw)
To: make-initrd
On Mon, Apr 29, 2019 at 01:02:36PM +0200, Michael A. Kangin wrote:
> On 04/26/2019 02:35 PM, Alexey Gladkov wrote:
>
> > Я обновил master.
>
> Замечательно! Всё прям работает, даже почти не придраться :)
За это нужно вас всех в этой рассылке благодарить ))
> > * Вернул из make-initrd-1x возможность запустить скрипты до и после
> > сервисов.
>
> Хотел уточнить:
> > Скрипты из директории /lib/initrd/all вызываются перед и после каждого
> > сервиса.
> > Все скрипты вызываются с аргументами {start|stop} <servicename> [retcode]
>
> Из этой директории, насколько я понял, они вызываются перед стартом
> каждого сервиса, и непосредственно после старта сервиса, и во втором
> случае им еще передаётся третьим параметром retcode. Я правильно понял?
Именно.
> Вызываются ли они (из /all/ ) еще при остановке сервисов? (я не знаю как
> протестировать сценарий остановки сервисов, если просто сказать
> /etc/init.d/service stop, этого недостаточно).
Для остановки сервисов тоже вызываются. Для этого там первый параметр
{start|stop} передаётся.
Чтобы это проверить дайте начать загрузиться реальной системе. Когда
корень найден, то система переходит на runlevel 2 и сервисы
останавливаются.
> > * В route= имя интерфейса обязательно.
>
> Насколько я понял, сейчас все три параметра обязательно? сеть, шлюз,
> интерфейс.
> Когда я пытаюсь нарисовать link-маршрут route=172.16.0.0/12::eth2, он не
> применяется.
В логах что-нибудь есть ? ip-route выполняется ?
Я посмотрю.
> > Изменил обработку macaddr в ip. Теперь MAC меняется у интерфейса, а не
> > переименовывает интерфейс. Это совпадает с поведением в fedora;
>
> Но запрос на DHCP приходит со старого мака. И адрес выдаётся
> соответственно для старого. Интересно будет посмотреть событие
> обновление лизы, как бы посреди работы новый IP не схватила.
Хм. Это правда. В случае, когда меняется и mac и используется dhcp, то mac
будет изменён после работы dhcp. Это же касается mtu. Собственно все
параметры будут применяться после dhcp.
Нужно подумать.
> > Если считать, что утилита nfsroot работает, то используя фичу nfsroot ты
> > получишь просто корень по NFS.
>
> Вот интересно, с этими последними релизами из master она хоть
> запускаться пытается (при указании заклинания root=/dev/nfs, кстати
> зачем, nfsroot не хватило бы?)
root=/dev/nfs это не моё изобретение:
https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46
> Но таки не работает, ошибки из логов:
> /var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Running
> nfsroot handler ...
> /var/log/ueventd.log:/lib/uevent/handlers/040-nfsroot: line 7:
> /tmp/net-eth1.conf: No such file or directory
> /var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Event handler
> failed: nfsroot
Да, я помню. Эту нужно чинить и писать новую nfs.
> И напоминаю, фича dropbear тоже сломана, сислога хочет.
Угу. Видимо добавлю из busybox, хотя не очень хочется.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 12:18 ` Alexey Gladkov
@ 2019-04-29 14:37 ` Michael A. Kangin
2019-04-29 14:49 ` Alexey Gladkov
0 siblings, 1 reply; 13+ messages in thread
From: Michael A. Kangin @ 2019-04-29 14:37 UTC (permalink / raw)
To: make-initrd
On 04/29/2019 02:18 PM, Alexey Gladkov wrote:
> В логах что-нибудь есть ? ip-route выполняется ?
[2019-04-29 13:47:36] 040-network: eth1: process event: network.route.update
[2019-04-29 13:47:36] route: eth1: run: ip -4 route append default via
192.168.222.1
[2019-04-29 13:47:36] route: eth1: run: ip -4 route append 172.16.0.0/12
ip: RTNETLINK answers: No such device
[2019-04-29 13:47:36] route: eth1: create event: network.route.update ->
network.route.updated
/.initrd/initenv:export
CMDLINE="ip=192.168.222.25::192.168.222.1:25:myhost:eth1:none
route=172.16.0.0/12::eth1 nameserver=98.158.111.2
nameserver=[fd00:eeee:2::1] debug rd-depmod=y rdshell rootdelay=5"
/.initrd/initenv:export ROUTE0="172.16.0.0/12::eth1"
/.initrd/initenv:export route="172.16.0.0/12::eth1"
/.initrd/kernenv:route="172.16.0.0/12::eth1"
кстати: еще в логах постоянно мелькает такая запись:
[2019-04-29 14:22:27] addr: lo: run: ip -4 address add dev lo 127.0.0.1/8
ip: RTNETLINK answers: File exists
вроде вреда особого нету...
еще кстати:
If you are here that something went wrong. If so, it's important to
remember:
...
- /var/log/uevent.log -- contains log of the execution of handlers.
Он /var/log/uevent*d*.log
- /var/log/udhcp{4|6}.<iface>.log -- contains DHCP logs.
Оне /var/log/udhcp*с*...
> root=/dev/nfs это не моё изобретение:
> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46
Я просто задумался, если NFS (и другие фичи) рассматривать и как
транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи
наверное есть :)
>> И напоминаю, фича dropbear тоже сломана, сислога хочет.
> Угу. Видимо добавлю из busybox, хотя не очень хочется.
В принципе, сам dropbear прекрасно сейчас и без него работает (из
дополнительного debug.cpio)
Если закомментить упоминания syslog:
features/dropbear/data/etc/rc.d/init.d/dropbear:
-# Required-Start: $syslog localnet
+# Required-Start: udev
features/dropbear/rules.mk:
-$(call require,syslog)
то initrd собирается, dropbear упаковывается нормально, в рантайме
запускается, host-ключи генерит.
Впрочем, для того, чтобы действительно приконнектиться, нужно еще решить
вопрос с ключом или паролем для root, а так же монтировать в рантайме
/dev/pts
Вот тогда действительно коннектится :)
мне кажется, при сборке стоит подумать о вопросах:
- добавления паблик-ключа в /home/root/.ssh/authorized_keys
- возможность класть свои host-ключи (сейчас они генерятся каждый раз
заново при старте системы, не вижу в этом большого профита, только с
known_hosts лишняя возня)
- как класть дропбировский scp
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 14:37 ` Michael A. Kangin
@ 2019-04-29 14:49 ` Alexey Gladkov
2019-04-29 15:39 ` Michael A. Kangin
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-29 14:49 UTC (permalink / raw)
To: make-initrd
On Mon, Apr 29, 2019 at 04:37:58PM +0200, Michael A. Kangin wrote:
> On 04/29/2019 02:18 PM, Alexey Gladkov wrote:
>
> > В логах что-нибудь есть ? ip-route выполняется ?
>
> [2019-04-29 13:47:36] 040-network: eth1: process event: network.route.update
> [2019-04-29 13:47:36] route: eth1: run: ip -4 route append default via
> 192.168.222.1
> [2019-04-29 13:47:36] route: eth1: run: ip -4 route append 172.16.0.0/12
> ip: RTNETLINK answers: No such device
Спасибо. Так яснее.
> [2019-04-29 13:47:36] route: eth1: create event: network.route.update ->
> network.route.updated
>
> /.initrd/initenv:export
> CMDLINE="ip=192.168.222.25::192.168.222.1:25:myhost:eth1:none
> route=172.16.0.0/12::eth1 nameserver=98.158.111.2
> nameserver=[fd00:eeee:2::1] debug rd-depmod=y rdshell rootdelay=5"
> /.initrd/initenv:export ROUTE0="172.16.0.0/12::eth1"
> /.initrd/initenv:export route="172.16.0.0/12::eth1"
> /.initrd/kernenv:route="172.16.0.0/12::eth1"
Спасибо. Проверю.
> кстати: еще в логах постоянно мелькает такая запись:
> [2019-04-29 14:22:27] addr: lo: run: ip -4 address add dev lo 127.0.0.1/8
> ip: RTNETLINK answers: File exists
Я видел. Да, это не страшно.
> еще кстати:
> If you are here that something went wrong. If so, it's important to
> remember:
> ...
> - /var/log/uevent.log -- contains log of the execution of handlers.
>
> Он /var/log/uevent*d*.log
>
Исправлю.
> - /var/log/udhcp{4|6}.<iface>.log -- contains DHCP logs.
>
> Оне /var/log/udhcp*с*...
А это вообще нужно придумать как вынести в фичу.
> > root=/dev/nfs это не моё изобретение:
> > https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46
>
> Я просто задумался, если NFS (и другие фичи) рассматривать и как
> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи
> наверное есть :)
В каком смысле чей будет ?
> >> И напоминаю, фича dropbear тоже сломана, сислога хочет.
> > Угу. Видимо добавлю из busybox, хотя не очень хочется.
>
> В принципе, сам dropbear прекрасно сейчас и без него работает (из
> дополнительного debug.cpio)
>
> Если закомментить упоминания syslog:
А куда у тебя логи идут в этом случае ?
> Впрочем, для того, чтобы действительно приконнектиться, нужно еще решить
> вопрос с ключом или паролем для root, а так же монтировать в рантайме
> /dev/pts
В сервисе dropbear нужно проверять и монтировать его.
> мне кажется, при сборке стоит подумать о вопросах:
> - добавления паблик-ключа в /home/root/.ssh/authorized_keys
Хорошая мысль.
> - возможность класть свои host-ключи (сейчас они генерятся каждый раз
> заново при старте системы, не вижу в этом большого профита, только с
> known_hosts лишняя возня)
Угу
> - как класть дропбировский scp
Можно.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 14:49 ` Alexey Gladkov
@ 2019-04-29 15:39 ` Michael A. Kangin
2019-04-29 15:53 ` Leonid Krivoshein
2019-04-29 16:26 ` Alexey Gladkov
0 siblings, 2 replies; 13+ messages in thread
From: Michael A. Kangin @ 2019-04-29 15:39 UTC (permalink / raw)
To: make-initrd
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 15:39 ` Michael A. Kangin
@ 2019-04-29 15:53 ` Leonid Krivoshein
2019-04-29 21:08 ` Alexey Gladkov
2019-04-29 16:26 ` Alexey Gladkov
1 sibling, 1 reply; 13+ messages in thread
From: Leonid Krivoshein @ 2019-04-29 15:53 UTC (permalink / raw)
To: make-initrd
29.04.2019 18:39, Michael A. Kangin пишет:
> 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=?
>
По цепочке все фичи парсят /proc/cmdline, в результате что-то
оказывается в глобальной $INITRD_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=, который она поймёт как процессить
>
И такой тоже. Что-то вроде этого напрашивается:
root=nfs:server:/nfsshare/images;squash:livecd
>
> Кстати, в каком объёме нужна будет поддержка 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
>
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 15:39 ` Michael A. Kangin
2019-04-29 15:53 ` Leonid Krivoshein
@ 2019-04-29 16:26 ` Alexey Gladkov
2019-04-29 16:42 ` Michael A. Kangin
1 sibling, 1 reply; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-29 16:26 UTC (permalink / raw)
To: make-initrd
On Mon, Apr 29, 2019 at 05:39:20PM +0200, Michael A. Kangin wrote:
> > В каком смысле чей будет ?
>
> Мм, мне трудновато с непривычки выразиться корректно и понятно :)
>
> Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут и
> использовать друг-друга в качестве промежуточного транспорта - как они
> договорятся, которая из них будет обрабатывать параметр root=?
Такой ситуации не бывает.
Каждый транспорт ждёт необходимых параметров и если они предоставлены, то
согласно им монтирует нечто в указанный каталог. Так продолжается пока не
будет выполнено условие, после которого система считается готовой.
Сейчас для монтирования корня входными параметрами являются эвенты udev.
В новой вселенной этого не достаточно и будет ещё что-то.
> Кстати, в каком объёме нужна будет поддержка NFS?
> tcp/udp? v. 3 / 4? kerberos?
Я пока не знаю.
> >> Если закомментить упоминания syslog:
> > А куда у тебя логи идут в этом случае ?
>
> Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно..
Вот это меня очень смущает. Поэтому там syslog.
> Cейчас с сетью, мне кажется нужно думать за ремотные сислоги.
>
> Вот, говорят, busybox'ный syslog вроде как умеет отсылать:
> https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging
Я это и имел в виду, когда говорил, что можно починить фичу syslog,
включив sysklog в busybox. Правда в этом случае эти утилиты нельзя будет
не класть в образ и фича будет приносить лишь service-файлы, то не очень
мне нравится.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 16:26 ` Alexey Gladkov
@ 2019-04-29 16:42 ` Michael A. Kangin
2019-04-29 17:25 ` Alexey Gladkov
0 siblings, 1 reply; 13+ messages in thread
From: Michael A. Kangin @ 2019-04-29 16:42 UTC (permalink / raw)
To: make-initrd
On 04/29/2019 06:26 PM, Alexey Gladkov wrote:
>>> А куда у тебя логи идут в этом случае ?
>> Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно..
> Вот это меня очень смущает. Поэтому там syslog.
А зачем они вообще могут быть настолько необходимы?
Возможно, еще стоит подумать в сторону:
-E Log to stderr rather than syslog
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 16:42 ` Michael A. Kangin
@ 2019-04-29 17:25 ` Alexey Gladkov
2019-04-29 17:46 ` Michael A. Kangin
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-29 17:25 UTC (permalink / raw)
To: make-initrd
On Mon, Apr 29, 2019 at 06:42:38PM +0200, Michael A. Kangin wrote:
> On 04/29/2019 06:26 PM, Alexey Gladkov wrote:
>
> >>> А куда у тебя логи идут в этом случае ?
> >> Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно..
> > Вот это меня очень смущает. Поэтому там syslog.
>
> А зачем они вообще могут быть настолько необходимы?
Эм. Ну как бы мне иногда хочется знать почему меня не пускает ))
> Возможно, еще стоит подумать в сторону:
> -E Log to stderr rather than syslog
Я уже думал про это.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 17:25 ` Alexey Gladkov
@ 2019-04-29 17:46 ` Michael A. Kangin
2019-04-29 21:05 ` Alexey Gladkov
0 siblings, 1 reply; 13+ messages in thread
From: Michael A. Kangin @ 2019-04-29 17:46 UTC (permalink / raw)
To: make-initrd
On 04/29/2019 07:25 PM, Alexey Gladkov wrote:
>> А зачем они вообще могут быть настолько необходимы?
> Эм. Ну как бы мне иногда хочется знать почему меня не пускает ))
Мне для этого хватило запустить с -EF, сразу всё понятно стало :)
Мож так и гонять в systemd стиле, с nohup, не демонизируя...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 17:46 ` Michael A. Kangin
@ 2019-04-29 21:05 ` Alexey Gladkov
0 siblings, 0 replies; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-29 21:05 UTC (permalink / raw)
To: make-initrd
On Mon, Apr 29, 2019 at 07:46:33PM +0200, Michael A. Kangin wrote:
> On 04/29/2019 07:25 PM, Alexey Gladkov wrote:
>
> >> А зачем они вообще могут быть настолько необходимы?
> > Эм. Ну как бы мне иногда хочется знать почему меня не пускает ))
>
> Мне для этого хватило запустить с -EF, сразу всё понятно стало :)
Это ты, когда уже имеешь доступ ты можешь запустить его так и посмотреть :)
> Мож так и гонять в systemd стиле, с nohup, не демонизируя...
Это один из вариантов.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated
2019-04-29 15:53 ` Leonid Krivoshein
@ 2019-04-29 21:08 ` Alexey Gladkov
0 siblings, 0 replies; 13+ messages in thread
From: Alexey Gladkov @ 2019-04-29 21:08 UTC (permalink / raw)
To: make-initrd
On Mon, Apr 29, 2019 at 06:53:50PM +0300, Leonid Krivoshein wrote:
>
>
> 29.04.2019 18:39, Michael A. Kangin пишет:
> > 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=?
> >
>
> По цепочке все фичи парсят /proc/cmdline, в результате что-то
> оказывается в глобальной $INITRD_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=, который она поймёт как процессить
> >
>
> И такой тоже. Что-то вроде этого напрашивается:
>
> root=nfs:server:/nfsshare/images;squash:livecd
Да, что-то в этом роде. Хотя мне не очень нравится один параметр с кучей
опций вперемешку. Мне бы хотелось разделить их, но не уверен, что это
будет удобно задавать.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-04-29 21:08 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-26 12:35 [make-initrd] master updated Alexey Gladkov
2019-04-29 11:02 ` Michael A. Kangin
2019-04-29 12:18 ` Alexey Gladkov
2019-04-29 14:37 ` Michael A. Kangin
2019-04-29 14:49 ` Alexey Gladkov
2019-04-29 15:39 ` Michael A. Kangin
2019-04-29 15:53 ` Leonid Krivoshein
2019-04-29 21:08 ` Alexey Gladkov
2019-04-29 16:26 ` Alexey Gladkov
2019-04-29 16:42 ` Michael A. Kangin
2019-04-29 17:25 ` Alexey Gladkov
2019-04-29 17:46 ` Michael A. Kangin
2019-04-29 21:05 ` Alexey Gladkov
Make-initrd development discussion
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \
make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com
public-inbox-index make-initrd
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.make-initrd
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git