Bug#336514: yaird: falls down when new scsi/sata disks are added
On Tue, Nov 01, 2005 at 11:16:21AM +0100, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 1 Nov 2005 09:04:35 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
>
> > On Mon, Oct 31, 2005 at 03:48:44PM -0500, Daniel Jacobowitz wrote:
> > > On Mon, Oct 31, 2005 at 09:45:54PM +0100, Erik van Konijnenburg
> > > wrote:
> > > > Interesting to experiment with, but not a quick fix for today.
> > >
> > > Sure. I'd just like to point out that, today, there is no way to
> > > add a drive to a configuration like mine, while using yaird, that
> > > is not extremely painful, manual, and awkward. Even if I had known
> > > that yaird would be such a problem before I did it, there's no
> > > obvious way to generate a new initrd for any configuration other
> > > than my current one.
> >
> > The plan for this is to modify the d-i rescue mode to be able to
> > regenerate the yaird initrd (BTW, Jonas, maybe you could already add
> > a yaird .udeb for that), so you add your disk, boot into the d-i
> > rescue mode, the ramdisk gets regenerated, and all works fine.
>
> Is that plan documented somewhere?
Nope.
> I seem to remember sceptical voices when that approach was mentioned on
> #debian-kernel. One point raised was with remote-controlled systems.
well, it is not a viable sarge-etch upgrade patch, but it sure comes in handy
in various cases, and it may be the way to do it for people modifying their
hardware configs and using yaird.
This is a different case than the generic sarge/2.4 to etch/2.6/yaird upgrade
path which was critiqued earlier.
> What I would like is a kernel-install-helper extended to provide the
> user with a choice of ramdisk tool similar to choice of default
> dictionaries today. Read the draft here:
> wiki.debian.org/FlexibleKernelHandling
Yep. Will not help with the dependencies though. We can easily enough put that
in /etc/kernel.d/postinst.d, altough i am not sure this will be run early
enough for it to be used while generating ramdisks. Maybe we should separate
the whole ramdisk thingy out of the generic kernel-tools, as well as the
bootloader issues, and handle them in /etc/kernel/postinst.d. Look at the
(powerpc) mkvmlinuz package on how this could be handled neatly.
> Regarding udeb: Could someone provide me a good reference for that - I
> have never packaged a udeb.
Mmm, there may be some documentation around, but i gather is is rather
straightforward. Look at the debian-installer wiki pages maybe, or ask on
#debian-boot.
Friendly,
Sven Luther
Reply to: