Bug 31109 - Упаковать systemd-firstboot
Summary: Упаковать systemd-firstboot
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: systemd (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-28 08:16 MSK by enp
Modified: 2015-11-05 01:26 MSK (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description enp 2015-06-28 08:16:46 MSK
Прошу упаковать systemd-firstboot
Comment 1 Alexey Shabalin 2015-06-29 14:53:00 MSK
Хорошо, упакую, если беретесь проверить работоспособность (мне сейчас банально некогда).
У меня есть сомнения, что получите то, что ожидаете.
- вывод о первичной загрузке делается по наличию /etc/machine-id, он в свою очередь генерируется на основе /var/lib/dbus/machine-id. Т.е. если /var/lib/dbus/machine-id уже существует, то /etc/machine-id будет генерироваться один и тот же. Кто будет перегенерировать /var/lib/dbus/machine-id я не знаю.
- systemd-firstlogin также задает пароль для root, как это будет происходить для tcb - я не знаю.
Comment 2 enp 2015-06-29 20:21:03 MSK
Проверю, конечно (если к тому времени мне самому не станет некогда :) ). Но я все равно постараюсь.

Вообще вопрос возник в результате прочтения http://www.freedesktop.org/software/systemd/man/timedatectl.html - там при создании образов (средствами mkimage например) рекомендуют использовать именно systemd-firstboot вместо localectl, timedatectl or hostnamectl.

А откуда возникает сам /var/lib/dbus/machine-id?
Comment 3 enp 2015-06-29 20:52:53 MSK
Пишут кстати, что systemd-machine-id-setup(1) tool may be used by installer tools to initialize the machine ID at install time - но не похоже, чтоб это у нас работало.
Comment 4 Alexey Shabalin 2015-06-29 21:14:01 MSK
и /var/lib/dbus/machine-id (с помощью /bin/dbus-uuidgen --ensure)
и /etc/machine-id (с помощью /sbin/systemd-machine-id-setup) 
у нас создаются из %post скриптов rpm.
Поэтому чего-то специального в инсталерах скорее всего нет, и так работает.
А вот когда клонируется виртуалка, или разворачивается из одного тарбола несколько контейнеров, их заново никто не переделывает.
Comment 5 enp 2015-06-30 08:21:53 MSK
(В ответ на комментарий №4)
> и /var/lib/dbus/machine-id (с помощью /bin/dbus-uuidgen --ensure)
> и /etc/machine-id (с помощью /sbin/systemd-machine-id-setup) 
> у нас создаются из %post скриптов rpm.

[root@vbox ~]# cat /var/lib/dbus/machine-id
fb6a5fbb4884f8a4eafcb29f558ec9c5
[root@vbox ~]# rm /var/lib/dbus/machine-id
rm: удалить обычный файл «/var/lib/dbus/machine-id»? y
[root@vbox ~]# /bin/dbus-uuidgen --ensure
[root@vbox ~]# cat /var/lib/dbus/machine-id
fb6a5fbb4884f8a4eafcb29f558ec9c5

Это нормально, что создается тот же UUID?
Comment 6 Alexey Shabalin 2015-06-30 09:29:14 MSK
(В ответ на комментарий №5)
> (В ответ на комментарий №4)
> > и /var/lib/dbus/machine-id (с помощью /bin/dbus-uuidgen --ensure)
> > и /etc/machine-id (с помощью /sbin/systemd-machine-id-setup) 
> > у нас создаются из %post скриптов rpm.
> 
> [root@vbox ~]# cat /var/lib/dbus/machine-id
> fb6a5fbb4884f8a4eafcb29f558ec9c5
> [root@vbox ~]# rm /var/lib/dbus/machine-id
> rm: удалить обычный файл «/var/lib/dbus/machine-id»? y
> [root@vbox ~]# /bin/dbus-uuidgen --ensure
> [root@vbox ~]# cat /var/lib/dbus/machine-id
> fb6a5fbb4884f8a4eafcb29f558ec9c5
> 
> Это нормально, что создается тот же UUID?
надо оба сразу удалить /var/lib/dbus/machine-id и /etc/machine-id
Comment 7 enp 2015-06-30 14:20:39 MSK
> надо оба сразу удалить /var/lib/dbus/machine-id и /etc/machine-id

Ага, но чтобы перегенерить machine-id у свежесозданного контейнера, нужно, получается, сделать chroot в него?
Comment 8 Alexey Shabalin 2015-11-05 01:26:27 MSK
/sbin/systemd-firstboot упакован в systemd-utils