linux-kernel - Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

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: <20100827163753.GA13252@citd.de>
Date:	Fri, 27 Aug 2010 18:37:53 +0200
From:	Matthias Schniedermeyer <ms@...d.de>
To:	Eric Valette <Eric.Valette@...e.fr>
Cc:	Phil Turmel <philip@...mel.org>, linux-kernel@...r.kernel.org,
	Florian Mickler <florian@...kler.org>
Subject: Re: Please add generic support for root=UUID= at kernel parameter
	command line (LABEL, BYID maybe also)

On 27.08.2010 13:59, Eric Valette wrote:
> On 08/26/2010 09:53 PM, Phil Turmel wrote:
>
>>
>>> Now I'm really puzzled grub2 as a "search by fs uuid" command that linux is unable to deliver for the root device!
>>
>> The key word here is "unable".  The maintainers aren't *unable* to do this.  They are *unwilling* to do this.  I don't recall the precise discussion, but basically it boils down to the fact that early userspace (aka initramfs) can do this efficiently, and it needs to be supported in initramfs for other reasons, so it is pointless to duplicate this code in the kernel.  I'm sure block folk will chime in if this isn't a fair representation (my apologies in advance if so).
>>
>> Try dracut.  Seriously.  It's lean and mean just for this use-case, and you'll be protecting yourself against future changes in the block layer.  And you can put root=LABEL=foo on your kernel command line to match your fstab.
>
>
> This is a rather bizarre argument as because of this situation
> 	1) the code is duplicated between the initramfs and the real disk

I don't really get what you mean.
But binary duplication isn't the issue, source-code duplication is.
I'd count an initramfs to the binary category. It is "compiled" more or 
less literaly.

> 	2) the initramfs has to be rebuild each time a new kernel is done

Only when you use kernel-modules, otherwise you should be fine for "some 
time".

> 	3) The tmpdevfs is also a dupplicate somehow

No.

devtmpfs uses tmpfs or ramfs as backing-store. And it doesn't really 
duplicate udev either, as it only does the bare minimum needed to get 
the computer to the point where udev can do the rest. Like when you have 
a root filesystem with no /dev at all.
(Which was kind of an chicken & egg-problem before.)





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/