lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Stephen Powell on 25 May 2010 22:00 On Tue, 25 May 2010 11:10:38 -0400 (EDT), Ferenc Wagner wrote: > Stephen Powell wrote: >> ... I installed the mbr package ... > > The extlinux package itself also contains an mbr.bin, which you can use > (it's strong point is probably EBIOS support). So it does. Well, I've now installed extlinux' version of mbr.bin to the master boot record and purged the mbr package. extlinux' built-in version of a master boot record boot loader works great. >> >> Speaking of documentation, that seems to be its main weakness. >> Documentation is sketchy and spread out over a number of different files. > > /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly > comprehensive according to my standards, at least as far as the core is > concerned. What did you miss? Some modules may be less well documented. Yes, I found those two files. Reference documentation for each specific boot loader option is there, but what is lacking is tutorial-type stuff. For example, there is a global options section at the beginning that applies to all bootable images, and there are options which are specific to each boot image. I guessed at that mainly based on how /etc/lilo.conf works, but I'm not sure it was directly stated anywhere. It may be hinted at in the description of some individual configuration option but not explained "up front". Also, there's no example configuration file. There are little pieces of configuration files but no complete typical configuration file. A "picture" is worth a thousand words. >> It installs hook scripts that I don't want (and that have bugs). > > I hope we can fix them soon (they are Debian specific additions). Remember, I'm used to using lilo. And based on analogies with lilo, I built a /boot/extlinux/extlinux.conf file that looks like this: ----- DEFAULT Linux APPEND root=/dev/sda2 ro vga=779 TIMEOUT 50 PROMPT 1 LABEL Linux KERNEL ../vmlinuz INITRD ../initrd.img LABEL LinuxOLD KERNEL ../vmlinuz.old INITRD ../initrd.img.old ----- The kernel and initial RAM disk images are specified via the traditional symlinks. As long as the symlinks are maintained properly, my config file never needs updating, just like lilo's. Consequently, I really don't want the extlinux hook scripts to execute at all when I install or remove a kernel. I solved that temporarily by issuing chmod -x /etc/kernel/postinst.d/extlinux chmod -x /etc/kernel/postrm.d/extlinux That works for now; but if a package upgrade for extlinux is ever downloaded, I'm afraid that new versions of the hook scripts will be copied into these directories which are marked executable, and my hand-made configuration file will get wiped out. I would suggest testing the existence of some flag file. If the flag file exists, then invoking update-extlinux should be bypassed. Thus, if the user doesn't want his hand-made /boot/extlinux/extlinux.conf file to be tampered with, he can create that flag file via "touch" and the hook script will not run update-extlinux. Strictly speaking, this is an enhancement request. Second, it is important that any script run as a hook script not produce any output at all to standard output. I found that out the hard way when I was writing my own hook scripts for use with lilo. That's because they run under debconf, which has redirected standard output for its own purposes. Thus, anything written to standard output is (1) never seen by the user and (2) has a good chance of messing up debconf, which is examining the output. The invocation of update-extlinux should have a redirection on it to redirect output to standard error. For example, update-extlinux >&2 This is a bona-fide bug. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/630546796.56099.1274837814099.JavaMail.root(a)md01.wow.synacor.com
From: Daniel Baumann on 26 May 2010 00:30 On 05/26/2010 03:36 AM, Stephen Powell wrote: > That works for now; but if a package upgrade for extlinux is ever > downloaded, I'm afraid that new versions of the hook scripts will > be copied into these directories which are marked executable, and > my hand-made configuration file will get wiped out. I would suggest > testing the existence of some flag file. If the flag file exists, > then invoking update-extlinux should be bypassed. Thus, if the user > doesn't want his hand-made /boot/extlinux/extlinux.conf file to be > tampered with, he can create that flag file via "touch" and the hook > script will not run update-extlinux. Strictly speaking, this is > an enhancement request. as of current git, you can now use EXTLINUX_UPDATE=false in /etc/default/extlinux to prevent having update-extlinux do anything. > Second, it is important that any script run as a hook script not > produce any output at all to standard output. I found that out the > hard way when I was writing my own hook scripts for use with lilo. > That's because they run under debconf, which has redirected standard > output for its own purposes. Thus, anything written to standard > output is (1) never seen by the user and (2) has a good chance of > messing up debconf, which is examining the output. The invocation > of update-extlinux should have a redirection on it to redirect > output to standard error. For example, > > update-extlinux >&2 none of the hooks is doing this (initramfs-tools, grub, etc), might needs further convincing. -- Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baumann(a)panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-devel-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BFCA228.5000601(a)debian.org
From: thib on 26 May 2010 01:20 consul tores wrote: > Again, and again; Debian depends of Linus Torvals; maybe it is time to > seriously think about Debian kernels! Madness. -t -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BFCACE6.1080309(a)stammed.net
From: Mihamina Rakotomandimby on 26 May 2010 01:40 > consul tores <consultores1(a)gmail.com> : >Again, and again; Debian depends of Linus Torvals; maybe it is time to >seriously think about Debian kernels! http://www.debian.org/ports/hurd/ -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 3456 000 19 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100526083301.2f8412b8(a)pbmiha.malagasy.com
From: consul tores on 26 May 2010 01:50
2010/5/25 thib <thib(a)stammed.net>: > consul tores wrote: >> >> Again, and again; Debian depends of Linus Torvals; maybe it is time to >> seriously think about Debian kernels! > > Madness. > > -t Could you say why? We have lost the posibility to install from disquette, we have to add an initrd, SElinux have been added by default because of Linus, Linus kernels define what to do, and ad infinitum. Do you know how BSDs work? Have you try Hurd? Well you can see some reasons to built Debian kernels. -- Consultores Agropecuarios. Administracion, Produccion, Capacitacion. -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/AANLkTilx9mME2_aFyIUPvfjvhcCQpNhLP0B-4U_M49fx(a)mail.gmail.com |