On Tue, 12 Jun 2018 10:28:26 -0500 Bruce Dubbs <bruce.du...@gmail.com> wrote:
> I don't think you can say that for all BIOS firmware, but it is
> certainly true for some.
I'm surprised by this, but you are correct here! According to
t13.org/Documents/UploadedDocuments/project/d1386r0-EDD.pdf
since 1999 BIOes have had "Enhanced disk drive (EDD)" support for an
Int 13h extension than can address up to "16 mega-tera" sectors (2^64)
in size. It is just a question of upgrading any boot loader to use
this call (and hope the BIOS creator did it correctly).
With the older BIOS call, the sector number is specified as a 32bit
number and drives have historically used 512 bytes per sector.
So, the upper limit with the legacy call is 2^32 * 512 = 2.199 TB
On Tue, 12 Jun 2018 20:42:05 +0100
Ken Moffat <zarniwh...@ntlworld.com> wrote:
> And then /dev/hda became /dev/sda - I never managed to get lilo to
> work with /dev/sd if the machine was currently booting from /dev/hd.
IMHO, lilo had one particularly awful design decision and the resulting
unexpected behavior was never explained to us as it should have been -
lilo would *reinterpret* whatever the user specified for root= in terms
of device numbers of the current running system and then pass the
resulting device *number* as the value of root= to the kernel to be
booted. The only exceptions allowed were for LABEL= and UUID=, but even
there what we really needed was PARTUUID=. In short, lilo should have
just kept root= exactly as the user gave it in the lilo.conf and passed
that string as-is to the kernel when booting.
I was working on one of my (really) old machines back in November and
wrote a patch for lilo to do just that. I've attached it to this post.
Once the patch has been applied and lilo rebuilt, you can put anything
you want for root= and it will be passed-on as-is. That means you can
do things like:
root="PARTUUID=1234567a-af67-4c97-8154-438376dc7113"
or
root="/dev/sda1"
and it will work as you expect - root= will be interpreted only at
boot by the booting kernel. And lilo will also work with GPT partitioned
disks just fine! (because lilo only cares about sector numbers, not
partitions).
The main lilo limitations would then be:
1. The EFI/BIOS must provide the legacy BIOS "compatibility" (CSM)
calls.
2. Lilo's second stage boot loader and any kernel images to be
loaded must be within the first 2TB boundary. (I think.)
3. The drive must be using a 512 byte sector size. (I think.)
4. As always, if lilo's second stage boot loader or a kernel image
file is moved, lilo must be rerun to get the correct sector
number locations of those files.
If they really are problems, both #2 and #3 should also be fixable in
code, well, as long as the BIOS call of the machine supports it.
I suppose my "pass root as-is" patch would have really been helpful
to some folks ... 5 years ago. Oh well.
Mike
lilo_pass_root_as_is.patch
Description: Binary data
-- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
