Mark Hedges schreef: > > 1) When I installed splashy with apt-get I was running my > custom kernel. When I removed splashy I was running the > stock kernel, but it rebuilt initramfs for the custom > kernel. So it did not "by default only rebuild the > initramfs of the current kernel."
You're right. It is not updating the initramfs of the current kernel (the one you are running), but it is updating the initramfs of a kernel which is sorted as highest by some algorithm I do not remember the details of. What is most important is that it will always be the same kernel, whatever one you are running at the moment. I think the sorting is such that under normal circumstances (as in: you just track the debian kernels) it will update the newest kernel. > 2) What happens if I rebuilt the initramfs of kernel A to > include splashy, but then I boot kernel B and remove the > splashy package, then reboot to kernel A? Won't the kernel > load the boot screen that was included? But I've removed it > so what will happen after switching root? If you boot an initramfs with splashy included while it is removed from the root system, splashy will be started from initramfs as usual. The process will probably just survive the root-switching. There will however not be a splashy-update command on the root file system, so the progress bar will not be updated. Splashy will however timeout at some point. You will also still be able to kill splashy manually. So nothing dramatic will happen. You can also change the kernel command-line from grub and add nosplash to supress splashy. > I think there should be a splashy update that wraps > update-initramfs (or yaird or whatever you have selected) > and keeps track of which kernels have splashy installed. That sounds much to fragile. > Then `splashy_config -s theme` can call that automatically. > (That was something that took me a while to figure out that > I needed to do BTW.) [ this is not relevant for the current discussion, but it is probably a good idea to let splashy_config rebuild the initramfs as if it were a package update] As I explained before it was agreed under all maintainers supplying initramfs additions that rebuilding more than one initramfs on upgrades/removals is not going to happen by default. This is what was the concensus. Also `normal' users will find their system working as usual. It will only give (minor) problems if you start installing custom kernels. As I said, there is the possibility to configure initramfs-tools to rebuild all initramfses on removal, why isn't that a solution for your use case? Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
