![](https://seccdn.libravatar.org/avatar/bc496665c59405794cdb5236dd40ad59.jpg?s=120&d=mm&r=g)
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
So appending is basically "mksquashfs source/ destination.squashfs" instead of "gunzip -c cpio.gz | cpio -idmv" then copying in new files and "cpio -idmv | gzip -c >cpio.gz" kind of stuff.
That would make a simple add easier, more frequent probably would be delete & add files though.
2009/1/14 Matt Sealey <matt@genesi-usa.com>:
Though mounting, copying to disk, and then re-building the formatted file, is more like making iso files.
Not so. Rob, again, you've overcomplicated it by looking at it from your skewed view of things, and not what I actually said or what is under discussion.
"zcat initrd | cpio -id" and then rebuilding, wasn't obvious enough to get suggested when I had an issue with replacing the driver with mkinintrd on a live system.
You can't replace a file in the initrd on a live filesystem that's *mounted*. If you want to add files to the initrd, grab your kernel module name, add it to the list in /etc/sysconfig/kernel INITRD_MODULES like you said below, and run mkinitrd again (or if
Well Matt, if you read back, you'll find as explained, doing that did not work.
udev captures the modules "coldplugged" by the system (usually USB and Firewire) and this gets added to the list in INITRD_MODULES for the initrd. INITRD_MODULES is basically the list of modules that *has* to be loaded to get to mount the disk that udev is on (plus anything else you care to add). This is usually exactly your libata driver and your root filesystem module (on my system, "pata_mpc52xx xfs", on my Pegasos, "pata_via", on my VirtualBox systems, "ahci")
That was not the case. INITRD_MODULES was not containing the expected information, and replacing the root filesystem driver, from the udev list was not possible. The broken driver was always loaded into the initrd. If INITRD_MODULES was working like that, as it used to pre-11.1 I don't think I'd have had an issue. It would have been a simple edit, and re-run mkinitrd.
The "problem" with adding stuff to the initrd is, is not a problem at all. Apart from the fact that INITRD_MODULES is generated during the install? If it installed the wrong driver (via82cxxx for example) for the disk then it glues that in there and it's not that easy to get it to automatically fix it.
It's actually removing things, as well as adding what you actually want, that appears necessary. As it stood, running mkinitrd by default updates for all kernels and initrd, which can caused the system to become unbootable, when attempting to force usage of the pdc202xx_old driver. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org