Hello, When the Mageia 9 Beta 1 is newly installed beside an already installed Mageia 8 installation, and a partition of the Mga 9 beta 1 is inserted in the fstab of the Mageia 8 ( for an automatic mount at Mageia 8 startup ( for example in /media/partMga9), Mageia 8 drop to an emergency prompt. Logs shows that a fsck is launched against the Mageia 9 partition, but fail with an exit code 12 due to the fact the e2fsck in Mageia 8 is in 1.45.6 version and doesn't support "feature C12". Due to that e2fsck advise to upgrade e2fsck to a newer version. When a new version of e2fsprogs ( 1.47 ) is installed, the startup of Mageia 8 looks to be restored. A removal of the offending line in the Mageia 8 fstab, allow the system to start also.
Summary: Adding a Mageia 9 Beta 1 in an Mageia 8 fstab break startup of Mageia 8 => Adding a Mageia 9 Beta 1 partition in ext4 format in an Mageia 8 fstab break startup of Mageia 8
Thank you for this instructive report, which makes it appear that we need to update Mageia 8 e2fsprogs as you nicely demonstrate. e2fsprogs has various committers, so assigning this bug globally.
Assignee: bugsquad => pkg-bugsSource RPM: e2fsprogs => e2fsprogs...mga8Summary: Adding a Mageia 9 Beta 1 partition in ext4 format in an Mageia 8 fstab break startup of Mageia 8 => Mageia 8 cannot mount a Mageia 9 ext4 partition due to the latter having a feature not supported by the former. Resolved by updating M8 e2fsprogs.
We are not going to push 1.47 to mga8
CC: (none) => yves.brungard_mageiaWhiteboard: (none) => IN_ERRATA9
@tmb: a couple words on why not would be nice For an example on why it would be good: for existing portable Mageia 8 systems, i.e persistent Live, to access various disks on host. (at least until mga9 ships, so not a strong point) Better point may be when using portable media formatted on systems using C12
CC: (none) => fri
Per Comment 2: closing as wontfix. If minds change: reopen and edit errata.
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED
Also affects fsarchiver, bug 28791. To note in Mageia 8 Errata and also somewhere regarding live - because they may be used as backup tools. (mention mounting, e2fsck, and fsarchiver)
Whiteboard: IN_ERRATA9 => (none)Summary: Mageia 8 cannot mount a Mageia 9 ext4 partition due to the latter having a feature not supported by the former. Resolved by updating M8 e2fsprogs. => Mageia 8 cannot mount a Mageia 9 ext4 partition due to the latter having a feature not supported by the former.Keywords: (none) => FOR_ERRATA8, IN_ERRATA9
https://wiki.mageia.org/en/Mageia_8_Errata#Various_software
Keywords: FOR_ERRATA8 => IN_ERRATA8
The default file /etc/mke2fs.conf encloses: ext4 = { features = has_journal,extent,huge_file,flex_bg,metadata_csum,metadata_csum_seed,64bit,dir_nlink,extra_isize,orphan_file Could we remove the new default options metadata_csum_seed and orphan_file features ?
It seems that Debian has done it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031622
(In reply to Morgan Leijström from comment #5) > To note in Mageia 8 Errata and also somewhere regarding live - because they > may be used as backup tools. (mention mounting, e2fsck, and fsarchiver) https://wiki.mageia.org/en/Persistent_live_systems#Ext4_option_difference
CC: (none) => mrmazda
Hello, I have pushed a release in testing where these options metadata_csum_seed and orphan_file are removed. e2fsprogs-1.47.0-2.mga9
Source RPM: e2fsprogs...mga8 => e2fsprogs-1.47.0-1.mga9Version: 8 => Cauldron
So new installs using next ISOs (or any netinstall) will be compatible with Mga8 but systems fresh installed from beta2 and earlier netinstalls will have formatted partitions with the C12 feature? (I may misunderstand something, this is not my cup of tea) Currently in errata as https://wiki.mageia.org/en/Mageia_9_Errata#ext4_format_uses_feature_C12_which_are_not_recognized_by_older_fsck (and mentioned in errata 8 and per comment 9) I guess we need a wide agreement on this before eventual pushing
Updated erratas