lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Stephen Powell on 29 May 2010 10:50 On Fri, 28 May 2010 21:26:01 -0400 (EDT), Stan Hoeppner wrote: > Stephen Powell put forth on 5/28/2010 9:45 AM: >> The problem can be circumvented by taking an image backup >> instead of a logical backup, but that gets into special backup >> requirements. > > Can you mix and match? Does the image backup grab the entire disk or does it > work at the partition level? Can you, say, do an image backup of the MBR and > boot sector and the /boot partition, and then use file backup on the rest of > the disk. I'm not sure. But the whole point is for the backup people to be able to backup and restore a Linux server using the same procedure as they would for a Windows server. And their standard method is to take a logical backup of the entire disk. > > What backup software are you using that can take an image backup of a Linux > boot disk? Does it install a local agent for this? Or are you booting from > SAN? If so, you should have all kinds of backup flexibility, depending on > whose storage arrays you use. The machine is backed up by doing a PXE network boot directly from the hardware BIOS. The backup client does not exist on the hard drive that is being backed up. It is downloaded over the network, just as the netboot operating system is. The backup itself is done by connecting to a backup server and sending the data over the network. There is no local tape drive or anything of that nature. The restore procedure is similar. Yes, there is backup flexibility. But the whole goal here is to make the backup process standard for every server, regardless of whether it runs Windows or Linux. I don't want the backup people to have to make a decision. "OK, now let's see. Is this a Linux server or a Windows server? If it's a Linux server I have to remember to take the backup this special way. Otherwise, I do it the standard way." They'll forget. Or a new guy will come along who doesn't know to do it differently for a Linux server and he won't do it right. And then, if we have to restore from the backup that wasn't taken the proper way, the machine won't boot. And then Linux looks bad. I want the standard method that they use for Windows machines to work for a Linux server too. And as long as I live within the restrictions of supported file systems and boot loaders, the backup and restore software understands the file system and can backup the disk on a file-by-file basis, and the restore software knows how to patch the boot loader after the restore to make the machine bootable. As time goes on, these restrictions are getting more restrictive. And we are looking at alternatives to our existing backup software. But for now, I have to live within these restrictions. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/115102933.148780.1275144536082.JavaMail.root(a)md01.wow.synacor.com
From: Andreas Barth on 29 May 2010 14:50 * Stephen Powell (zlinuxman(a)wowway.com) [100523 21:21]: > On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: > > 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. We're speaking about #505609 I assume? I'm not sure this bug requires an removal of lilo (see below), however I think this means we should strongly discourage usage of lilo. > > (1) The release notes need to be updated to reflect that lilo is no > > longer a bootloader option; The release notes should be updated in case we keep lilo that we recommend to move to another boot loader now. > > (2) The debian-installer team needs to remove the lilo-installer udeb; This should indeed happen - if someone activly requires lilo, then doing it by hand should be ok-ish. > I am not a Debian package maintainer or a Debian developer. I am just an > ordinary system administrator. So I'm sure that my opinion will not count > for much. But I am opposed to the removal of lilo. Both grub-legacy and > grub-pc use sectors on the hard disk outside of the master boot record > (cylinder 0, head 0, sector 1). In other words they use cylinder 0, head 0, > sector 2 and possibly subsequent sectors on cylinder 0 head 0. This breaks > the design of the backup software that my employer uses. This backup software > backs up the master boot record and all partitions; but since the extra > sectors used by grub-legacy and grub-pc are outside the master boot record > and are not part of any partition, they don't get backed up. Consequently, > if we have a hard drive failure and restore from a backup, we have an > unbootable machine. Lilo uses only the master boot record. A lilo-booted > machine can be backed up and restored with our existing backup software > just fine. Given these requirements, I wouldn't use grub-pc even if it > were bug free and well documented. (But neither is the case!) Would it be possible to move (perhaps optionally) the extra grub sectors into an (perhaps dummy) partition (this question is for the grub2-people)? Would that be ok for you? > As for the claims that kernels are too big now, I find that hard to > believe, especially now that we have the large-memory option available. > The standard stock Debian kernel image file that I use for Squeeze, > vmlinuz-2.6.32-3-686, is currently 2234080 bytes. Are you trying to tell > me that there's no room for a 2M kernel below the start of the EBDA? > > I am able to load *both* the kernel *and* the initial RAM filesystem > below the EBDA (i.e. the large-memory option is not used) if I use > MODULES=dep instead of MODULES=most in the initial RAM filesystem > under Lenny. I'll bet I can do it with Squeeze too. This sounds like we should add an wrapper around lilo that warns that lilo is deprecated and warns if the images are too large. Andi -- 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/20100529184041.GK13148(a)mails.so.argh.org
From: Stephen Powell on 29 May 2010 16:50 On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote: > Stephen Powell wrote: >> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: >>> 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. >> > > We're speaking about #505609 I assume? I hope not. Strictly speaking, 505609 is not a lilo bug. The key is that he was still able to boot his old kernel that had been de-installed. That's a sure sign that lilo's map installer did not get run during the kernel upgrade process. It used to be that if do_bootloader = yes was specified in /etc/kernel-img.conf that installing a new kernel would cause lilo to be run. That is no longer the case. "update-initramfs -u ..." will cause lilo to be run if this option is set; but "update-initramfs -c ..." (or mkinitramfs ...) which is what is run during installation of a new kernel, will not. I have created my own hook script to fix that problem on my system. Strangely, though, "do_bootloader = yes" in /etc/kernel-img.conf still causes zipl to be run during kernel installation on the s390 platform. Something must have changed in the kernel maintainer script or in update-initramfs that causes the lilo map installer to not be run anymore under conditions that used to cause it to be run. Look carefully at the console log. There is no output from the map installer until he manually runs lilo. He apparently thinks that running lilo from the command line simply lists the installed kernels. No. Running lilo from the command line is what fixed the problem. If there's a bug here, it's somewhere else in the kernel installation process, not in lilo itself. If this so-called bug in lilo is what prompted the decision to drop lilo, then the decision was based on bad data. lilo, at least in this case, is working as designed. The problem is that the lilo map installer did not get run during the kernel installation process. I've helped a number of people on debian-user with problems like this, and in every case so far running lilo at the command line fixed the problem. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/267435255.153128.1275165812236.JavaMail.root(a)md01.wow.synacor.com
From: Stan Hoeppner on 29 May 2010 23:40 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? -- 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/4C01DD1C.1090706(a)hardwarefreak.com
From: Stan Hoeppner on 29 May 2010 23:50
Tom H put forth on 5/28/2010 10:55 PM: > On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner <stan(a)hardwarefreak.com> wrote: >> Roger Leigh put forth on 5/28/2010 11:39 AM: > >>> For the most part, grub is a vast >>> improvement over LILO, and except for the odd corner cases which >>> grub doesn't cover, >> >> In what way is it a vast improvement over LILO? I've never had a problem with >> LILO. It's always "just worked", which is what a bootloader should do. So >> how exactly would grub be a better choice for me? > > The reverse argument can be made too. Both grub1 and grub2 just work. > Unless you are continually installing dual- and triple-boot this or > that, you are not going to be changing you config continually no > matter what bootloader you use and you will therefore not be > interacting with it that much. So, except for Stephen P's case, what's > the big deal? I frequently roll new kernels from kernel.org source using the Debian installation method, once every couple of months. I'm very comfortable with using LILO for this. I've pretty much zero experience with Grub (any version). If something goes wrong converting from LILO to Grub2, I'm screwed. And I'll probably have an unwanted and unneeded learning curve while continuing my current practice of rolling kernels frequently. Please don't debate the merits of customs kernels. I have very valid reasons for doing so. Let's focus on why or why not Grub2 will work for my needs, and not hose my systems either during the migration from LILO to Grub2, or installing custom kernels after the fact. -- 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/4C01DFB1.8010307(a)hardwarefreak.com |