lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: thib on 26 May 2010 08:30 consul tores wrote: > Could you say why? I misunderstood you, or simply wasn't aware of the terminology, sorry. I mistakenly thought you were suggesting the creation of an entirely new Debian kernel. > We have lost the posibility to install from disquette, we have to add > an initrd, SElinux have been added by default because of Linus, Linus > kernels define what to do, and ad infinitum. Linux is still extremely tweakable, and you are free to build the kernel whichever way you want to. If you can't, maybe a specific distribution of it will fit your needs -- the fact that its default configuration doesn't [fit] doesn't necessarily mean Linus is evil, but that maybe the general needs of most people are shifting. He doesn't have absolute power over everything. Beeing actually aware of what's going on there is also a must to understand the choices beeing taken. I'm not strictly suggesting you aren't, but you must admit that going on a revolution because a full featured modern kernel *in its default configuration* won't fit a disquette lacks some sense. They had their reasons to drop that "feature". I'm not sure you'd like to debate your other examples here, but to avoid any confusion: no you don't *have* to use initrds -- complaints for using them by default even though you don't need them for your particular setup should go to the distributors, not "Linus". Not sure they would be valid though (they *are* necessary for many setups for technical reasons that don't have much to do with the kernel). > Do you know how BSDs work? Have you try Hurd? Are you referring to the BSDs development model? Anyway, progress on kfreebsd *is* impressive, and it indeed looks like it might become a very good alternative for Debian in the near future, but I wouldn't say the same for the Hurd. It's actually very interesting, but currently lacks much needed traction. > Well you can see some reasons to built Debian kernels. Absolutely, choice is always good. -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/4BFD106A.8010309(a)stammed.net
From: Stephen Powell on 26 May 2010 09:50 On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote: > On 05/26/2010 03:36 AM, Stephen Powell wrote: >> ... >> That works for now; but if a package upgrade for extlinux is ever >> downloaded, I'm afraid that new versions of the hook scripts will >> be copied into these directories which are marked executable, and >> my hand-made configuration file will get wiped out. >> ... > > as of current git, you can now use EXTLINUX_UPDATE=false in > /etc/default/extlinux to prevent having update-extlinux do anything. That's good to know, thanks. I'm looking forward to that feature migrating into squeeze. >> Second, it is important that any script run as a hook script not >> produce any output at all to standard output. I found that out the >> hard way when I was writing my own hook scripts for use with lilo. >> That's because they run under debconf, which has redirected standard >> output for its own purposes. Thus, anything written to standard >> output is (1) never seen by the user and (2) has a good chance of >> messing up debconf, which is examining the output. The invocation >> of update-extlinux should have a redirection on it to redirect >> output to standard error. For example, >> >> update-extlinux >&2 > > none of the hooks is doing this (initramfs-tools, grub, etc), might > needs further convincing. It is a little-known requirement, and often you can get away with it, but not always. I'm going from memory here, but I believe that debconf redirects standard output, then calls the maintainer script for the kernel, which calls the run-parts utility, which then calls the hook script. If the standard output produced by the hook script matches something that debconf is looking for it can mess things up. Sometimes the failure will occur for one type of call, such as a purge, but not for another type of call, such as a configure or a remove. Manoj Srivastava, author and Debian package maintainer of the kernel-package package, mentions it in the man page for kernel-img.conf, and I have personally been burned by it with one of my own hook scripts that I wrote for use with lilo. The hook script failed with a non-zero return code, which caused the kernel installation process to fail. I could not figure out for the life of me what was wrong. The script ran fine when invoked stand-alone, but not as a hook script. Redirecting lilo output to standard error solved the problem. It ran perfectly after that. But even if the stuff written to standard output does not mess up debconf, the user still won't see it. The safe (and informative) thing to do is for all hook scripts to write all output to standard error. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/375009335.66290.1274880285294.JavaMail.root(a)md01.wow.synacor.com
From: Stefan Monnier on 26 May 2010 14:30 > 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. Really? Never heard of it, and it sounds very odd: why would they do that when they can (and do, AFAICT) use sectors on specified partitions? Is that documented/discussed somewhere? 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/jwvvdaa7cev.fsf-monnier+gmane.linux.debian.user(a)gnu.org
From: thib on 26 May 2010 15:30 Stefan Monnier wrote: >> 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. > > Really? Never heard of it, and it sounds very odd: why would they do > that when they can (and do, AFAICT) use sectors on specified partitions? > Is that documented/discussed somewhere? It is, yes. At least I remember reading about it for grub1. Actually you don't *have* to use that space, it's just that it's convenient to store an intermediary stage (called 1.5) there, which typically holds filesystem drivers. The reason for this extra space is that traditionally, the first partition on a DOS partition table can only start at the second cylinder (correct me if I'm wrong), so boot loaders just used to use the remaining space from the first cylinder so they didn't have to ask anything to anybody, since it was always sufficient. For grub1 at least, the 'install' command (not the same as the 'grub-install' script) was well documented and allowed to tweak this by manually specifying an address for the next stage (be it 1.5 or directly 2) that you would allocate yourself with a partition just like you're suggesting (I think there is about zero tools helping you with this however). Note that pointing to a stage2 file directly makes grub behave much like lilo; you would put a filesystem on the partition and then you have tools to update the address in stage1 automatically when you upgrade. Maybe someone can point to similar documentation for grub2, as I'd bet it still allows it. So yes, the first cylinder situation is a mess, and silly backup software are not the only programs carelessly using the extra space in it without checking for bootloader stuff; for example Windows stores information about its LDM thingy ("Logical Disk Manager" or "Dynamic Disks", comparable to LVM and dmraid, but crappy) in there too, making dual-boot with software RAID a real PITA. To be fair, there's never been an authority dictating that the space was reserved to boot loaders (AFAIK), so there's really no-one to blame. Fortunately, GPT answers this with new conventions. Each of these pieces of software can have their own partition and partition type and many already support it out of the box (grub2 included). I think administrators should really consider GPT for their new setups now; it has definitely more advantages than just "allowing for big partitions", and it's darn simple (not sure how anybody could defend the "I stick to what I know" point here). Note that this partition scheme doesn't need EFI hardware, it's entirely backward compatible with PC/BIOS systems (you can even have hybrid GUID/DOS partition tables if you're really stuck with crappy software). -thib -- 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/4BFD754E.1050608(a)stammed.net
From: Boyd Stephen Smith Jr. on 26 May 2010 16:00
On Wednesday 26 May 2010 14:23:58 thib wrote: > I think > administrators should really consider GPT for their new setups now; it > has definitely more advantages than just "allowing for big partitions", > and it's darn simple (not sure how anybody could defend the "I stick to > what I know" point here). Note that this partition scheme doesn't need EFI > hardware, it's entirely backward compatible with PC/BIOS systems I agree. I think d-i onto an unpartitioned disk should probably use GPT by default. > (you can > even have hybrid GUID/DOS partition tables if you're really stuck with > crappy software). You do sacrifice one of your primary partitions to the GPT "flag" partition. If you have somehow gotten stuck with 3/4 OSes that only boot off of a primary partition, it may be quite difficult to move to GPT. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ |