Make-initrd development discussion
 help / color / mirror / Atom feed
* [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