Bug#457044: (pas de sujet)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jun 04, 2008 at 02:22:47PM +0200, [EMAIL PROTECTED] wrote: > Jonas Smedegaard a écrit : >> >> Those tools are different approaches indeed. How do you find them >> contradictory? Please elaborate - I sincerely want to understand >> better. > > Sorry for being confusing. Saying contradictory I wasn't talking about > the tools themselves, but about the comments #43, #48, #53 and #58. Ah, ok. Perhaps I can help clarify: Debian is a large system, containing big pile of packages that is tested that they do not break each other. The system is not, however, simplified so that e.g. there's only a single way to setup and boot Linux kernels. For core booting, you have a choice of bootloader, ramdisk-generator, kernels and device handling. If you dislike the confusion of the many choices (and us package maintainers disagreeing of what's best), then use the same as gets installed by default using a recent debian-installer. On IBM-compatible x86 systems that means the bootloader "grub", the ramdisk-generator "initramfs-tools", a kernel compiled and packaged by the Debian kernel team, and devices handled by udev. If you want to investigate alternatives, then this mailinglist is *not* a common middleground, but biased towards their own favourite bot chain: An active member of The Debian kernel team, Max, is also the maintainer of initramfs-tools. Max has a strong opinion on the state of the competing ramdisk-generator yaird. So strong an opinion that he would rather the package be removed from Debian than being used in its current state[1]. So here at this list you should expect only sceptical opinions on alternatives to the mainstream setup. Use mailinglists or file bugs tied to the respective alternative tool for positive opinions on them. > As I am myself a bit confused about how to do to ensure a correct > reboot of my boxes, this "friendly battle" between developpers didn't > help me very much. Agreed. And on this list I cannot help you further - you need to decide if you want to gain more info on your current setup by addressing the maintainers of the tools you use or might want to use. Or you need to change your setup to satisfy the maintainers of the mainstream tools for them to want to "waste time on you". Or so it seems to me. I am biased :-P > Anyway both of those tools seems very useful Indeed. initramfs-tools and yaird has different qualities. Each has their good use IMHO. > But my problem is still when a reboot is needed for distant machines, > now I'm too afraid about that to take the risk. I see your problem. And I want to help. Just cannot do so here. - Jonas [1] http://bugs.debian.org/457177 - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhGtnsACgkQn7DbMsAkQLhwgQCgph2BXb50LFLiZe0/LjSJ5bqN of8An0oquXjpDKQ+WemsmoB4HL7axquk =KHQd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457044: (pas de sujet)
Jonas Smedegaard a écrit : Those tools are different approaches indeed. How do you find them contradictory? Please elaborate - I sincerely want to understand better. Sorry for being confusing. Saying contradictory I wasn't talking about the tools themselves, but about the comments #43, #48, #53 and #58. As I am myself a bit confused about how to do to ensure a correct reboot of my boxes, this "friendly battle" between developpers didn't help me very much. Anyway both of those tools seems very useful But my problem is still when a reboot is needed for distant machines, now I'm too afraid about that to take the risk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457044: (pas de sujet)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jun 04, 2008 at 10:05:01AM +0200, [EMAIL PROTECTED] wrote: > I've found a work around :now I never reboot any distant machine, > There are so many bugs indicating boot problems for so much different > reasons (394608,334831,327335,422217,462221...) It seems only a few of those bugs are related to kernel problems. But nevertheless I do acknowledge that kernel upgrades can be problematic. > I can't take this risk on distant production servers until I get a > solution to really double check the boot process before running it for > true. > I was unable to choose between yaird and kexec as the informations > provided were contradictory... Those tools are different approaches indeed. How do you find them contradictory? Please elaborate - I sincerely want to understand better. - Jonas Yaird package maintainer - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhGV/YACgkQn7DbMsAkQLgQvACfZgBMKX800rL9e3j+leXrZJwg PEQAn1nYjvCqAqvPG31j4w6cbHoI9dB2 =qy3C -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457044: (pas de sujet)
I've found a work around :now I never reboot any distant machine, I never follow the stressing instructions provided : You are attempting to install a kernel version that is the same as the version you are currently running (version > 2.6.18-4-686). The modules list is quite likely to have been changed, and the modules dependency file > /lib/modules/2.6.18-4-686/modules.dep needs to be re-built. It can not be built correctly right now, since the module list for the running kernel are likely to be different from the kernel installed. I am creating a new modules.dep file, but that may not be correct. It shall be regenerated correctly at next reboot. I repeat: you have to reboot in order for the modules file to be created correctly. Until you reboot, it may be impossible to load some modules. Reboot as soon as this install is finished (Do not reboot right now, since you may not be able to boot back up until installation is over, but boot immediately after). I can not stress that too much. You need to reboot soon. There are so many bugs indicating boot problems for so much different reasons (394608,334831,327335,422217,462221...) that I can't take this risk on distant production servers until I get a solution to really double check the boot process before running it for true. I was unable to choose between yaird and kexec as the informations provided were contradictory... thanks for all anyway -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
