[yocto] /var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior

Ryan Harkin ryan.harkin at linaro.org
Fri Aug 9 07:21:14 PDT 2019


On Fri, 2 Aug 2019 at 21:20, Ryan Harkin <ryan.harkin at linaro.org> wrote:

> Hi Carsten,
>
> Thanks for your help.
>
> On Fri, 2 Aug 2019 at 20:42, Stelling2 Carsten <
> Carsten.Stelling2 at 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-bounces at yoctoproject.org [mailto:
>> yocto-bounces at yoctoproject.org] *Im Auftrag von *Ryan Harkin
>> *Gesendet:* Freitag, 2. August 2019 13:09
>> *An:* yocto at 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 at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190809/6e5a1967/attachment.html>


More information about the yocto mailing list