On Wed, Feb 26, 2025 at 11:43 AM Vyacheslav Yurkov via lists.openembedded.org <uvv.mail=gmail....@lists.openembedded.org> wrote: > > On 25.02.2025 15:48, Ross Burton wrote: > > On 20 Feb 2025, at 15:33, Vyacheslav Yurkov <uvv.m...@gmail.com> wrote: > >> Isn't is supposed to be created on first boot? > > > > Yes, ish, but our rootfs is read only at this point: > > > > [ 7.639766] systemd[1]: System cannot boot: Missing /etc/machine-id and > > /etc is mounted read-only. > > [ 7.641135] systemd[1]: Booting up is supported only when: > > [ 7.641844] systemd[1]: 1) /etc/machine-id exists and is populated. > > [ 7.642588] systemd[1]: 2) /etc/machine-id exists and is empty. > > [ 7.643279] systemd[1]: 3) /etc/machine-id is missing and /etc is > > writable. > > > > On 20 Feb 2025, at 16:03, Alex Kiernan <alex.kier...@gmail.com> wrote: > >> I do know that it was a horrible thing to get right when I rewrote the > >> shell script in python (which I'm very glad to see the back of): > >> > >> # If we populate the systemd links we also create /etc/machine-id, > >> which > >> # allows systemd to boot with the filesystem read-only before > >> generating > >> # a real value and then committing it back. > >> # > >> # For the stateless configuration, where /etc is generated at runtime > >> # (for example on a tmpfs), this script shouldn't run at all and we > >> # allow systemd to completely populate /etc. > >> > >> It may be that this behaviour was wrong in some cases, but at the same > >> time, I remember spending a lot of time getting this right! > > It certainly looks like it’s “tricky” to get the right semantics here > > because the range of potential use-cases is too great. > > > > I believe we should be writing /etc/machine-id at rootfs time if systemd is > > being used. Currently this is done in the systemctl class if it writes > > links, and then in the rootfs class if the rootfs is read-only. > > > > I think we should consolidate those into the rootfs class, and give the > > user the choice of whether to treat the image as booted or not by writing > > either “” or “uninitialized” to the file as per > > https://www.freedesktop.org/software/systemd/man/latest/machine-id.html#First%20Boot%20Semantics. > > > > tl;dr: if it contains “uninitialized” then this is the first boot, > > otherwise it’s not. By always touching the file we break the ability for > > anyone to use systemd-first-boot or ConditionFirstBoot in their own units, > > which seems wrong. > > > > We’re about a week from feature freeze and getting this merged would be > > great, do you think you can finish this off Slava? > > > > Thanks, > > Ross > > I definitely gonna try. But I might be missing something, because I > thought it sums up as follows: > > RO rootfs -> empty machine-id > RW rootfs -> no machine-id > > And it does work that way when I rebuild my image with or without RO rootfs.
At the moment on master, as systemd-systemctl python script touch the file, we can end up with an empty file independently of the IMAGE_FEATURE read-only-rootfs. So we do break the ability of firstboot in any case. Also, if you boot with your rootfs in ro (KERNEL_ARGS, wic, ...) without setting read-only-rootfs, with fstab that will remount your rootfs in rw (so you do not have a read-only rootfs), not having the /etc/machine-id file will make systemd fail (no not having /etc/machine-id seems dangerous te me). So why not put "uninitialized" in /etc/machine-id all the time (probably in rootfs post commands, if the file does not exist yet, to allow user to put a predefine one), it allows firstboot and prevent the dangerous case of not having the file. The only strange case would be when you do have a read-only filesystem, as you will always have a first boot. But if we do not want that strange behaviour by default, we can empty /etc/machine-id in case of read-only-rootfs (in rootfs post commands), or we let the decision to the user by letting him choose using the systemd PACKAGECONFIG to enable/disable the firstboot support. > Richard, could you please point me out which test actually failed? I > looked at the logs, but most of them were "Skipped". > Does the test explicitly remount rootfs as RO perhaps? > > The other option to have a real machine ID will probably mean to build > machine id and leave it up to a user to decide whether they want to have > such image. But I don't think it's wise to add this option now so it > ends up in the next release. > > Slava Regards, -- Alexis Cellier Smile ECS Developer
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#212069): https://lists.openembedded.org/g/openembedded-core/message/212069 Mute This Topic: https://lists.openembedded.org/mt/111267385/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
