linux-ext4 - Re: Possible regression in e2fsprogs-1.43.4 [RESOLVED]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170626024019.hni2k6uwfb7sknaw@thunk.org>
Date:   Sun, 25 Jun 2017 22:40:19 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Felipe A Rodriguez <far@...umenos.com>
Cc:     Christian Hesse <list@...rm.de>,
        The development of GNU GRUB <grub-devel@....org>,
        linux-ext4@...r.kernel.org
Subject: Re: Possible regression in e2fsprogs-1.43.4  [RESOLVED]

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