Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot loader to fail (unknown filesystem error) on the x86_64 VM I use for initial testing. I traced the problem to changes in the e2fsprogs configuration file which now sets 64 bit flags. I tried upgrading to GRUB 2.02 but that did not resolve the problem. Reverting the changes per the patch below fixes the problem.
Kernel: 3.16.42, x86_64
Bootloader: GRUB 2.00
Filesystem: Ext4
diff -ruN e2fsprogs-1.43.4/misc/mke2fs.conf.in e2fsprogs-1.43.4-patched/misc/mke2fs.conf.in
--- e2fsprogs-1.43.4/misc/mke2fs.conf.in Wed Feb 1 01:56:32 2017
+++ e2fsprogs-1.43.4-patched/misc/mke2fs.conf.in Sat Jun 3 23:21:39 2017
@@ -11,11 +11,12 @@
features = has_journal
}
ext4 = {
- features = has_journal,extent,huge_file,flex_bg,uninit_bg,64bit,dir_nlink,extra_isize
+ features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
+ auto_64-bit_support = 1
inode_size = 256
}
ext4dev = {
- features = has_journal,extent,huge_file,flex_bg,uninit_bg,inline_data,64bit,dir_nlink,extra_isize
+ features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
options = test_fs=1
}
Regards,
Felipe A. Rodriguez
illumenos LLC
________________________
+grub-devel
On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
> Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
> loader to fail (unknown filesystem error) on the x86_64 VM I use for
> initial testing. I traced the problem to changes in the e2fsprogs
> configuration file which now sets 64 bit flags. I tried upgrading
> to GRUB 2.02 but that did not resolve the problem. Reverting the
> changes per the patch below fixes the problem.
Hmm, my laptop has been using a file system with the 64-bit feature
enabled for quite some time, and my Debian Stretch system has been
using Grub 2.02 to boot my system without any difficulties.
I've done a quick check of the Debian patches and none of them seem to
modify Grub's ext2/ext4 file system implementation. So I don't know
what to tell you. Are you sure you properly reinstalled grub on the
boot device after you upgraded to grub 2.02?
Cheers,
- Ted
Theodore Ts'o <[email protected]> on Fri, 2017/06/23 15:53:
> +grub-devel
>
> On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
> > Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
> > loader to fail (unknown filesystem error) on the x86_64 VM I use for
> > initial testing. I traced the problem to changes in the e2fsprogs
> > configuration file which now sets 64 bit flags. I tried upgrading
> > to GRUB 2.02 but that did not resolve the problem. Reverting the
> > changes per the patch below fixes the problem.
>
> Hmm, my laptop has been using a file system with the 64-bit feature
> enabled for quite some time, and my Debian Stretch system has been
> using Grub 2.02 to boot my system without any difficulties.
>
> I've done a quick check of the Debian patches and none of them seem to
> modify Grub's ext2/ext4 file system implementation. So I don't know
> what to tell you. Are you sure you properly reinstalled grub on the
> boot device after you upgraded to grub 2.02?
Grub should be fine, however syslinux still suffers issues with 64-bit
feature. Possibly you use a chain to load syslinux first, grub second?
--
main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];)
putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On Jun 23, 2017, at 11:29 PM, Christian Hesse <[email protected]> wrote:
> Theodore Ts'o <[email protected]> on Fri, 2017/06/23 15:53:
>> +grub-devel
>>
>> On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
>>> Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
>>> loader to fail (unknown filesystem error) on the x86_64 VM I use for
>>> initial testing. I traced the problem to changes in the e2fsprogs
>>> configuration file which now sets 64 bit flags. I tried upgrading
>>> to GRUB 2.02 but that did not resolve the problem. Reverting the
>>> changes per the patch below fixes the problem.
>>
>> Hmm, my laptop has been using a file system with the 64-bit feature
>> enabled for quite some time, and my Debian Stretch system has been
>> using Grub 2.02 to boot my system without any difficulties.
>>
>> I've done a quick check of the Debian patches and none of them seem to
>> modify Grub's ext2/ext4 file system implementation. So I don't know
>> what to tell you. Are you sure you properly reinstalled grub on the
>> boot device after you upgraded to grub 2.02?
>
Yes. I did not upgrade the test VM directly. I replaced GRUB 2.00 with 2.02 in my build automation which creates an installer ISO. Installation onto the VM is also largely automated. GRUB 2.02 (and 2.00) work fine if I revert the config file to that in 1.42.13.
To be clear: I don?t believe any of the code changes between 1.42.13 and 1.43.4 cause this issue. The problem arises from just the changes in the built-in default configuration file that gets installed. A distro that uses its own custom configuration file may not encounter this issue.
> Grub should be fine, however syslinux still suffers issues with 64-bit
> feature. Possibly you use a chain to load syslinux first, grub second?
Yes, my test VM is configured to chain load GRUB from Syslinux (ISOLINUX). I don?t recall whether I tried booting directly into GRUB so I will test that tomorrow.
Regards,
Felipe
сб, 24 июн. 2017 г., 23:22 Felipe A Rodriguez <[email protected]>:
> On Jun 23, 2017, at 11:29 PM, Christian Hesse <[email protected]> wrote:
>
> > Theodore Ts'o <[email protected]> on Fri, 2017/06/23 15:53:
> >> +grub-devel
> >>
> >> On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
> >>> Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
> >>> loader to fail (unknown filesystem error) on the x86_64 VM I use for
> >>> initial testing. I traced the problem to changes in the e2fsprogs
> >>> configuration file which now sets 64 bit flags. I tried upgrading
> >>> to GRUB 2.02 but that did not resolve the problem. Reverting the
> >>> changes per the patch below fixes the problem.
> >>
> >> Hmm, my laptop has been using a file system with the 64-bit feature
> >> enabled for quite some time, and my Debian Stretch system has been
> >> using Grub 2.02 to boot my system without any difficulties.
> >>
> >> I've done a quick check of the Debian patches and none of them seem to
> >> modify Grub's ext2/ext4 file system implementation. So I don't know
> >> what to tell you. Are you sure you properly reinstalled grub on the
> >> boot device after you upgraded to grub 2.02?
> >
>
> Yes. I did not upgrade the test VM directly. I replaced GRUB 2.00 with
> 2.02 in my build automation which creates an installer ISO. Installation
> onto the VM is also largely automated. GRUB 2.02 (and 2.00) work fine if I
> revert the config file to that in 1.42.13.
>
Do you mean grub is unable to read some files ? Can you try, recreating it
with grub-fstest? Can you upload failing image somewhere?
>
> To be clear: I don’t believe any of the code changes between 1.42.13 and
> 1.43.4 cause this issue. The problem arises from just the changes in the
> built-in default configuration file that gets installed. A distro that
> uses its own custom configuration file may not encounter this issue.
>
>
> > Grub should be fine, however syslinux still suffers issues with 64-bit
> > feature. Possibly you use a chain to load syslinux first, grub second?
>
> Yes, my test VM is configured to chain load GRUB from Syslinux
> (ISOLINUX). I don’t recall whether I tried booting directly into GRUB so I
> will test that tomorrow.
>
>
>
>
>
> Regards,
>
> Felipe
>
> _______________________________________________
> Grub-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
On Jun 24, 2017, at 9:08 PM, Felipe A Rodriguez <[email protected]> wrote:
> On Jun 23, 2017, at 11:29 PM, Christian Hesse <[email protected]> wrote:
>
>> Theodore Ts'o <[email protected]> on Fri, 2017/06/23 15:53:
>>> +grub-devel
>>>
>>> On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
>>>> Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
>>>> loader to fail (unknown filesystem error) on the x86_64 VM I use for
>>>> initial testing. I traced the problem to changes in the e2fsprogs
>>>> configuration file which now sets 64 bit flags. I tried upgrading
>>>> to GRUB 2.02 but that did not resolve the problem. Reverting the
>>>> changes per the patch below fixes the problem.
>>>
>>> Hmm, my laptop has been using a file system with the 64-bit feature
>>> enabled for quite some time, and my Debian Stretch system has been
>>> using Grub 2.02 to boot my system without any difficulties.
>>>
>>> I've done a quick check of the Debian patches and none of them seem to
>>> modify Grub's ext2/ext4 file system implementation. So I don't know
>>> what to tell you. Are you sure you properly reinstalled grub on the
>>> boot device after you upgraded to grub 2.02?
>>
>
> Yes. I did not upgrade the test VM directly. I replaced GRUB 2.00 with 2.02 in my build automation which creates an installer ISO. Installation onto the VM is also largely automated. GRUB 2.02 (and 2.00) work fine if I revert the config file to that in 1.42.13.
>
> To be clear: I don?t believe any of the code changes between 1.42.13 and 1.43.4 cause this issue. The problem arises from just the changes in the built-in default configuration file that gets installed. A distro that uses its own custom configuration file may not encounter this issue.
>
>
>> Grub should be fine, however syslinux still suffers issues with 64-bit
>> feature. Possibly you use a chain to load syslinux first, grub second?
>
> Yes, my test VM is configured to chain load GRUB from Syslinux (ISOLINUX). I don?t recall whether I tried booting directly into GRUB so I will test that tomorrow.
>
Sysllinux chain-loading is not a factor (GRUB 2.00 still fails to boot w/o it). GRUB 2.02 does resolve the issue. The command line for 2.02 required a ?-p? switch which 2.00 does not. This probably caused an uncaught and unnoticed failure during installation in my previous testing.
Regards,
Felipe
On Sun, Jun 25, 2017 at 08:16:39PM +0200, Felipe A Rodriguez wrote:
>
> Sysllinux chain-loading is not a factor (GRUB 2.00 still fails to
> boot w/o it). GRUB 2.02 does resolve the issue. The command line
> for 2.02 required a “-p” switch which 2.00 does not. This probably
> caused an uncaught and unnoticed failure during installation in my
> previous testing.
Again, Debian is using e2fsprogs 1.43.4 and uses ext4 as the default
file system, and GRUB 2.02 as the default boot system. No one has
complained about failures in the instsall process, and I'm pretty sure
the Debian installer team has done their usual great job in testing
and QA. So if there was an issue in the combination of ext4,
e2fsprogs 1.43.4 and Grub 2.02 in Debian Stretch (the latest Debian
Stable, version 8.0) they would have found it.
I am also *personally* using a root file system with 64-bit feature
enabled:
# dumpe2fs -h /dev/callcc/root | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
and the system boots just fine on GRUB 2.02. So it seems to work for
everyone who is using the Debian Installer to install a default setup
using the latest Debian Stable Release. My personal setup involves
using the UEFI boot loader (grubx64.efi) installed as the default
bootloader. (e.g., as /EFI/BOOTX64.EFI).
I'm also using a fairly complex setup, with both dm-crypt (LUKS) and
LVM, so the output of lsblk looks like this on my laptop
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.9T 0 disk
├─sda1 8:1 0 480M 0 part <--- EFI VFAT partition
└─sda2 8:2 0 1.9T 0 part
└─callcc_crypt 254:0 0 1.9T 0 crypt
├─callcc-root 254:1 0 326G 0 lvm /
...
It doesn't get any much more complex than this, and it Just Works.
About the only annoying thing is that I have to type my decryption
password twice. Once to grub, so it can read the LUKS partition, then
find the root partition Logical Volume, and the read the kernel and
initramfs, and the after the kernel boots and initramfs is loaded, I
have to type the password to initramfs a second time so Linux can
unlock the LUKS partition and then mount the root partition.
So when you say that enabling the 64-bit file system feature causes a
regression by causing Grub to fail to be able to read the root file
system, I have to respectfully disagree. I do it all the time when I
reboot my kernel, and it Works For Me...
- Ted
On Jun 26, 2017, at 4:40 AM, Theodore Ts'o <[email protected]> wrote:
> On Sun, Jun 25, 2017 at 08:16:39PM +0200, Felipe A Rodriguez wrote:
>>
>> Sysllinux chain-loading is not a factor (GRUB 2.00 still fails to
>> boot w/o it). GRUB 2.02 does resolve the issue. The command line
>> for 2.02 required a ?-p? switch which 2.00 does not. This probably
>> caused an uncaught and unnoticed failure during installation in my
>> previous testing.
>
> Again, Debian is using e2fsprogs 1.43.4 and uses ext4 as the default
> file system, and GRUB 2.02 as the default boot system. No one has
> complained about failures in the instsall process, and I'm pretty sure
> the Debian installer team has done their usual great job in testing
> and QA. So if there was an issue in the combination of ext4,
> e2fsprogs 1.43.4 and Grub 2.02 in Debian Stretch (the latest Debian
> Stable, version 8.0) they would have found it.
>
> ? snip
> So when you say that enabling the 64-bit file system feature causes a
> regression by causing Grub to fail to be able to read the root file
> system, I have to respectfully disagree. I do it all the time when I
> reboot my kernel, and it Works For Me...
>
> - Ted
Huh ??? I indicated GRUB 2.00 stopped working with the upgrade to 1.43.4, but GRUB 2.02 works fine.
Felipe
On Mon, Jun 26, 2017 at 08:46:48AM +0200, Felipe A Rodriguez wrote:
> > So when you say that enabling the 64-bit file system feature causes a
> > regression by causing Grub to fail to be able to read the root file
> > system, I have to respectfully disagree. I do it all the time when I
> > reboot my kernel, and it Works For Me...
>
> Huh ??? I indicated GRUB 2.00 stopped working with the upgrade to 1.43.4, but GRUB 2.02 works fine.
You originally said:
On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
> Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
> loader to fail (unknown filesystem error) on the x86_64 VM I use for
> initial testing. I traced the problem to changes in the e2fsprogs
> configuration file which now sets 64 bit flags. I tried upgrading
> to GRUB 2.02 but that did not resolve the problem.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In your follow up, you didn't bother line wrapping your message, so I
misparsed the sentence where you stated "Grub 2.02 does resolve the
problem" because it was burried in a several hundred character long
line. My apologies.
- Ted
On Jun 27, 2017, at 3:53 AM, Theodore Ts'o <[email protected]> wrote:
> On Mon, Jun 26, 2017 at 08:46:48AM +0200, Felipe A Rodriguez wrote:
>>> So when you say that enabling the 64-bit file system feature causes a
>>> regression by causing Grub to fail to be able to read the root file
>>> system, I have to respectfully disagree. I do it all the time when I
>>> reboot my kernel, and it Works For Me...
>>
>> Huh ??? I indicated GRUB 2.00 stopped working with the upgrade to 1.43.4, but GRUB 2.02 works fine.
>
> You originally said:
>
> On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
>> Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
>> loader to fail (unknown filesystem error) on the x86_64 VM I use for
>> initial testing. I traced the problem to changes in the e2fsprogs
>> configuration file which now sets 64 bit flags. I tried upgrading
>> to GRUB 2.02 but that did not resolve the problem.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> In your follow up, you didn't bother line wrapping your message, so I
> misparsed the sentence where you stated "Grub 2.02 does resolve the
> problem" because it was burried in a several hundred character long
> line. My apologies.
>
> - Ted
No problem. My thanks to you and all others who contributed to e2fsprogs and GRUB dev.
Felipe