GRUB update borks Debian testing

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Mon Jan 11 18:06:20 UTC 2010


On Sun, Jan 10, 2010 at 01:59:41AM -0500, D. Hugh Redelmeier wrote:
> | From: Jamon Camisso <jamon.camisso-H217xnMUJC0sA/PxXw9srA at public.gmane.org>
> 
> Thanks for your informative response.
> 
> | I usually always run update-grub when a new kernel comes around, either
> | grub or grub2. No change there for me.
> 
> Me too, but indirectly.  I get kernel updates from my distro.  The
> installation process updates the grub config file(s) as part of that.
> 
> When the LILO -> Grub transition happened, I was using custom kernels,
> or at least thought I was still going to do that.  So the issue was
> more significant.
> 
> Custom kernels are much less mainstream now.  So the issue is mostly
> moot.
> 
> There was another advantage of Grub back then that I forgot to
> mention.  LILO used the BIOS to do disk operations.  Some BIOSes I had
> to work with could not address beyond the first 8.5G of disk.  But
> Grub used native disk I/O and could boot from partitions past 8.5G

No grub uses the BIOS.  But grub uses LBA if available.  So did later
versions of lilo if you asked it to (it wasn't much for runtime detection
of things).

> Thankfully, that issue too is dead.  I think.  I admit variations of
> it seem to come back once in a while.
> 
> There may be another issue.  LILO may only be 16-bit and may only be
> able to load things into the first 640K.  I don't know.  That might
> not be easy to fix since BIOS calls may have those limitations.

No it can handle 3MB ramdisk images just fine.  It runs in protected mode.

> So: I wonder if we should move back to LILO!

Go ahead.  I am sticking with grub.  I don't know if LILO is >32bit
sector number compatible, which we are getting very close to (2TB disks
will have that).  Grub2 works with the EFI style GPT partition tables,
and works fine with large disks.  Grub1 does not, and I would not be
surprised if lilo doesn't either.

> I guess what you are saying that modules allow bloat without a
> proportionately increased RAM footprint.  And that the GRUB2 folks
> have been prolific.
> 
> I'd like GRUB2 to support netbooting (apparently it has lost old
> Grub's capability).

That would probably be easier on EFI systems where there are platform
drivers in EFI it could tap into, rather than having to be built witth
drivers for all sorts of network cards at compile time.

> I'd like GRUB to be suitable for CD and DVD booting.  I don't know
> what the issues are, but all the bootable CDs I've noticed uses
> syslinux / isolinux.  I actually have a bootable GRUB CD to use in
> emergencies.

isolinux does it very well.  Doesn't mean grub couldn't be extended for
it, although the normal grub install method certainly would not work.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list