Possible regression in e2fsprogs-1.43.4

Possible regression in e2fsprogs-1.43.4

[Felipe A Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

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
________________________






[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1086 bytes --]

Re: Possible regression in e2fsprogs-1.43.4

[Theodore Ts'o]

+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

Re: Possible regression in e2fsprogs-1.43.4

[Christian Hesse]

[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --]

Theodore Ts'o <tytso@mit.edu> 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);}

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Possible regression in e2fsprogs-1.43.4

[Christian Hesse]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

Theodore Ts'o <tytso@mit.edu> 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);}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Possible regression in e2fsprogs-1.43.4

[Felipe A Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

On Jun 23, 2017, at 11:29 PM, Christian Hesse <list@eworm.de> wrote:

> Theodore Ts'o <tytso@mit.edu> 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


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1086 bytes --]

Re: Possible regression in e2fsprogs-1.43.4

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 2507 bytes --]

сб, 24 июн. 2017 г., 23:22 Felipe A Rodriguez <far@illumenos.com>:

> On Jun 23, 2017, at 11:29 PM, Christian Hesse <list@eworm.de> wrote:
>
> > Theodore Ts'o <tytso@mit.edu> 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #1.2: Type: text/html, Size: 3388 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Possible regression in e2fsprogs-1.43.4

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

сб, 24 июн. 2017 г., 23:22 Felipe A Rodriguez <far@illumenos.com>:

> On Jun 23, 2017, at 11:29 PM, Christian Hesse <list@eworm.de> wrote:
>
> > Theodore Ts'o <tytso@mit.edu> 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3388 bytes --]

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Felipe A Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 2460 bytes --]

On Jun 24, 2017, at 9:08 PM, Felipe A Rodriguez <far@illumenos.com> wrote:

> On Jun 23, 2017, at 11:29 PM, Christian Hesse <list@eworm.de> wrote:
> 
>> Theodore Ts'o <tytso@mit.edu> 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




[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1086 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Felipe A Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

On Jun 24, 2017, at 9:08 PM, Felipe A Rodriguez <far@illumenos.com> wrote:

> On Jun 23, 2017, at 11:29 PM, Christian Hesse <list@eworm.de> wrote:
> 
>> Theodore Ts'o <tytso@mit.edu> 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




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1086 bytes --]

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Theodore Ts'o]

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

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Felipe A Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On Jun 26, 2017, at 4:40 AM, Theodore Ts'o <tytso@mit.edu> 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

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1086 bytes --]

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Colin Watson]

On Mon, Jun 26, 2017 at 08:46:48AM +0200, Felipe A Rodriguez wrote:
> On Jun 26, 2017, at 4:40 AM, Theodore Ts'o <tytso@mit.edu> 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.
[...]
> > 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.

Yes - I think this is to be expected since support for the 64-bit
feature was only added in 2.02.  (See the NEWS file, or commit
073b57bb8e2d688f33198f97076d01cea4455d7f.)

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Theodore Ts'o]

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

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Theodore Ts'o]

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

Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

[Felipe A Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Jun 27, 2017, at 3:53 AM, Theodore Ts'o <tytso@mit.edu> 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


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1086 bytes --]