linux-ext4 - Re: Richacl and ext4 vs. xfs

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]

Date:   Sat, 5 Nov 2016 00:15:02 +0100
From:   Andreas Gruenbacher <agruenba@...hat.com>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Steve French <smfrench@...il.com>,
        samba-technical <samba-technical@...ts.samba.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: Richacl and ext4 vs. xfs

On Fri, Nov 4, 2016 at 11:48 PM, Andreas Dilger <adilger@...ger.ca> wrote:
> [added linux-ext4 to CC list]
>
> On Nov 4, 2016, at 1:19 PM, Steve French <smfrench@...il.com> wrote:
>>
>> Andreas,
>> I had been working on getting some VMs together to experiment with a
>> few different Richacl configurations and it looks like the e2fsprogs
>> git hub repo with richacl enhanced ext4 utilities may need to be
>> updated or have an incompatibility with current kernels (See e2fsprogs
>> github link at http://www.bestbits.at/richacl/ ).  XFS worked ok.
>>
>> Fedora 24 Workstation, created two extra disks
>> /dev/sdb for xfs
>> /dev/sdc for ext4
>>
>> Built and installed Andreas's 4.9.0-rc1 based kernel richacl branch
>> and the other repos (xfsprogs, richacl etc.).    Had no problem
>> formatting and using /dev/sdb1 as xfs, but once I installed e2fsprogs
>> from Andreas's tree I couldn't boot the system (removed e2fsprogs and
>> the ext4 partition and booted fine).  With Andreas's e2fsprogs I
>> couldn't boot 4.9.0-rc1
>
> What version of e2fsprogs is (the other) Andreas' tree based on?  The
> newer e2fsprogs-1.43 has support for metadata checksums, but this should
> be off by default in the released version.  The testing version had it
> enabled by default.

The richacl patches were based on v1.42.12+. They only define a new
"richacl" feature flag, so I don't think they are to blame for the
failure Steve is seeing. I've still rebased the patches onto v1.43.3+
now.

Steve, I assume that /dev/sdc is not the root filesystem or listed in
/etc/fstab; if so, then the device will have no influence on booting.

Does the richacl kernel use an initrd? If so, then please check for
mkinitrd errors: I've seen versions of mkinitrd (dracut) that use a
blkid option that isn't part of e2fsprogs v1.42. Not sure if v1.43 has
this fixed or if this is a distro specific problem.

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html