Re: lilo removal in squeeze (or, "please test grub2")
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
Reply to: