linux-kernel - mkinitrd. (was Re: [RFC] [PATCH] Allow overriding module parameters from kernel command

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] [day] [month] [year] [list]

Message-ID: <20070418225810.GB20204@redhat.com>
Date:	Wed, 18 Apr 2007 18:58:10 -0400
From:	Dave Jones <davej@...hat.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kyle McMartin <kyle@...onical.com>,
	linux-kernel@...r.kernel.org, alan@...hat.com, bcollins@...ntu.com,
	pjones@...hat.com
Subject: mkinitrd.  (was Re: [RFC] [PATCH] Allow overriding module parameters from kernel command_line)

On Thu, Apr 19, 2007 at 08:47:13AM +1000, Neil Brown wrote:

 > > Fixed by changing /etc/fstab and rebuilding initrd, but IMO rootfstype=
 > > should have worked.
 > 
 > I think these are both issues that should be solved by smarts in the
 > initrd.

This is getting away from the intent of Kyle's original patch
(Which I think is worthwhile fwiw, having recently hit the exact
 same sata_nv bug that prompted him to write it)

 > What we really need is a single reference implementation of "mkinitrd"
 > which each distro can fiddle with to their heart's content.  Then
 > sensible ideas like the above can be incorporated into the reference,
 > and all distros will ultimately pick them up.
 > 
 > But unfortunately I don't have the time to volunteer for this role...

The problem I see with such a 'one mkinitrd to rule them all', is that
it would suffer from the same thing that stopped any vendor stepping
up and getting behind hpa's klibc project...  Apathy due to "our current
stuff works, why would we throw it all away and start again"

It's a great idea in theory, in practise however, initrd construction
for every distro now contains years of custom hacks and workarounds
(that may not even be relevant on other distros).

Given the critical nature of mkinitrd (get something wrong, and your
system doesn't boot), unsurprisingly, people are reluctant to change
away from something they're familar with, unless there's a *really*
compelling reason.

	Dave

-- 
http://www.codemonkey.org.uk
-
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/