On Fri, Feb 28, 2025 at 5:33 PM Alex Kiernan <alex.kier...@gmail.com> wrote: > > On Fri, Feb 28, 2025 at 3:57 PM Alexis CELLIER <alexis.cell...@smile.fr> > wrote: > > > > 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. > > > > firstboot usage, really doesn't feel like a piece of package > configuration to me, possibly distro config, but having a > (potentially) interactive boot seems like an outlier in the OE world > (though I'm not saying it shouldn't be supported).
It is already a PACKAGECONFIG of systemd, not enabled by default (not sure it was clear in my previous message). > Today we call the systemctl script as part of rootfs construction > which may touch /etc/machine-id, removing it from there and having it > obviously in one place as part of rootfs construction seems like it > ought to be an improvement. I do agree. I do have a question, it is possible to not end up with the /etc/machine-id file, i.e. not having the python script called (on master)? If it is not possible, it means there is now way to have the first boot mechanism working (without tweaks), and so there is no risk to create an empty file in all cases (if the file does not exist, to avoid breaking builds that were embedding it in some way) no? And then we could move the discussion about the first boot support (empty or "uninitalized") in another thread as it is not the point of this patch (and avoid blocking it)? But if it is possible, no idea. Break the support but add documentation, a new image feature, or a distro feature (so systemd PACKAGECONFIG could adapt its default value)? > > > 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 > > > > -- > Alex Kiernan Regards, -- Alexis Cellier Smile ECS Developer
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#212073): https://lists.openembedded.org/g/openembedded-core/message/212073 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] -=-=-=-=-=-=-=-=-=-=-=-
