lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Stephen Powell on 25 May 2010 09:40 Ferenc Wagner wrote: > Stephen Powell <zlinuxman(a)wowway.com> writes: >> >> Both grub-legacy and grub-pc use sectors on the hard disk outside of >> the master boot record and outside of a partition ... > > You may want to try extlinux, it works much like LILO in this respect. Well, I tried extlinux last night, and I am hopeful that this is going to be a solution, at least for me. extlinux seems to combine the best parts of grub-pc and lilo. Like grub-pc, extlinux understands the file system, and can read the configuration file, kernel, and the initial RAM file system image from the file system without needing a list of specific blocks to read. Thus, the boot loader does not need to be re-run every time a kernel is installed or updated or an initial RAM file system image is installed or updated. The number of file systems it supports is limited, but that's OK. A separate /boot partition of the file system type supported by the boot loader is acceptable. But like lilo it stays out of unallocated (and therefore not backed up) sectors. The boot block of extlinux is installed in the boot sector of a partition, and the second stage loader occupies a file within the partition. It does not use the master boot record. It relies on a master boot record program to chain load it from the partition boot sector. (I use the mbr package for that.) It *does* support the specification of an initial text video mode (vga option), though this is not specifically documented. Speaking of documentation, that seems to be its main weakness. Documentation is sketchy and spread out over a number of different files. I would have had a hard time configuring it if it weren't for correct guesses based on my knowledge of how lilo is configured, which newer users won't have. It installs hook scripts that I don't want (and that have bugs). But after manual configuration and tweaking, it works just fine. Now, if it passes the backup / low-level-format / restore test, I'll be good to go. Stay tuned ... -- .''`. 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/1078928757.35141.1274793733671.JavaMail.root(a)md01.wow.synacor.com
From: Stephen Powell on 25 May 2010 10:10 On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote: > William Pitcock <nenolod(a)dereferenced.org> wrote: >> This bug *can* be fixed, but not without a significant rewrite of the >> way that lilo's stage2 loader code works. Given that there is no >> active upstream and that the Debian lilo package carries many patches >> for bug fixes that are alleviated by standardizing on grub2, this >> seems like the best option for Debian. > > Agreed: dead (and buggy) softwares must be out of the distribution. > Whatever happens. If LILO regains upstream coders, its return to the > distribution is quite easy. By that standard, grub-pc should be removed from the distribution. It may have upstream support, but based on other posts I've seen, it effectively has no maintainer. Which is worse, a package with effectively no upstream support or a package with effectively no maintainer? And grub-pc is buggier than lilo. I understand the need to remove packages with no upstream support. But asking users to test a package with umpteen known release-critical bugs, most of which have apparently been fixed upstream, but have not been fixed in Debian because there is no maintainer to download a new upstream version, is not a reasonable request in my humble opinion. Get a maintainer for it, fix the known bugs, and *then* ask the users to test it. -- .''`. 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/1927842586.35924.1274795074336.JavaMail.root(a)md01.wow.synacor.com
From: Ferenc Wagner on 25 May 2010 11:30 Stephen Powell <zlinuxman(a)wowway.com> writes: > Ferenc Wagner wrote: > >> Stephen Powell <zlinuxman(a)wowway.com> writes: >>> >>> Both grub-legacy and grub-pc use sectors on the hard disk outside of >>> the master boot record and outside of a partition ... >> >> You may want to try extlinux, it works much like LILO in this respect. > > It does not use the master boot record. It relies on a master boot > record program to chain load it from the partition boot sector. (I > use the mbr package for that.) The extlinux package itself also contains an mbr.bin, which you can use (it's strong point is probably EBIOS support). > 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. > 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). -- Cheers, Feri. -- 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/874ohwt3td.fsf(a)tac.ki.iif.hu
From: Joachim Wiedorn on 25 May 2010 16:40 Harald Braumann <harry(a)unheit.net> wrote on Tue, 25 May 2010: > > On simple standard system -- one disk, one kernel in /boot, no fancy > stuff -- it works quite well. This is enough to use grub2 for new installing of Debian. > On other systems it often breaks miserably. Updates leave my system > unbootable every other time. One major problem are incompatible > versions of the boot loader installed in the MBR and grub.cfg. > > Currently, automatic installation of grub in the MBR is a no-go for me, > because of #554790 but I can't prevent grub from automatically > updating grub.cfg which leads to incompatible versions, hence an > unbootable system. And these problems say, we still need an alternative - I would say: LiLO. William Pitcock <nenolod(a)dereferenced.org> wrote on Sat, 22 May 2010: > > After some discussion about lilo on #debian-devel in IRC, it has pretty > much been determined that kernel sizes have crossed the line past where > lilo can reliably determine the payload size. But not all kernels are to large - especially the custom kernels - and LiLO can be used for this special situation. Until which size of kernel is LiLO usable? My suggestion / recommendation is now: a) using grub2 as default boot manager for new installations (d-i) and for updating grub. b) provide LiLO in squeeze as alternative for grub2. The limitations must be said while installing the lilo package. I think it must not be a proposal in d-i. Because I still use LiLO for all my systems, I could support the maintaining of LiLO. Would this a way for you, William? Fondest regards, Joachim Wiedorn
From: Stan Hoeppner on 25 May 2010 19:00
Joachim Wiedorn put forth on 5/25/2010 2:37 PM: > Because I still use LiLO for all my systems, I could support the > maintaining of LiLO. Same here. The last thing I need is for my next distribution upgrade to try to forcibly remove LILO and the current MBR, and then install Grub2, bricking my servers in the process. Or, just as bad, leaving the MBR in tact, but removing LILO from the system, and thus giving me no way of installing a new kernel down the road without manually installing/configuring Grub2, which I have zero experience with, and no guarantee such a process would work. It all boils down to this: In my environment, LILO works very well, is not broken, nor will it be broken in any foreseeable future due to kernel size. I use small custom kernels, no initrd, only the drivers built in for the specific hardware in the box. If someone can guarantee me that a dist upgrade process where LILO gets replaced by Grub2 is seamless, and won't brick my systems under any circumstances, then I might have an open mind on this. As things stand now, from everything I've read, I fear replacing LILO with Grub2 during an upgrade. -- Stan -- 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/4BFC5659.1030305(a)hardwarefreak.com |