lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Stephen Powell on 1 Jun 2010 10:50 On Tue, 01 Jun 2010 10:20:09 -0400 (EDT), thib wrote: > > 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. I am still hopeful that lilo will not be dropped from the distribution. I think it would be a mistake, and I believe lilo has many more years of useful life than most people think it does (or should have) at this point. But if they drop it, I'm prepared. I have already downloaded the source code, and I will build my own packages if I have to. For now at least, I *have* to use lilo for reasons previously discussed. -- .''`. 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/1600857906.194739.1275403757931.JavaMail.root(a)md01.wow.synacor.com
From: Daniel Barclay on 1 Jun 2010 11:00 Stan Hoeppner wrote: > The > problem, in and of itself, is booting. Period. There is [no] 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. How about temporarily booting from an alternate partition, disk, etc? For example: 1. Install a second instance of your current LILO installation on some other boot device. - Then boot from that device to make sure that booting from that device can boot your system normally. If not, boot from your normal boot partition, try to fix that second LILO installation, and try again. Once it works, proceed to step 2. 2. Install Grub2 on the main boot device. - Try booting. - If doesn't work, reboot from the device with the backup LILO installation in step one and try to fix the Grub2 installation, and try again. Once it works, you're done. Actually, you'd probably want to install the new loader (Grub2) on an alternative device first, so your system by default would still boot using the old boot loader setup. Then, when you think you have your Grub2 configuration worked out, create and test the LILO backup boot device as above, and install Grub2 on your main boot device. If it works, you're done; if it doesn't, you can reboot from the LILO backup boot device to work on your main-device Grub2 installation. That takes several reboots rather than just one, but then it means you're never more than one reboot away from a working system, rather than possibly dead in the water until you can figure out and fix whatever the problem is (either by fixing the Grub2 problem or by booting enough (viaa rescue disc) to re-install your LILO configuration. Daniel -- 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/4C051C29.60006(a)fgm.com
From: John Hasler on 1 Jun 2010 13:00 Stephen Powell writes: > Actually, I've been tempted to volunteer to become the upstream > maintainer for lilo myself. Please do so. > 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. Set up a Web site (I suggest tuxfamily.org for hosting) and ask for help. You'll find that there are people who can and will do the coding but who don't want the hassle and responsibility of running the project. -- John Hasler -- 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/87mxved91p.fsf(a)thumper.dhh.gt.org
From: Andrei Popescu on 1 Jun 2010 14:20 On Ma, 01 iun 10, 10:25:42, Stephen Powell wrote: > > 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. [...] > 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. Maybe it would be enough if you just take over the maintenance of the Debian package. After all, you are very familiar with lilo and run it on many machines. If the code is as stable as I've read in this thread it shouldn't be too difficult. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
From: Stephan Seitz on 1 Jun 2010 15:50
On Mon, May 31, 2010 at 01:29:15AM +0300, Andrei Popescu wrote: >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. But I donât think that everyone will switch to ext4 with the next release, even if they install new systems. Does the squeeze installer support ext4 or is this the new filesystem if you donât choose one? Besides we are not talking about having grub1 for all eternity. If grub2 will support all features of grub1, we can replace the bootloader in squeeze + 1. >Is it just me or does this sound like the KDE3 -> KDE4 debate all over >again? I donât know, I donât use KDE. ;-) But if I have to use KDE to help another user, I feel more comfortable with KDE3. KDE4 looks terribly and I donât find anything. >software (Stephen's case), but we have to face it: >* LILO is not developed anymore >* Grub1 is not developed anymore Yes, but for now both bootloader are still working. They may not support ext4, but they do support things grub2 doesnât. >Unless there are people interested in further developing those code >bases they will be gone sooner or later. And my feeling (as a Yes, but in the time for squeeze + 1, grub2 may get all missing features from grub1. Then we can at least through away grub1. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: stse(a)fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | |