Re: Considerations for lilo removal
Michael Banck [EMAIL PROTECTED] writes: On Mon, Jun 16, 2008 at 11:03:10AM +0200, Goswin von Brederlow wrote: I don't really see this as a bug, certainly not as grave. The problem seems to be that lilo simply can't handle large images and the default ramdisk just has now hit that limit on amd64. So it's broken on amd64 for the stock Debian kernel, AIUI. Looks like a grave bug to me. With the default initramfs-tools.conf. So initramfs-tools has the grave bug. :) It should not be using MODULES=most on amd64 or reduce the list of modules. Certainly the floppy module does not have to be in the initrd. Michael MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Wouter Verhelst [EMAIL PROTECTED] writes: On Mon, Jun 16, 2008 at 12:31:49AM -0500, William Pitcock wrote: Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. grub doesn't work with root-on-LVM, or other similar cryptic installations. There, your only option is lilo. grub2 does. Is that going to happen for lenny? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:19:03AM +0200, Mike Hommey wrote: *SKIP* OTOH, aren't most of these choosing lilo over grub only doing so by habit ? OTOH, aren't most of theses choosing emacs over vim only doing so by habit? -- Torvalds' goal for Linux is very simple: World Domination -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Le mercredi 18 juin 2008 à 09:52 +0300, Eric Pozharski a écrit : On Mon, Jun 16, 2008 at 11:19:03AM +0200, Mike Hommey wrote: OTOH, aren't most of these choosing lilo over grub only doing so by habit ? OTOH, aren't most of theses choosing emacs over vim only doing so by habit? The day where my bootloader has the same impact on my habits than my text editor, please remind me to throw my computer out of the window and not buy another one. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for lilo removal
On Wed, Jun 18, 2008 at 01:28:36PM +0200, Josselin Mouette wrote: Le mercredi 18 juin 2008 à 09:52 +0300, Eric Pozharski a écrit : On Mon, Jun 16, 2008 at 11:19:03AM +0200, Mike Hommey wrote: OTOH, aren't most of these choosing lilo over grub only doing so by habit ? OTOH, aren't most of theses choosing emacs over vim only doing so by habit? The day where my bootloader has the same impact on my habits than my text editor, please remind me to throw my computer out of the window and not buy another one. Or whenever you spend more than an hour a day using your bootloader. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:19:03AM +0200, Mike Hommey wrote:
We still very regularly get installation reports where people use
lilo rather than grub, so it must still have a fairly significant
user base. I would say that the activity on the bug report shows
the same.
OTOH, aren't most of these choosing lilo over grub only doing so by
habit ?
Not me. I switched from lilo to grub in almost all of my computers,
but I had problems with the grub 'map' command ('map-drive' in lilo)
in one of them so I went back to lilo.
I don't know if it was fixed, though, now I don't need that feature
anymore.
--
Alberto García González
http://people.igalia.com/berto/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 12:31:49AM -0500, William Pitcock wrote: Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. grub doesn't work with root-on-LVM, or other similar cryptic installations. There, your only option is lilo. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Wed, Jun 18, 2008 at 01:49:40PM +0200, Mike Hommey wrote: On Wed, Jun 18, 2008 at 01:28:36PM +0200, Josselin Mouette wrote: Le mercredi 18 juin 2008 à 09:52 +0300, Eric Pozharski a écrit : On Mon, Jun 16, 2008 at 11:19:03AM +0200, Mike Hommey wrote: OTOH, aren't most of these choosing lilo over grub only doing so by habit ? OTOH, aren't most of theses choosing emacs over vim only doing so by habit? The day where my bootloader has the same impact on my habits than my text editor, please remind me to throw my computer out of the window and not buy another one. Or whenever you spend more than an hour a day using your bootloader. That usually only happens when you threw your computer out of the window and it now doesn't boot anymore. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Wed, Jun 18, 2008 at 07:20:36PM +0200, Wouter Verhelst wrote: grub doesn't work with root-on-LVM, or other similar cryptic installations. There, your only option is lilo. Actually, that's not true. I use root-on-LVM with a /boot partition and grub 2 (and previously, grub 0.9x). It is my understanding that if you don't have a /boot partition, you do need lilo, however. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Considerations for lilo removal
* Mike Bird | FWIW, adding -9 to the gzip in mkinitramfs gives a | 0.5% saving, which may help with some marginal cases. Re-adding -9 to the update-initramfs call makes update-initramfs take about three times as long to run on this system, so at least I would rather not have that switched on by default. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:55:49PM +0300, Riku Voipio wrote: Having one well working tool is better than having multiple mediocre, buggy tools to choose from. The problem is that we do not have one well working tool. Grub certainly does not qualify as such and there is no hope it ever will. So until grub2 reaches perfection or somebody writes a brand new bootloader, we're better with two imperfect bootloaders that have a different set of bugs. Grub and Lilo do a simple well defined task. Simple? Well defined?!? Gimme' the crack you're smoking... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Jun 17, Brian May [EMAIL PROTECTED] wrote: Frans Pop wrote: AFAIK grub (at least the default legacy version) also still has problems with / on XFS. That's the one other case where D-I automatically falls back to lilo. I think you mean /boot on XFS. Having / as XFS seems to work fine for me... There is nothing wrong with a XFS /boot except grub being unable to support it, and anyway this cannot be changed on installed systems. -- ciao, Marco signature.asc Description: Digital signature
Re: Considerations for lilo removal
Riku Voipio wrote: On Mon, Jun 16, 2008 at 11:12:53AM -0400, David Duggins wrote: I would also have to say that the Linux Community has always been about freedom and choice. Not everyone agrees[1] about the choice part. Having one well working tool is better than having multiple mediocre, buggy tools to choose from. mediocre buggy tools? It work very nice on some configuration, and it very simple. Should we remove all text editor that doesn't have doctor mode, because some of us use such bloated module? Really: lilo is simple and good for some configuration, and is more KISS designed that grub. And the transition cost? Should we learn a new tools in next few months? grub (and any boot loader) are very important: a miss-configuration, miss-handle cause a non bootable system, and it is also very different to other sysadmin commands, thus switching cost are very high, and our users (IMHO) are not ready for such costs. Let obsolete it for few years, but I consider removal of lilo in lenny one of the worse RC bug I saw. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Tue, 17 Jun 2008, Marco d'Itri wrote: On Jun 17, Brian May [EMAIL PROTECTED] wrote: Frans Pop wrote: AFAIK grub (at least the default legacy version) also still has problems with / on XFS. That's the one other case where D-I automatically falls back to lilo. I think you mean /boot on XFS. Having / as XFS seems to work fine for me... There is nothing wrong with a XFS /boot except grub being unable to support it, and anyway this cannot be changed on installed systems. And yet it has worked for me every single time I tried it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Am Di den 17. Jun 2008 um 12:14 schrieb Peter Palfrader: AFAIK grub (at least the default legacy version) also still has problems with / on XFS. That's the one other case where D-I automatically falls back to lilo. I think you mean /boot on XFS. Having / as XFS seems to work fine for me... There is nothing wrong with a XFS /boot except grub being unable to support it, and anyway this cannot be changed on installed systems. And yet it has worked for me every single time I tried it. Well, there was several problems in the past. The reason is that the script do a xfs_freeze and then try to install the boot loader on that file system. I do not know if this is fixed in the current version. However, starting install-grub in the first shell and then xfs_freeze -u in a second do fix the problem. But this is only a workaround. Gruß Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSFe4C5+OKpjRpO3lAQJoHgf+PleYFVpdHUcRzOQXbPkbZ0R2XFARjsxY tPJk4SkCIr4cId1uSUTcdssJfWFi45YnUkAjDvsZ2TBzxfXsWtNf2wT+dlPtc3Dy 0s/cEGkVZAenVWJcS7GSiWqQuPRZQTD6u9EvjEtS7omgoEhIgqsqBu9lLYHUpvGM yREW9RGvYhePMOJs8iuG6h/NX5bs8tghwPfMb6q48BjSF6keCfo3uaZnlXRNyT2W vSMxvtlSed17Gpl8jS97bA5ePbNLr8UAwovvbk5yZMTO5Oc/xBV/YeAyIHAlpI7k X5mKaMuyTwizcennKSAdRT0hBc/BNRgWUbpctCRtvJsZIuLQF1oP2A== =k6d6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, 2008-06-16 at 23:53 +0200, Frans Pop wrote: William Pitcock wrote: * Cope with the growing initramfs issue as best we can, e.g. by displaying a warning to the user that the kernel may not be bootable by lilo due to the 8MiB boundry in liloconfig. Having only a warning is not sufficient for the use of lilo in new installations! We really need lilo to fail there, which means a non-zero exit code. My warning is followed by exit(-1), actually. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:19:03AM +0200, Mike Hommey wrote: On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote: We still very regularly get installation reports where people use lilo rather than grub, so it must still have a fairly significant user base. I would say that the activity on the bug report shows the same. OTOH, aren't most of these choosing lilo over grub only doing so by habit ? I am usually using grub, but I still have some systems that don't boot with grub, and the vendor citing the usual we don't support Linux, our systems boot just fine with all flavours of Windows, go take a hike. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Le Monday 16 June 2008 07:31:49 William Pitcock, vous avez écrit : With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. I have lilo for the systems where I want /boot to be on LVM. What would you do for those installs ? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 09:08 +0200, Romain Beauxis wrote: Le Monday 16 June 2008 07:31:49 William Pitcock, vous avez écrit : With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. I have lilo for the systems where I want /boot to be on LVM. What would you do for those installs ? That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. lilo-22.8$ head debian/patches/01_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 I also like and use this feature. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote: On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. lilo-22.8$ head debian/patches/01_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. I think most lvm configurations are this way, so it works for most people using lvm lilo. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote: Hi, On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote: On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. lilo-22.8$ head debian/patches/01_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. Il will only work if all extents containing initramfs and kernel are contiguous and ordered on the physical volume. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Am Montag, 16. Juni 2008 schrieb William Pitcock: Hi, That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. On some of my boxes all filesystems are on LVMs and the Debian installer used lilo to boot the systems. It would be nice if these systems can still be used with future Debian versions. Please remove lilo only if there's a full replacement available. regards, Jörg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Mike Hommey [EMAIL PROTECTED] writes: On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote: Hi, On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote: On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. lilo-22.8$ head debian/patches/01_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. Il will only work if all extents containing initramfs and kernel are contiguous and ordered on the physical volume. Mike Why? Lilo looks up the block addresses of the file on the disk. Having the LV fragmented into several segments is no different from having the file fragmented in the filesystem. Having /boot be on a single PV, preferably the one with the bootblock should be totally sufficient. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
William Pitcock wrote: It seems like moving to grub for everything may be a good choice on the archs where lilo is used. Lilo has one killer feature that is totally missing from GRUB - the -R option. It allows me to upgrade a kernel on remote servers, knowing that if the upgrade fails, I will get the original kernel after a few minutes without asking a local hand to push the reset button. Until Grub has something similar, removing Lilo entirely seems like a bad idea to me. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
William Pitcock wrote: I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape That's just great. That means that whoever did this just broke an option that's been available in Debian Installer since forever: to choose lilo as bootloader rather than grub. And it seems for no other reason than cosmetically bring the RC count down as the BR shows that testing currently is not affected (still has 2.6.24). It really would be nice if the RT would would contact us (D-I team) before taking such actions, especially as we just had a fairly big discussion about a similar case. It can't be too hard to make the mental jump from $bootloader package to installation system. where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. We still very regularly get installation reports where people use lilo rather than grub, so it must still have a fairly significant user base. I would say that the activity on the bug report shows the same. Please keep the D-I team informed of where this is going. TIA, FJP signature.asc Description: This is a digitally signed message part.
Re: Considerations for lilo removal
William Pitcock [EMAIL PROTECTED] writes: Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. I don't really see this as a bug, certainly not as grave. The problem seems to be that lilo simply can't handle large images and the default ramdisk just has now hit that limit on amd64. The only bug there is imho is that the condition does not get detected and reported properly (patched lilo shoud be on mentors). The simple solution to is to not stuff so many modules into the initramfs. Using only needed modules reduces my initramfs by a factor of 3. So there is still a big margin for growth. And there are systems where grub simply doesn't work for some screwed up reason or another and a lot of people that prefer it. Removing it just because it has an avoidable size limit seems like a bad idea. With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. William MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:54:52AM +0300, Shachar Shemesh wrote: William Pitcock wrote: It seems like moving to grub for everything may be a good choice on the archs where lilo is used. Lilo has one killer feature that is totally missing from GRUB - the -R option. It allows me to upgrade a kernel on remote servers, knowing that if the upgrade fails, I will get the original kernel after a few minutes without asking a local hand to push the reset button. Until Grub has something similar, removing Lilo entirely seems like a bad idea to me. grub savedefault --default=2 --once Now, maybe debian just needs a nice wrapper around this. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:04:35AM +0200, Mike Hommey wrote: On Mon, Jun 16, 2008 at 11:54:52AM +0300, Shachar Shemesh wrote: Lilo has one killer feature that is totally missing from GRUB - the -R option. It allows me to upgrade a kernel on remote servers, knowing that if the upgrade fails, I will get the original kernel after a few minutes without asking a local hand to push the reset button. grub savedefault --default=2 --once Now, maybe debian just needs a nice wrapper around this. grub-reboot 2 -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 10:53:22AM +0200, Goswin von Brederlow wrote: Mike Hommey [EMAIL PROTECTED] writes: On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote: Hi, On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote: On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. lilo-22.8$ head debian/patches/01_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. Il will only work if all extents containing initramfs and kernel are contiguous and ordered on the physical volume. Mike Why? Lilo looks up the block addresses of the file on the disk. Having the LV fragmented into several segments is no different from having the file fragmented in the filesystem. AFAIK, lilo only stores the start of initrd and kernel images in CHS form. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote: We still very regularly get installation reports where people use lilo rather than grub, so it must still have a fairly significant user base. I would say that the activity on the bug report shows the same. OTOH, aren't most of these choosing lilo over grub only doing so by habit ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, 16 Jun 2008 11:19:03 +0200, Mike Hommey writes: On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote: We still very regularly get installation reports where people use lilo rather than grub, so it must still have a fairly significant user base. I would say that the activity on the bug report shows the same. OTOH, aren't most of these choosing lilo over grub only doing so by habit ? no. i for one detest grub, wholeheartedly. please don't remove lilo. regards az -- + Alexander Zangerl + DSA 42BD645D + (RSA 5B586291) So what if I have a fertile brain? Fertilizer happens. -- Larry Wall signature.asc Description: Digital Signature
Re: Considerations for lilo removal
William Pitcock [EMAIL PROTECTED] writes: With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. Debian Etch installs lilo without choice if XFS is used, so there should be a number of systems still using lilo for good reason. If we do not need lilo, then I will file a RM bug in the next couple of weeks. i still prefer lilo for systems on raid1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/08 04:19, Mike Hommey wrote: On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote: We still very regularly get installation reports where people use lilo rather than grub, so it must still have a fairly significant user base. I would say that the activity on the bug report shows the same. OTOH, aren't most of these choosing lilo over grub only doing so by habit ? Does it matter? Debian doesn't just have one web broswer, one MUA, one IM app, one scripting language, one word processor, one movie player, etc, etc, etc. So why should it only have one boot loader? - -- Ron Johnson, Jr. Jefferson LA USA Kittens give Morbo gas. In lighter news, the city of New New York is doomed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhWNnIACgkQS9HxQb37XmdjQACghOfpn0VHd4bTToJmCM2XCaBx Sv8AoLQ+vE3tpCOKd0DkG6k5yFNLruXN =fOMf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 19:27 +1000, Alexander Zangerl wrote: please don't remove lilo. It certaintly won't be happening in lenny. This may be revisited in lenny+1 though. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape Can either version of grub handle all the cases that lilo can? for example can either of them handle the situation where root is on lvm and there is not a seperate /boot partition? last I checked d-i defaulted to lilo in that situation. If not then removing lilo will leave d-i with no ability to install a bootloader in those situations and worse leave some users with no upgrade path. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 09:37:34AM +0200, Joerg Platte wrote: Am Montag, 16. Juni 2008 schrieb William Pitcock: Hi, That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. On some of my boxes all filesystems are on LVMs and the Debian installer used lilo to boot the systems. It would be nice if these systems can still be used with future Debian versions. Please remove lilo only if there's a full replacement available. Lilo is already removed from testing and will not be in lenny until somebody steps up and cares for it. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
(Dropping d-release for this part of the discussion.) On Monday 16 June 2008, Mike Hommey wrote: On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote: We still very regularly get installation reports where people use lilo rather than grub, so it must still have a fairly significant user base. I would say that the activity on the bug report shows the same. OTOH, aren't most of these choosing lilo over grub only doing so by habit ? In some cases, probably. But as it requires some fairly specific actions in D-I, especially in the default mode, I would expect it to be a conscious choice in a lot of cases. I also remember a number of reports _requesting_ that we support installing lilo instead of grub... And see also some of the other replies in this thread. AFAICT there is still a real demand for lilo. And wasn't Linux (or free software if you prefer) at least partly about choice anyway? AFAICT from a quick browse through the BR, the issue is only that the size of the initrd as generated by default by initramfs-tools with 2.6.25 has grown too large for lilo. Does this mean that server setups that do not use an initrd at all or that have small, targeted initrds should no longer be allowed to use lilo? Why not add a size check in lilo that just loudly bails out if the initrd is too large? As lilo has to be rerun anyway, that would at least inform users that there is a problem at kernel installation time instead of on the first reboot and they get a chance to correct things. signature.asc Description: This is a digitally signed message part.
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:03:10AM +0200, Goswin von Brederlow wrote: I don't really see this as a bug, certainly not as grave. The problem seems to be that lilo simply can't handle large images and the default ramdisk just has now hit that limit on amd64. So it's broken on amd64 for the stock Debian kernel, AIUI. Looks like a grave bug to me. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Le Monday 16 June 2008 12:03:09 Michael Banck, vous avez écrit : On some of my boxes all filesystems are on LVMs and the Debian installer used lilo to boot the systems. It would be nice if these systems can still be used with future Debian versions. Please remove lilo only if there's a full replacement available. Lilo is already removed from testing and will not be in lenny until somebody steps up and cares for it. Really that is not serious. The RC bug is a side effect as explained before, and just for that the package is removed while it is still part of the installer and very important to *many* users, without even communicating about it. I'm really disapointed of such a irresponsive behaviour. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
(Dropping d-release again.) On Monday 16 June 2008, peter green wrote: I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape Can either version of grub handle all the cases that lilo can? D-I currently does indeed fall back to lilo for _all_ /boot on LVM cases. When LVM is set up using guided partitioning D-I will always create a separate /boot partition though. AFAIK grub (at least the default legacy version) also still has problems with / on XFS. That's the one other case where D-I automatically falls back to lilo. signature.asc Description: This is a digitally signed message part.
Re: Re: Considerations for lilo removal
That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. Valid or not, the installer actually gives you lilo if you configure the partitions this way (in non-expert mode at least) without prompts, so many people will have this configuration and lilo without being aware that it is invalid. A proper migration away from lilo is necessary, rather than just dropping it. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Mike Hommey [EMAIL PROTECTED] writes: On Mon, Jun 16, 2008 at 10:53:22AM +0200, Goswin von Brederlow wrote: Mike Hommey [EMAIL PROTECTED] writes: On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote: Hi, On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote: On 2008-06-16, William Pitcock [EMAIL PROTECTED] wrote: That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. lilo-22.8$ head debian/patches/01_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. Il will only work if all extents containing initramfs and kernel are contiguous and ordered on the physical volume. Mike Why? Lilo looks up the block addresses of the file on the disk. Having the LV fragmented into several segments is no different from having the file fragmented in the filesystem. AFAIK, lilo only stores the start of initrd and kernel images in CHS form. Mike That would require them to be continious and they often aren't. Afaik lilo stores an array of extents (location, size). The number of extens is limited but certainly 1. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Michael Banck wrote: On Mon, Jun 16, 2008 at 11:03:10AM +0200, Goswin von Brederlow wrote: I don't really see this as a bug, certainly not as grave. The problem seems to be that lilo simply can't handle large images and the default ramdisk just has now hit that limit on amd64. So it's broken on amd64 for the stock Debian kernel, AIUI. Looks like a grave bug to me. It also means that it is not broken for testing as that has 2.6.24. And it means that it is not broken for i386 users. Sounds to me that it is still useful for most users, so severity important, not RC. Especially given that it is not the default bootloader. You can argue this from various sides, but IMO a removal from testing was very much the wrong action to take by RMs. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 12:31:49AM -0500, William Pitcock wrote: If we do not need lilo, then I will file a RM bug in the next couple of weeks. I had at least a couple of boxes in the past where grub were problematic and I used the old good linux loader. I generally agree that grub is more flexible and generally useful but I would retain lilo as an optional package at least. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:54:52AM +0300, Shachar Shemesh wrote: Lilo has one killer feature that is totally missing from GRUB - the -R option. It allows me to upgrade a kernel on remote servers, knowing that if the upgrade fails, I will get the original kernel after a few minutes without asking a local hand to push the reset button. Until Grub has something similar, removing Lilo entirely seems like a bad idea to me. grub does have that. man grub-reboot. Boot a specific entry next time but only once. I think it is a debian specific patch and not a generic grub feature. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Francesco P. Lovergine writes: I had at least a couple of boxes in the past where grub were problematic and I used the old good linux loader. When I installed Lenny on this AMD64 box (ASUS A8V-XE) a few weeks ago Grub was unable to boot it. I had to go back and reinstall, selecting Lilo. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
I demand that Frans Pop may or may not have written...
William Pitcock wrote:
[snip]
With grub being stable and grub2 approaching stability itself, do we
really need lilo anymore? It's not even installed by default anymore, and
the only systems I have that are still on lilo are installations of
Debian I have had since Woody.
We still very regularly get installation reports where people use lilo
rather than grub, so it must still have a fairly significant user base. I
would say that the activity on the bug report shows the same.
FWIW, I use lilo, and I have no plans to change that. I'm not seeing any
problems with it, but then the installed kernels are all locally built and
don't use init{rd,ramfs}.
--
| Darren Salt| linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
A memorandum is written not to inform the reader, but to protect the writer.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
William Pitcock wrote: Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. Well, grub is also not free of bugs, all my partitions are usually reiserfs and on a hard reset grub stupidly comes up with GRUB Error 16: Inconsistent filesystem structure. You might see it differently, by in my opinion this is a grave bug as well. So why not also to remove grub ;) Sorry, I don't know if there is a debian bug report, the ubuntu bug description is here: https://bugs.launchpad.net/grub/+bug/64928 With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. I still use lilo on all of my systems. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. Next problem with grub, grub can't read links, but always needs to update the menu.lst. In my previous work group we have a laptop chroot for updates. We then rsync from this chroot to the laptops and as last step only call 'lilo' to update to the recent kernel. For some laptops there are exceptions, however, and not the generic kernel is installed. With simple links and calling lilo these exceptions can be easily handled, with grubs menu.lst this would required full parsing of that file - the script probably would be 10x larger only for this stupid menu.lst parsing. So I quite disagree to remove lilo. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
I would also have to say that the Linux Community has always been about freedom and choice. Although I use GRUB my self, why should we remove a useful package that is being used? Wouldn't that take away from the freedom just a bit? Just because you might not like it, or like another program better, we shouldn't force our preferences on people. GRUB and LILO fall into the category of Gnome vs. KDEeverybody has an opinion on what they like best. It doesn't nessicarily mean that one is really that much better than the other. David Bernd Schubert wrote: William Pitcock wrote: Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. Well, grub is also not free of bugs, all my partitions are usually reiserfs and on a hard reset grub stupidly comes up with GRUB Error 16: Inconsistent filesystem structure. You might see it differently, by in my opinion this is a grave bug as well. So why not also to remove grub ;) Sorry, I don't know if there is a debian bug report, the ubuntu bug description is here: https://bugs.launchpad.net/grub/+bug/64928 With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. I still use lilo on all of my systems. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. Next problem with grub, grub can't read links, but always needs to update the menu.lst. In my previous work group we have a laptop chroot for updates. We then rsync from this chroot to the laptops and as last step only call 'lilo' to update to the recent kernel. For some laptops there are exceptions, however, and not the generic kernel is installed. With simple links and calling lilo these exceptions can be easily handled, with grubs menu.lst this would required full parsing of that file - the script probably would be 10x larger only for this stupid menu.lst parsing. So I quite disagree to remove lilo. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 00:31 -0500, William Pitcock wrote: [a lot of stuff] As many people have brought up usecases not covered by alternatives, the plan seems to be: * Cope with the growing initramfs issue as best we can, e.g. by displaying a warning to the user that the kernel may not be bootable by lilo due to the 8MiB boundry in liloconfig. An upload is already prepared to do exactly this, and is pending a merge with some translation updates which have not all been received yet. At that point, an upload will hit incoming and a fixed lilo will hit Debian in time for Lenny's freeze (whenever that may be). On another note, if you want to improve the translations for lilo in Lenny, you have 4 days to get them into the upload that will be made. * Possibly revisit this issue if this outcome is not enough for Lenny+1. We will probably be revisiting this issue because working around bugs is not really the greatest way of handling them. By then, it is hopeful that grub or grub2 can be adapted to handle any missing features not provided already. Thank you all for your feedback, it has been helpful for determining how to handle the situation. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
FWIW, adding -9 to the gzip in mkinitramfs gives a 0.5% saving, which may help with some marginal cases. OTOH using bzip2 instead of gzip saves 10.5% but I have no idea how much work it would take to support bzip'd initrd's. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
William Pitcock wrote: * Cope with the growing initramfs issue as best we can, e.g. by displaying a warning to the user that the kernel may not be bootable by lilo due to the 8MiB boundry in liloconfig. Having only a warning is not sufficient for the use of lilo in new installations! We really need lilo to fail there, which means a non-zero exit code. I guess that will also affect package upgrades, but IMO that's a good thing as otherwise the warning may just be lost in the general package installation noise. If you wish to discuss this further, feel free to contact the D-I team on the debian-boot list. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Considerations for lilo removal
* William Pitcock: I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. BTW, the bug report lacks this information (it seems that you've isolated the bug). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Considerations for lilo removal
Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. William signature.asc Description: This is a digitally signed message part
