Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol <mikemol@gmail.com>]

On Tue, Dec 18, 2012 at 6:07 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 18 Dec 2012 17:55:16 -0500, Michael Mol wrote:
>
>> > #2 already has a solution, it's called an init*. Other solutions exist
>> > but none are as elegant as a throwaway temporary filesystem in RAM.
>>
>> I find virtually nothing elegant about a temporary filesystem in RAM.
>> It duplicates code that already exists on the system, and it
>> represents and additional maintenance step in system upgrades. It
>> seems almost a given that if someone is keeping multiple kernel images
>> on a system, they're not updating the initr* for each when binaries
>> that would be found in each are upgraded or rebuilt.
>
> I don't use separate initr* files, the initramfs is built into the
> kernel, using the latest versions of the tools installed at the time the
> kernel was compiled. That gives a single bootable file that, if it works
> now, should always work. Most changes to the component packages do not
> affect the simple job they have to do to get a system ready to run init.

Just because it runs, doesn't mean it "works." For example, let's say
your network now requires an additional protocol for the host to
operate properly. Or let's say there's a security vulnerability in
some network-aware component in your initramfs. Or that some piece of
automounter code is vulnerable to corrupted filesystems on flash
drives.

>
>> In Debian, Ubuntu and others, this is handled by a post-install hook
>> where the initr* image is rebuilt. To me, this honestly feels like a
>> hack. In something like Gentoo, I'd rather see package placement
>> driven by whether or not it will be needed to get all mount points
>> mounted. If that means i18n databases under something like /boot/data,
>> that seems reasonable. To me, the only cases where initr* feels like
>> the right solution are things like netboot or booting from read-only
>
> Or / on LVM, or / on an encrypted filesystem. or any other requirement
> for a filesystem that cannot be used without adding code to the kernel.

/ on special filesystems is a good use case, yes. I should have said
"/ from an unusual source."

--
:wq