On Fri, 2 Aug 2019 at 21:20, Ryan Harkin <ryan.har...@linaro.org> wrote:
> Hi Carsten, > > Thanks for your help. > > On Fri, 2 Aug 2019 at 20:42, Stelling2 Carsten < > carsten.stelli...@goerlitz.com> wrote: > >> Hi Ryan, >> >> >> >> Regarding to timesyncd, have a look at >> https://wiki.archlinux.org/index.php/systemd-timesyncd, especially the >> section >> >> “Note: The service writes to a local file /var/lib/systemd/timesync/clock >> with every synchronization. >> >> This location is hard-coded and cannot be changed. This may be >> problematic for running off >> >> read-only root partition or trying to minimize writes to an SD card.” >> > > Yes, this looks like it is my problem. I experimented with timesync, and > by making /var/lib and a few other places writable, I'm able to start it > manually, but not via systemd, which I think is experiencing other issues > with the read-only rootfs. > > >> >> See also https://github.com/systemd/systemd/issues/5610 for your problem >> with systemd-resolved. >> >> According to this, /var, /var/tmp, /run, and /tmp should be writable. >> > I think the problem is not Yocto specific, but possibly I overlook >> something. >> > > Again, I think you're right. I need to have these areas writable from > boot. But I don't know how. > > I suppose my problem is that these areas used to be writable when I was > using Sumo, but moving to Warrior has caused something to change. I'm > wondering what extra steps I need to do in Warrior to ensure that all these > things are mounted with tmpfs as before. I expect my Sumo recipes worked > through luck more than design, and now something has changed, I need to > improve them. > > It is rather difficult to work out what the relevant changes are. > I still don't know what has changed between Sumo and Warrior so it works on Sumo, but not on Warrior. However, I tried a different board (WaRP7) with Warrior, and read-only works as expected. I tried removing the read-only flag from my malfunctioning board setup, and I still have the problems. Of course, the quirky system I'm fixing boots in a more complex way that WaRP7. There is a service that boots at startup, with a script to switch-root from initramfs to an UBI partition. The UBI partition is being mounted read-only in the switch-root script. If I change this to read-write, everything works. I think one fix for me is to have my script manually mount /tmp, /var/volatile, and so on, as tmpfs. It doesn't explain what's changed, however. Either way, the fault appears to be in my environment, and Sumo possibly worked with luck. Regards, Ryan. > Kind regards, > Ryan. > > >> >> Best regards, >> >> >> >> Carsten >> >> >> >> *Von:* yocto-boun...@yoctoproject.org [mailto: >> yocto-boun...@yoctoproject.org] *Im Auftrag von *Ryan Harkin >> *Gesendet:* Freitag, 2. August 2019 13:09 >> *An:* yocto@yoctoproject.org >> *Cc:* openembedded >> *Betreff:* [yocto] /var/volatile not mounted as tmpfs on read-only >> rootfs when migrating to Warrior >> >> >> >> Hi, >> >> >> >> I have a working system based on Sumo. The system boots with a read-only >> rootfs, then applies are read-write overlay for /etc. >> >> >> >> When I migrate to Warrior, systemd-resolved fails to start. If I mount >> the same rootfs via NFS, it starts and works fine. systemd-timesyncd is >> also failing, but I haven't looked into that yet. It also works fine on the >> NFS mounted system. >> >> >> >> The resolve problem seems to be caused by two things: >> >> - /var/volatile is read-only >> >> - /run/systemd/resolve has the wrong ownership >> >> drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23 >> resolve/ >> >> I think this permissions problem may be a result of the >> /var/volatile mounting >> >> problems; it looks fine on the NFS mounted system. >> >> >> >> If I manually mount /var/volatile (it's in fstab) and change the >> ownership on /run/systemd/resolve, the service starts just fine. >> >> >> >> I also notice that /tmp is not mounted at all, which may be related. >> >> >> >> Here are the various tmp mount points on my read-only rootfs: >> >> >> >> $ mount | grep tmp >> >> devtmpfs on /dev type devtmpfs >> (rw,nosuid,size=112036k,nr_inodes=28009,mode=755) >> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) >> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) >> tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) >> overlay on /etc type overlay >> (rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc) >> tmpfs on /run/user/0 type tmpfs >> (rw,nosuid,nodev,relatime,size=23840k,mode=700) >> >> On the NFS mounted system, I see these: >> >> >> >> $ mount | grep tmp >> devtmpfs on /dev type devtmpfs >> (rw,relatime,size=118180k,nr_inodes=29545,mode=755) >> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) >> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) >> tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) >> tmpfs on /tmp type tmpfs (rw,nosuid,nodev) >> tmpfs on /var/volatile type tmpfs (rw,relatime) >> tmpfs on /run/user/0 type tmpfs >> (rw,nosuid,nodev,relatime,size=23840k,mode=700) >> >> As you can see, NFS has these extra mounts: >> >> >> >> tmpfs on /tmp type tmpfs (rw,nosuid,nodev) >> >> tmpfs on /var/volatile type tmpfs (rw,relatime) >> >> >> >> I've tried reverting a few commits that may be related, but I haven't had >> any luck working out things have changed, eg: >> >> >> >> c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available >> [Matt Hoosier] >> >> >> >> Advice would be appreciated. Are there any particular areas I should be >> looking to work out what's going wrong? >> >> >> >> Kind regards, >> >> Ryan. >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto