[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC][PATCH] unique sigs in the msdos label
From: |
Matt Domsch |
Subject: |
Re: [RFC][PATCH] unique sigs in the msdos label |
Date: |
Sun, 4 Jul 2004 08:30:46 -0500 (CDT) |
I seem not to be subscribed to bug-parted right now, so please cc: me on
this thread. I'm also out on vacation, so I'll respond when time allows.
On Sat, 3 Jul 2004, Andrew Clausen wrote:
> I'll answer for Matt :)
>
> On Mon, Jun 28, 2004 at 03:46:21PM -0700, John Gilmore wrote:
> > I think writing 'unique signatures into disk labels' is a terrible idea.
I wasn't so keen on it myself I'll admit. Which is why I've put a lot
of effort into using the "BIOS Enhanced Disk Drive Services 3.0"
specification, which EFI relies on. Problem is, I can count the
number of correct BIOS implementations of EDD 3.0 on one hand. I
can't count the number of incorrect or didn't-bother implementations,
though I've tried. See my listing at
http://linux.dell.com/projects.shtml.
> > Intel is working on a Legacy-BIOS-free spec.
>
> GPT, yeah. (Parted and Linux even support it :)
> There are plenty of legacy users left though.
yep. Andrew and I wrote the GPT stuff for Parted several years ago.
> > It should provide a way to determine exactly what device is the
> > boot device -- without this hocus pocus about storing different
> > magic numbers in every partition table, retrieving them via
> > different routes to compare and contrast. By getting involved in
> > the writing of this spec
EDD is exactly this spec. www.t13.org's 1572D project is the latest.
I believe this is what you're referring to, yes?
It's not the writing of the spec that's problematic (though there are
a few problems with the spec, which I've described to the T13
committee chair, they're corner cases right now). It's BIOS
implementations that are problematic, and I guarantee, there are more
(closed source) implementations than there are people who care to fix them.
> >, we should be able to put a stake through
> > the heart of this issue once and for all, in new hardware. Like
> > the concept of cylinders, 'BIOS drive numbers' should hsve been
> > d-e-a-d two decades ago.
That was my hope when I wrote EDD for Linux... it's a good theory,
but not yet practical.
> > As far as I know, nobody cares what device numbers the BIOS assigned
> > to devices other than the boot disk.
Except the one thing that really cares is the OS installer. Red Hat's
Anaconda, and SuSE's YAST, for example.
> > The main question is, "What
> > disk and partition did I, this kernel/bootstrapper/etc, get read in from?"
Take a perfectly new system, with zeros across all the disks, and yes,
you've got multiple disks attached to multiple PCI devices in the
system. Which disk should your /boot, / and MBR-based boot loader
(grub, lilo) go, such that after install, the system will boot
properly to that disk?
> With the current BIOS setup, we need to have unique hard disks to
> answer this question.
>
> We can ask the BIOS which disk is the boot disk, but it will give
> an identifier that "BIOS-only". i.e. we can't match it up to an IDE
> controller or whatever. (Reason: the BIOS can do funky remapping
> tricks) What we can do is ask the BIOS to read sectors from this
> boot device. If they are unique, we can figure out which disk it is.
>
> Matt: is this what you had in mind?
Yep. I wish we didn't have to write sigs to the disk. I really do.
But it's unavoidable until EDD3.0 works everywhere, which won't happen
any time soon.
--
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com