grub defaults to configuring the rootfs to be initially mounted RO, and openrc and systemd remount the rootfs to RW early during boot process. This is on two machines 1) desktop using uefi, gpt partitions and systemd 2) headless using bios (old MB), gpt partitions and openrc openrc rc.log snippet: * Remounting root filesystem read/write ... mount: /: cannot remount /dev/sda5 read-write, is write-protected. dmesg(1) may have more information after failed mount system call. * Root filesystem could not be mounted read/write [ !! ] * Remounting filesystems ... mount: /: cannot remount /dev/sda5 read-write, is write-protected. dmesg(1) may have more information after failed mount system call. [ ok ] * Updating /etc/mtab ... * /etc is not writable; unable to create /etc/mtab [ !! ] dmesg snippet: [ 9.193440] EXT4-fs warning (device sda5): ext4_enable_quotas:6997: Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck to fix. dmesg (from an earlier boot, in "recovery" mode, and manual remount): [ 80.473545] sda5: Can't mount, would change RO state for this earlier boot, "fsck.ext4 -f /dev/sda5" was run in the recovery shell (-f force as the filesystem was marked clean) however fsck.ext4 reported the filesystem clean in all stages then "mount -o remount,rw /" was run which gave rise to the dmesg output above about changing RO state. systemd snippet: Jun 06 15:34:09 binah kernel: EXT4-fs warning (device sda5): ext4_enable_quotas:6997: Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck to fix. Jun 06 15:34:09 binah systemd-remount-fs[241]: mount: /: cannot remount /dev/sda5 read-write, is write-protected. Jun 06 15:34:09 binah systemd-remount-fs[241]: dmesg(1) may have more information after failed mount system call. Jun 06 15:34:09 binah systemd-remount-fs[239]: /bin/mount for / exited with exit status 32 Jun 06 15:34:09 binah systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE Jun 06 15:34:09 binah systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'. Jun 06 15:34:09 binah systemd[1]: Failed to start systemd-remount-fs.service This systemd machine is unusable with rootfs still mounted RO as other units fail to start properly leaving among other things the network interface without ip addresses and so unable to support logins due to non-reachability of ldap. As there are no existing bugs already filed I'm assuming journaled quotas are causing this issue (the only system I have with traditional quota files ( aquota.{group,user} ) is x86 and so 6.1.31 wasn't stabilised). Rebooting the two machines and selecting the previous 6.1.28 kernel, they both booted fine and without dmesg errors regarding the ext4 quotas. The new 6.1.31 kernels were built using the ".config" copied from the 6.1.28 kernel source trees (on each respective machine). Reproducible: Always
I took a very quick look and saw https://lore.kernel.org/all/647DEC75.7080300@huawei.com/, not sure if that's it.
forgot fstab line and filesystem features: # ROOTFS PARTUUID=<UUID> / ext4 noatime,user_xattr,acl,usrquota,grpquota 0 1 # tune2fs -l /dev/sda5 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg encrypt sparse_super large_file huge_file dir_nlink extra_isize quota metadata_csum Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean these are identical between the openrc and systemd machines (well the actual PARTUUID is different)
(In reply to Bill Prendergast from comment #2) > forgot fstab line and filesystem features: > > # ROOTFS > PARTUUID=<UUID> / ext4 noatime,user_xattr,acl,usrquota,grpquota 0 1 > > > # tune2fs -l /dev/sda5 > Filesystem features: has_journal ext_attr resize_inode dir_index filetype > needs_recovery extent 64bit flex_bg encrypt sparse_super large_file > huge_file dir_nlink extra_isize quota metadata_csum > > Filesystem flags: signed_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean > > these are identical between the openrc and systemd machines (well the actual > PARTUUID is different) Can you do a bisect between the last working kernel and the first non-working kernel ?
