[systemd-devel] systemd-gpt-auto-generator does not appear to remount rootfs rw

[Lennart Poettering]

On Tue, 23.12.14 16:56, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:

Heya,

> I'm using systemd 218 (stock upstream, unpatched) & dracut 040 (stock
> upstream, unpatched).
> 
> I'm trying to build a basic GPT disk image to boot in a VM with
> gpt-auto-generator discovery of partitions.
> 
> I create three partitions: ESP, swap and rootfs with the following type ids set:
> sgdisk /dev/loop6 --typecode=1:c12a7328-f81f-11d2-ba4b-00a0c93ec93b
> sgdisk /dev/loop6 --typecode=2:0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
> sgdisk /dev/loop6 --typecode=3:4f68bce3-e8cd-4db1-96e7-fbcaf984b709
> 
> In addition to that I clear the no-auto-mount and read-only attributes:
> sgdisk /dev/loop6 --attributes=1:clear:60
> sgdisk /dev/loop6 --attributes=1:clear:63
> sgdisk /dev/loop6 --attributes=3:clear:60
> sgdisk /dev/loop6 --attributes=3:clear:63
> 
> Thus I am expecting for the gpt-auto-generator to work correctly.
> 
> It does boot with and without initramfs, however in such configuration
> the root filesystem (3rd partition in this case) is mounted read-only
> and a few of standard systemd units fail. As per documentation, I had
> the impression that rootfs should be mounted read-write in such
> configuration.
> 
> To mitigated this problem I came up with two workarounds:
> * add "rw" to the kernel cmdline
> * add /etc/fstab with a single entry like this one:
> /dev/gpt-auto-root / none       defaults,rw
> 
> Is this correct additional requirements to get "rw" rootfs? Or is
> there a bug, and either of the workarounds are not required? Or are my
> type ids/attributes set wrongly on the partitions?

Humm, yeah. I remember thinking about this for a long time when I
hacked this up. The way this currently works is that the auto
discovery picks "good" defaults for the read-only flag, depending on
the partition, but allows the kernel cmdline to override it (for the
rootfs), as well as the gpt flag (for /srv and /home).

/home and /srv are hence writable by default, and the rootfs read-only
(simply under the assumption that that would be the better default in
the end). With the gpt partition flag you can make /home and /srv
read-only. And with "rw" on the kernel cmdline you can make /
writable. (Either can be overriden in /etc/fstab also).

Now, I think this behaviour makes some sense, but I am open to
suggestions to change things here if you can make a case. 

This all is admittedly a departure from the kernel's own mount logic
where "ro" is opt-in for the root fs, not opt-out...

Maybe one option would be to upgrade the read-only gpt flag to a
tri-state. Instead of just "read-only" and "not read-only", it could
then be: "read-only", "writable", "default". 

Turning the flag into a tri-state should be easy and be possible in a
compatible way, by just defining a new bit in the flag set.

Would that make sense for you?

Lennart

-- 
Lennart Poettering, Red Hat