There was a discussion on the linux-btrfs mailing list about this, and for example the btrfs space_cache option can not be changed with a remount - this causes the fstab file's space_cache option to be basically ignored. I want to eliminate this kind of issue on my setup, that's why I need to avoid root being remounted. Instead I want root to be mounted with the options specified in fstab the first (and only) time. On 20 January 2016 at 20:56, Devon Smith wrote:

According to this page: http://www.freedesktop.org/software/systemd/man/systemd-remount-fs.service.h...

The systemd remount service remounts your root file system according to what is listed in fstab. This includes mounting root with the mount options listed therein.

If you need something else, what exactly are you trying to do?

Devon

On Wed, Jan 20, 2016 at 12:16 PM, Garmine 42 wrote:

...

Hi!

My concern is that there are a few mount flags which can not be changed with a remount (at least on some FSes such as btrfs).

Now as far as I understand, the kernel mounts root RO after boot using the root and rootflags parameters. I also found that you can include /etc/fstab in the initrd. How can I convince the kernel to mount every volume including the root according to fstab instead of the kernel paramters?

In case the kernel isn't the one which reads fstab (which I suspect), can I include some binary in the initrd that would read fstab and handle the mounting for me?

Or should I just scrap the whole above idea and write something that'll a) read the root volume's options from fstab and put it on the cmdline through e.g. a grub-mkconfig script?

Thanks in advance!

Regards, Garmine

On Wed, Jan 20, 2016 at 09:01:22PM +0100, Garmine 42 wrote:

There was a discussion on the linux-btrfs mailing list about this, and for example the btrfs space_cache option can not be changed with a remount - this causes the fstab file's space_cache option to be basically ignored. I want to eliminate this kind of issue on my setup, that's why I need to avoid root being remounted. Instead I want root to be mounted with the options specified in fstab the first (and only) time.

Why is it ignored? /dev/sda4 on / type btrfs (ro,nodev,relatime,compress=zlib,ssd,space_cache,autodefrag,subvolid=257,subvol=/_root) ^^^^^^^^^^^ Also, there is fstab in the initramfs: $ lsinitcpio /boot/initramfs-linux.img | grep fstab etc/fstab Have you tried masking the systemd-remount-fs.service? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On 20 January 2016 at 21:18, Leonid Isaev wrote:

On Wed, Jan 20, 2016 at 09:01:22PM +0100, Garmine 42 wrote:

...

There was a discussion on the linux-btrfs mailing list about this, and for example the btrfs space_cache option can not be changed with a remount - this causes the fstab file's space_cache option to be basically ignored. I want to eliminate this kind of issue on my setup, that's why I need to avoid root being remounted. Instead I want root to be mounted with the options specified in fstab the first (and only) time.

Why is it ignored? /dev/sda4 on / type btrfs (ro,nodev,relatime,compress=zlib,ssd,space_cache,autodefrag,subvolid=257,subvol=/_root) ^^^^^^^^^^^

The linux-btrfs discussion suggests that some mount options might be unchanged after a remount even if it should change based on the fstab. Although that particular discussion's exact problem was something else in my opinion, so they might be wrong on that. The fix for that problem was including the problematic option (space_cache=v2) in the rootflags parameter. Considering the cmdline size is limited and I want to avoid modifying that all the time, I want to mount the root volume with the correct flags in the first place.

Also, there is fstab in the initramfs: $ lsinitcpio /boot/initramfs-linux.img | grep fstab etc/fstab

That fstab is an empty file (ran in an uncompreseed initrd): % wc -c etc/fstab 0 etc/fstab

Have you tried masking the systemd-remount-fs.service?

First I will try to exclude root= and rootflags= parameters from the cmdline and include the fstab via mkinitcpio and see if it finds the root. Do I want to mask remount-fs in this case?

Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

I would like to avoid modifying rootflags inside grub config so if I change anything in fstab I don't have to change that in other places as well. Unless grub-mkconfig can somehow be taught to parse fstab and set the rootflags according to it. On 20 January 2016 at 21:43, Devon Smith wrote:

Garmine, If you are using grub2 you should be able to add that option in your grub config, then regenerate it, that will make that option permanent and you wont have to add it every time at boot. Also, if 'ro' is in your kernel params at boot, then im pretty sure masking the remount service will ensure that your root remains mounted ro...

Devon

On Wed, Jan 20, 2016 at 1:34 PM, Garmine 42 wrote:

...

On 20 January 2016 at 21:18, Leonid Isaev wrote:

...

On Wed, Jan 20, 2016 at 09:01:22PM +0100, Garmine 42 wrote:

...

There was a discussion on the linux-btrfs mailing list about this, and for example the btrfs space_cache option can not be changed with a remount - this causes the fstab file's space_cache option to be basically ignored. I want to eliminate this kind of issue on my setup, that's why I need to avoid root being remounted. Instead I want root to be mounted with the options specified in fstab the first (and only) time.

Why is it ignored? /dev/sda4 on / type btrfs (ro,nodev,relatime,compress=zlib,ssd,space_cache,autodefrag,subvolid=257,subvol=/_root) ^^^^^^^^^^^

