linux-ext4 - Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

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: <1239650325.18123.35.camel@localhost>
Date:	Mon, 13 Apr 2009 20:18:45 +0100
From:	"Ricardo M. Correia" <Ricardo.M.Correia@....COM>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Andreas Dilger <adilger@....COM>, "Theodore Ts'o" <tytso@....edu>,
	linux-ext4@...r.kernel.org, Karel Zak <kzak@...hat.com>
Subject: Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

Hi Eric,

On Seg, 2009-04-06 at 13:13 -0700, Eric Sandeen wrote: 
> Can you perhaps just chime in on these bugs & ask?  you speak zfs better
> than I do...
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=494070
> https://bugzilla.redhat.com/show_bug.cgi?id=490795

Sorry for taking a while to get back to you.

I've just looked at these bugs and everything seems to make more sense
now. Those partitions are actually Solaris partitions, which contain
their own partition table inside.

So in bug 494070, the /dev/sda2 partition is internally subdivided into
what Solaris calls "slices" (which are similar to partitions) and then
the root ZFS pool/filesystem is stored inside one of these slices. So in
fact, the ZFS pool is not directly in /dev/sda2, it's somewhere inside
it. This is why the ZFS magic numbers don't seem to be in the right
place.

These slices don't seem to be visible to that Linux system, which I
suspect is due to the kernel not being compiled with Solaris partition
table support. If it were, other partitions (including the ZFS one)
would show up (if my assumption is correct).

So from looking at the libblkid magic offsets, it seems that ext3 magic
value is stored between 1K-2K, which means that it will fall into the
boot slice, not in the ZFS slice. So AFAICS this bug doesn't have
anything to do with ZFS, i.e., the same thing would happen if the root
filesystem of the OpenSolaris installation was UFS.

It'd be nice if OpenSolaris zeroed the boot slice when it is installed,
but on the other hand, should the Anaconda installer fail just because
it can't mount a (possibly corrupted/leftover) filesystem?

I can file a bug for OpenSolaris if you feel strongly about this.

Thanks,
Ricardo

--
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