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
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 mikro001@gmail.com 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
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 devo8604@gmail.com 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 mikro001@gmail.com 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
P.s.: link to the mailing list thread about the mentioned discussion: http://article.gmane.org/gmane.comp.file-systems.btrfs/52312
On 20 January 2016 at 21:01, Garmine 42 mikro001@gmail.com 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.
On 20 January 2016 at 20:56, Devon Smith devo8604@gmail.com 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 mikro001@gmail.com 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,
Im not sure why you would mask the remount service. He has the space_cache option specified in his /etc/fstab. From what the mailing list states (as Garmine put it), BTRFS is not mounted with this option at boot by default and when the filesystem is remounted to rw, it will not accept the space_cache parameter for some reason when it remounts. I can't get to the mailing list right now to read the whole thing, the site is blocked here at work.
Cheers from Colorado Springs by the way, I see you are in Boulder.
Devon
On Wed, Jan 20, 2016 at 1:18 PM, Leonid Isaev leonid.isaev@jila.colorado.edu 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) ^^^^^^^^^^^
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 leonid.isaev@jila.colorado.edu 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
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 mikro001@gmail.com wrote:
On 20 January 2016 at 21:18, Leonid Isaev leonid.isaev@jila.colorado.edu 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 devo8604@gmail.com 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 mikro001@gmail.com wrote:
On 20 January 2016 at 21:18, Leonid Isaev leonid.isaev@jila.colorado.edu 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
(Yes, I use grub2.) Actually, grub-mkconfig is just a bunch of scripts, I should be able to grep and cut fstab and generate rootflags from that, shouldn't I? :)
Is the cmdline size still limited to 255 characters?
On 20 January 2016 at 21:48, Garmine 42 mikro001@gmail.com 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 devo8604@gmail.com 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 mikro001@gmail.com wrote:
On 20 January 2016 at 21:18, Leonid Isaev leonid.isaev@jila.colorado.edu 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 mikro001@gmail.com 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 devo8604@gmail.com 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 mikro001@gmail.com wrote:
On 20 January 2016 at 21:18, Leonid Isaev leonid.isaev@jila.colorado.edu 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
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"
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 admin@progandy.de 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"
arch-general@lists.archlinux.org