The linux-btrfs discussion suggests that some mount options might be unchanged after a remount even if it should change based on the fstab.

Although that particular discussion's exact problem was something else in my opinion, so they might be wrong on that. The fix for that problem was including the problematic option (space_cache=v2) in the rootflags parameter. Considering the cmdline size is limited and I want to avoid modifying that all the time, I want to mount the root volume with the correct flags in the first place.

...

Also, there is fstab in the initramfs: $ lsinitcpio /boot/initramfs-linux.img | grep fstab etc/fstab

That fstab is an empty file (ran in an uncompreseed initrd): % wc -c etc/fstab 0 etc/fstab

...

Have you tried masking the systemd-remount-fs.service?

First I will try to exclude root= and rootflags= parameters from the cmdline and include the fstab via mkinitcpio and see if it finds the root. Do I want to mask remount-fs in this case?

...

Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

You shouldn't have to change grub config at all unless you would like to remove that required root flag. You do not need to add all of your mount options as root flags since the remount service will read your fstab and mount the fs accordingly. This instance, where a mount option cannot be applied during a remount, is the only reason I can think of (and also barring any other special circumstances/configurations) that you would need to specify a mount option as a boot parameter. Devon On Wed, Jan 20, 2016 at 1:48 PM, Garmine 42 wrote:

I would like to avoid modifying rootflags inside grub config so if I change anything in fstab I don't have to change that in other places as well. Unless grub-mkconfig can somehow be taught to parse fstab and set the rootflags according to it.

On 20 January 2016 at 21:43, Devon Smith wrote:

...

Garmine, If you are using grub2 you should be able to add that option in your grub config, then regenerate it, that will make that option permanent and you wont have to add it every time at boot. Also, if 'ro' is in your kernel params at boot, then im pretty sure masking the remount service will ensure that your root remains mounted ro...

Devon

On Wed, Jan 20, 2016 at 1:34 PM, Garmine 42 wrote:

...

On 20 January 2016 at 21:18, Leonid Isaev wrote:

...

On Wed, Jan 20, 2016 at 09:01:22PM +0100, Garmine 42 wrote:

...

There was a discussion on the linux-btrfs mailing list about this, and for example the btrfs space_cache option can not be changed with a remount - this causes the fstab file's space_cache option to be basically ignored. I want to eliminate this kind of issue on my setup, that's why I need to avoid root being remounted. Instead I want root to be mounted with the options specified in fstab the first (and only) time.

Why is it ignored? /dev/sda4 on / type btrfs (ro,nodev,relatime,compress=zlib,ssd,space_cache,autodefrag,subvolid=257,subvol=/_root) ^^^^^^^^^^^

The linux-btrfs discussion suggests that some mount options might be unchanged after a remount even if it should change based on the fstab.

Although that particular discussion's exact problem was something else in my opinion, so they might be wrong on that. The fix for that problem was including the problematic option (space_cache=v2) in the rootflags parameter. Considering the cmdline size is limited and I want to avoid modifying that all the time, I want to mount the root volume with the correct flags in the first place.

...

Also, there is fstab in the initramfs: $ lsinitcpio /boot/initramfs-linux.img | grep fstab etc/fstab

That fstab is an empty file (ran in an uncompreseed initrd): % wc -c etc/fstab 0 etc/fstab

...

Have you tried masking the systemd-remount-fs.service?

First I will try to exclude root= and rootflags= parameters from the cmdline and include the fstab via mkinitcpio and see if it finds the root. Do I want to mask remount-fs in this case?

...

Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Hi! I was a bit busy and just got to hacking my mkinitcpio now. I decided to follow ProgAndy's idea and remove the current way of mounting (default_mount_handler function) and instead create and use mount hooks (by default the default_mount_handler and the mount call's nearest lines is a new, enabled hook now). This makes it easier to configure custom mount scenarios, even with exotic configurations such as my /etc on a separate partiton*. Another advantage is that it is compatible with most mkinitcpio features e.g. the breakpoints. Do you think it'd worth to try discussing and submitting my patch to mkinitcpio's maintainers? Thank you all for the help! :) * It is in real a btrfs subvolume and needed in case of a flat subvolume layout so I can easily snapshot only my /etc while experimenting with new configurations. Obviously this is impossible in case of the original mkinitcpio ramdisk because /etc/fstab is not on the root volume. Regards, Garmine On 20 January 2016 at 21:58, ProgAndy wrote:

Am 20.01.2016 um 21:34 schrieb Garmine 42:

...

First I will try to exclude root= and rootflags= parameters from the cmdline and include the fstab via mkinitcpio and see if it finds the root. Do I want to mask remount-fs in this case?

That won't work. You'll have to create a hook for mkinitcpio that implements a custom mount_handler. In the install hook part, read the fstab data, write the necessary stuff to the image and add a runtime hook with add_runscript In the runtime hook, you change the mount_handler

my_mount_handler() { mount ... } mount_handler="my_mount_handler"