lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Paul E Condon on 30 May 2010 11:40 On 20100529_223556, Stan Hoeppner wrote: > thib put forth on 5/28/2010 9:44 PM: > > > * If yes, should it still be presented as an "expert" option in d-i? > > Why not, I guess. If not, should extlinux be extensively tested to be > > provided as an alternative choice in d-i? I really don't know how much > > work would be needed for this. > > I'm far more concerned at this point with distribution upgrades than new > installs. I've a number of production Lenny servers all using LILO. What > will happen to the bootloader config on these machines when I perform a dist > upgrade after Squeeze becomes Stable? These machines all use custom rolled > kernels from kernel.org source (installed the Debian way), if that makes any > difference. Also, the kernel images are in /boot, not in / with the > traditional symlinks. > > My gut instinct is that due to the above reasons and possibly others, the next > dist upgrade is going to hose all my production servers whilst trying to > forcibly convert them to Grub2. Is my instinct correct? Yes, but ... I don't have anything as difficult to manage as you. But I am also far less adept. Long ago I gave up on dist-upgrade as a thing I wanted to do. I think I stopped using it even before it was renamed to dist-upgrade. Instead, I devote a few GB of hard disk to multiple partitions on which I can install successively newer releases of Debian, but only the parts that change in the new release. Thanks to HFS it is easy to determine which those are. I make a new clean install in a newly formatted partion. If it doesn't work, I can reboot back into what I had been running minutes before. It took me a while to work out all the kinks, but it is well worth the trouble. As an added benefit of this way, I mount the older root partition under a special non-standard mount point in the new installation. If(When) I get into trouble, I can refer to that partition to see how things were set up before I started mucking about. I know this is a waste of disk space, but it is impossible to buy a HD so small that it cannot hold several full installations of Debian/GNU/Linux. I suggest you rearrange your disks to make room for additional base-installs. Practice doing Lenny to Lenny transitions to make sure you have your plan fully worked out. And then, wait for Squeeze with the sure knowledge that you can reboot back into your existing software. I cannot believe Grub2 will remain in its current state of disarray when release of Squeeze finally happens. The module that finds pre-existing installs and adds them to the boot menu seems to work but when you do reboot at the end of the install process, the installations that were listed as having been found are not there in the boot menu. Just issue update-grub and reboot again. It is fixed. Does this post give you warm fuzzies about the coming release? -- Paul E Condon pecondon(a)mesanetworks.net -- 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/20100530153745.GA29283(a)big.lan.gnu
From: Stephan Seitz on 30 May 2010 12:30 On Fri, May 28, 2010 at 11:55:58PM -0400, Tom H wrote: >The reverse argument can be made too. Both grub1 and grub2 just work. I accept this argument for grub1. Yes, I never had problems with grub1, but grub2 is simply not ready for prime time. While grub2 works for simple workstations, it canât redirect its output to serial console and monitor like grub1 and it doesnât understand XEN hypervisor kernels. As long as grub2 has so many missing features it should not be considered default bootloader in Debian. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: stse(a)fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |
From: Sven Joachim on 30 May 2010 13:20 On 2010-05-30 18:29 +0200, Stephan Seitz wrote: > On Fri, May 28, 2010 at 11:55:58PM -0400, Tom H wrote: >>The reverse argument can be made too. Both grub1 and grub2 just work. > > I accept this argument for grub1. Yes, I never had problems with > grub1, but grub2 is simply not ready for prime time. > > While grub2 works for simple workstations, it can't redirect its > output to serial console and monitor like grub1 and it doesn't > understand XEN hypervisor kernels. The main problem with grub1 is the same as with lilo: there is no upstream maintainer, and crucial parts of the code are undocumented and not understandable¹. > As long as grub2 has so many missing features it should not be > considered default bootloader in Debian. So which bootloader should be the default? Grub1 is also lacking important features, albeit different ones than grub2 (e.g. ext4 support). Sven ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#237 -- 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/87eigt5n7s.fsf(a)turtle.gmx.de
From: Stan Hoeppner on 30 May 2010 16:10 Paul E Condon put forth on 5/30/2010 10:37 AM: > On 20100529_223556, Stan Hoeppner wrote: >> I'm far more concerned at this point with distribution upgrades than new >> installs. <snip> >> >> My gut instinct is that due to the above reasons and possibly others, the next >> dist upgrade is going to hose all my production servers whilst trying to >> forcibly convert them to Grub2. Is my instinct correct? > I don't have anything as difficult to manage as you. These systems are a breeze to manage currently, not difficult at all. > But I am also far > less adept. Long ago I gave up on dist-upgrade as a thing I wanted to > do. I think I stopped using it even before it was renamed to > dist-upgrade. Instead, I devote a few GB of hard disk to multiple > partitions on which I can install successively newer releases of > Debian, but only the parts that change in the new release. Thanks to > HFS it is easy to determine which those are. I make a new clean > install in a newly formatted partion. If it doesn't work, I can reboot > back into what I had been running minutes before. Herein lies the problem with changing bootloaders. Your "safe recovery" methodology (which is quite smart btw and I've used it myself over the years) goes out the window in this case because the bootloader controls loading every one of your parallel installations. If the bootloader gets hosed, you can't load any of them. You're fscked. > I know this is a waste of disk space, but it is impossible to buy a HD > so small that it cannot hold several full installations of > Debian/GNU/Linux. Not a waste of space at all, but a very good use of a tiny percentage of the space available on current drives. With 500GB drives at ~$50 USD, and a typical Debian install being ~5GB, you could have 10 parallel installations using only 10% of the drive's space. That's a smart investment in potential severe headache prevention. Ten parallel installs is extreme, but I'm simply demonstrating the "cost" of storage aspect. > I suggest you rearrange your disks to make room for additional base-installs. > Practice doing Lenny to Lenny transitions to make sure you have your plan > fully worked out. And then, wait for Squeeze with the sure knowledge that > you can reboot back into your existing software. What you suggest here doesn't really come into play. This isn't an issue of going from Lenny to Squeeze. This isn't about different package revs. It's not about Squeeze having problems and wanting to boot back into Lenny. The problem, in and of itself, is booting. Period. There is not way to test it but to replace LILO with Grub2 and see if the system boots afterward. I cannot do this on production servers, obviously. Cloning drives to play with on a lab machine would be a good idea, but I can't take production servers offline to clone the disks. The only real way to test this is to build a fresh Lenny test rig from scratch with LILO, tweak it to match my production systems, then install Grub2 and see what, if anything, breaks, and figure out how to get around the breakage. > I cannot believe Grub2 will remain in its current state of disarray > when release of Squeeze finally happens. The module that finds > pre-existing installs and adds them to the boot menu seems to work but > when you do reboot at the end of the install process, the > installations that were listed as having been found are not there in > the boot menu. Just issue update-grub and reboot again. It is fixed. I hope it's ready for prime time by then. > Does this post give you warm fuzzies about the coming release? I'm not worried about the release. I've taken these machines through four live online apt upgrades all the way back from Woody to Lenny, 4 releases, without major issues. However, the bootloader never changed. LILO all the way through. This upgrade will be radically different in this respect. I guess I could start looking for an aftermarket bootloader to avoid this mess altogether, although I'd rather use a FOSS solution. Maybe extlinux. From what others have said here it shows some promise. -- 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/4C02C573.4070902(a)hardwarefreak.com
From: Stephan Seitz on 30 May 2010 17:00
On Sun, May 30, 2010 at 07:11:19PM +0200, Sven Joachim wrote: >The main problem with grub1 is the same as with lilo: there is no >upstream maintainer, and crucial parts of the code are undocumented >and not understandable¹. But at least grub1 is working in a wider field than grub2. And lilo is still working, too. Maybe not with the current Debian kernel, but it works for people building their own kernel. >So which bootloader should be the default? Grub1 is also lacking >important features, albeit different ones than grub2 (e.g. ext4 >support). Maybe, but ext4 support is not really crucial. Simply make /boot ext2. I would say, the default bootloader should be grub1, expert installation can offer grub2 as well. Lilo should be in the distribution as well, so people can switch after installation. At least for the next release. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: stse(a)fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | |