lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Stefan Monnier on 31 May 2010 13:30 >> Maybe, but ext4 support is not really crucial. Simply make /boot ext2. Actually ext3 works fine. > Having /boot on a separate partition for robustness, security or > advanced features (encrypted LVM and stuff) is one thing, but having it > because the default bootloader doesn't support current (ext4) and future > (btrfs) filesystems seems like a hack to me. Until the bootloader is itself a Linux kernel (so it can directly use Linux fs drivers), the bootloader will always be playing catch-up. I've been using a /boot partition forever, because I have / on LVM. Nowadays, I use Grub2 on several of my machines, so I could put /boot directly in LVM, but why bother? The thing that I would find more useful is to get rid of things like update-grub, and instead have the bootloader generate the bootlist on the fly. I.e.: install the bootloader, and never touch it again. > Also, the config has become so complicated you need another config > file (/etc/default/grub) to configure how it will be generated :( Yes, that sucks as well. > * LILO is not developed anymore > * Grub1 is not developed anymore I've used Lilo a few times in the past and found it very useful because of its simplicity: tell it where are the files to boot, and on which drive to install itself, and that's it. For Grub1 (and worse for Grub2), you have to worry about the difference between "where the files are now" vs "where the files will be when I boot", then multiply that by the different sorts of files (Grub2 modules, Grub config file, kernel/initrd files) and then you have to add the fact that the grub-install scripts try to hide these differences from you. E.g. I could never use Grub1's "grub-install" and be confident of the result, so I always used /usr/sbin/grub to install Grub1 instead. With Grub2 this is not even an option, so I use `grub-install' and then I just hope for the best. Luckily, my setups are usually simple. Stefan -- 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/jwvr5ksxaf1.fsf-monnier+gmane.linux.debian.user(a)gnu.org
From: Stephen Powell on 31 May 2010 22:00 On Sun, 30 May 2010 03:48:50 -0400 (EDT), Andrei Popescu wrote: > On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote: >> >> 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? > > Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the > upgrade ;) Does anybody know what happened to John Coffman (the last known upstream maintainer for lilo)? Did he get bored with maintaining lilo? He was doing a great job. I think he's the one that added lba32 support. He seems to have fallen off the face of the earth. Did he die or what? -- .''`. 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/1734713713.184635.1275357460852.JavaMail.root(a)md01.wow.synacor.com
From: Stan Hoeppner on 1 Jun 2010 05:40 Stephen Powell put forth on 5/31/2010 8:57 PM: > On Sun, 30 May 2010 03:48:50 -0400 (EDT), Andrei Popescu wrote: >> On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote: >>> >>> 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? >> >> Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the >> upgrade ;) > > Does anybody know what happened to John Coffman (the last known upstream > maintainer for lilo)? Did he get bored with maintaining lilo? He was > doing a great job. I think he's the one that added lba32 support. > He seems to have fallen off the face of the earth. Did he die or what? That's a good question. I was just digging around (not very thoroughly) a few minutes ago and I can't find any recent posts from him via Google. -- 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/4C04D533.8060405(a)hardwarefreak.com
From: thib on 1 Jun 2010 10:30 Stan Hoeppner wrote: > LILO isn't broken and it works well enough for may folks such as myself. We > should have the option of keeping it, as an installable package, until _we_ > feel we need to change to something else. It's as much a philosophical issue > as it is a practical one. There is no legitimate reason LILO can't be left in > the distro as an optional package, just as it is now with Lenny. > > It's difficult to be "positive" when unnecessary change is being forced down > one's throat. In the worst case, people will maintain unofficial packages in unofficial repositories. In fact, I'm not even sure there's still much to maintain with the package.. just keep it around. It's very true, official support is best, but I wouldn't go as far as saying the change is "forced". This is all still open and hackable software, in the end, and "hack" here means pinning lilo and grub-pc, which should be it. It will still be manageable by apt. -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/4C051719.7080607(a)stammed.net
From: Stephen Powell on 1 Jun 2010 10:30
On Tue, 01 Jun 2010 05:32:37 -0400 (EDT), Stan Hoeppner wrote: > From a seasoned sysadmin perspective, a "vendor" forced change away from > something as critical as a bootloader, causes immediate push back. In LILO's > current state, and given the way I run kernels, I could likely used LILO 22.8 > for the next 10 years without a problem, without any code changes. So it > doesn't matter to me if it's currently maintained or not. Actually, I've been tempted to volunteer to become the upstream maintainer for lilo myself. I have worked on boot loaders before, on other platforms. For example, I have made local modifications to the "Stand Alone Program Loader" that ships with IBM's z/VM Operating System. The SAPL is used as the boot loader for the CP (Control Program) component of z/VM, as well as other stand-alone programs such as DDR (DASD Dump / Restore) and DSF (Device Support Facilities). I won't go into the details of what those local modifications are because they are not relevant here. The point is that I've worked on boot loaders before, and I like working on low-level stuff. However, although the SAPL is written in assembly language, it is written in s390 assembly language, which is totally different from x86 assembly language. I don't know x86 assembly language at all. And I am just learning C. So reason prevails over emotion and I don't volunteer. I am simply not qualified. Someday I may be, but not today. > > The reason grub2 is being forced upon us all is the need of the "desktop" > users who want a 20MB kitchen sink kernel and initrd that will support any > piece of hardware on any machine they throw at it. Many sysadmins don't want > or need that, and we're being forced to change our bootloader due to the > perceived needs of others. Actually, that is largely a myth. Lilo's only release-critical bug turned out not to be a bug at all. It was this "bug" that gave rise to the belief that stock kernels were getting too big for lilo to load. But the problem was that a new kernel was installed without lilo being run. And this is apparently the result of changes made to the stock kernel maintainer scripts that cause "do_bootloader = yes" in /etc/kernel-img.conf to not be honored anymore, as it once was. Whether this is a bug or a feature in the kernel maintainer scripts I am not sure. But I am sure that this is not a lilo bug. To the best of my knowledge, even the largest of today's "kitchen sink" kernel and initial RAM disk image combinations can be loaded by lilo with no trouble at all if the large-memory option is used and the BIOS support memory addressing above 16M, which is the case for almost all modern BIOS. (The 16M limit is apparently a hold-over from the days of the 80286 chip.) And if for some reason the BIOS do not support the large-memory option, simply using MODULES=dep instead of MODULES=most in your initial RAM file system is usually sufficient to allow lilo to work, even with these large kernels. (As a side note, it seems to me that the equivalent of the large-memory option should be possible even if the BIOS do not support it by asking the BIOS to read a block into storage below the 16M line and then copying the block above the 16M line under program control. Conceptually at least, it seems to me that that shouldn't be too hard. But I don't know.) > > LILO isn't broken and it works well enough for may folks such as myself. We > should have the option of keeping it, as an installable package, until _we_ > feel we need to change to something else. It's as much a philosophical issue > as it is a practical one. There is no legitimate reason LILO can't be left in > the distro as an optional package, just as it is now with Lenny. > > It's difficult to be "positive" when unnecessary change is being forced down > one's throat. I agree. But I also sympathize with the poor package maintainer who is essentially functioning as both package maintainer and upstream support. That cannot go on forever. Someone has to step up to the plate and take over upstream support. I'd do it myself if I had the requisite skills. But as of now, I just don't. Perhaps one of the reasons that no-one has stepped up to the plate to take over upstream support is the perception that lilo can't handle today's large kernels and therefore we should just let it die. That is simply not true. I use stock kernels most of the time. And I use lilo. And I've never had a bit of trouble. I just have to make sure by the use of hook scripts that lilo actually gets run when a kernel is installed or updated. And that's easy enough to do. -- .''`. 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/112473223.193825.1275402342029.JavaMail.root(a)md01.wow.synacor.com |