[RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Matt Domsch]

For comment. -Matt
-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com


You can import this changeset into BK by piping this whole message to
'| bk receive [path to repository]' or apply the patch as usual.

===================================================================


ChangeSet@1.1182, 2003-10-10 08:50:32-05:00, Matt_Domsch@dell.com
  EDD: read disk80 MBR signature, export through edd module
  
  There are 4 bytes in the MSDOS master boot record, at offset 0x228,
  which may contain a per-system-unique signature.  By writing into this
  signature from a tool that makes real-mode int13 calls a unique
  signature such as "BOOT" for the boot disk (int13 dev 80h), Linux may
  then retrieve this information and use it to compare against disks it
  knows as named /dev/[hs]d[a-z].
  
  This is useful in the case where the BIOS is not EDD3.0 compliant,
  thus doesn't provide the PCI bus/dev/fn and IDE/SCSI location of the
  boot disk, yet you need to know which disk is the boot disk.
  
  This patch retrieves the signature from the disk in setup.S and stores
  it in a space reserved in the empty_zero_page, copies it somewhere
  safe in setup.c, and exports it via
  /proc/bios/edd/int13_disk80/mbr_signature in edd.c.  Code is covered
  under CONFIG_EDD=[ym].


 Documentation/i386/zero-page.txt |    4 +++-
 arch/i386/boot/setup.S           |   21 +++++++++++++++++++++
 arch/i386/kernel/edd.c           |   27 +++++++++++++++++++++++++--
 arch/i386/kernel/i386_ksyms.c    |    1 +
 arch/i386/kernel/setup.c         |    3 +++
 include/asm-i386/edd.h           |    7 ++++++-
 6 files changed, 59 insertions(+), 4 deletions(-)


diff -Nru a/Documentation/i386/zero-page.txt b/Documentation/i386/zero-page.txt
--- a/Documentation/i386/zero-page.txt	Fri Oct 10 09:01:41 2003
+++ b/Documentation/i386/zero-page.txt	Fri Oct 10 09:01:41 2003
@@ -66,8 +66,10 @@
 0x21c	unsigned long	INITRD_SIZE, size in bytes of ramdisk image
 0x220	4 bytes		(setup.S)
 0x224	unsigned short	setup.S heap end pointer
+0x228	4 bytes		DISK80_SIG_BUFFER (setup.S)
 0x2d0 - 0x600		E820MAP
-0x600 - 0x7D4		EDDBUF (setup.S)
+0x600 - 0x800		EDDBUF (setup.S) for disk signature read sector
+0x600 - 0x7d4		EDDBUF (setup.S)
 
 0x800	string, 2K max	COMMAND_LINE, the kernel commandline as
 			copied using CL_OFFSET.
diff -Nru a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
--- a/arch/i386/boot/setup.S	Fri Oct 10 09:01:41 2003
+++ b/arch/i386/boot/setup.S	Fri Oct 10 09:01:41 2003
@@ -49,6 +49,8 @@
  * by Matt Domsch <Matt_Domsch@dell.com> October 2002
  * conformant to T13 Committee www.t13.org
  *   projects 1572D, 1484D, 1386D, 1226DT
+ * disk signature read by Matt Domsch <Matt_Domsch@dell.com>
+ *	and Andrew Wilks <Andrew_Wilks@dell.com> September 2003
  */
 
 #include <linux/config.h>
@@ -549,6 +551,25 @@
 #endif
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
+# Read the first sector of device 80h and store the 4-byte signature
+	movl	$0xFFFFFFFF, %eax
+	movl	%eax, (DISK80_SIG_BUFFER)	# assume failure
+	movb	$READ_SECTORS, %ah
+	movb	$1, %al				# read 1 sector
+	movb	$0x80, %dl			# from device 80
+	movb	$0, %dh				# at head 0
+	movw	$1, %cx				# cylinder 0, sector 0
+	pushw	%es
+	pushw	%ds
+	popw	%es
+	movw	$EDDBUF, %bx
+	int	$0x13
+	jc	disk_sig_done
+	movl	(EDDBUF+MBR_SIG_OFFSET), %eax
+	movl	%eax, (DISK80_SIG_BUFFER)	# store success
+disk_sig_done:
+	popw	%es
+
 # Do the BIOS Enhanced Disk Drive calls
 # This consists of two calls:
 #    int 13h ah=41h "Check Extensions Present"
diff -Nru a/arch/i386/kernel/edd.c b/arch/i386/kernel/edd.c
--- a/arch/i386/kernel/edd.c	Fri Oct 10 09:01:41 2003
+++ b/arch/i386/kernel/edd.c	Fri Oct 10 09:01:41 2003
@@ -1,7 +1,8 @@
 /*
  * linux/arch/i386/kernel/edd.c
- *  Copyright (C) 2002 Dell Computer Corporation
+ *  Copyright (C) 2002, 2003 Dell, Inc.
  *  by Matt Domsch <Matt_Domsch@dell.com>
+ *  disk80 signature by Matt Domsch, Andrew Wilks, and Sandeep K. Shandilya
  *
  * BIOS Enhanced Disk Drive Services (EDD)
  * conformant to T13 Committee www.t13.org
@@ -27,7 +28,6 @@
 /*
  * TODO:
  * - move edd.[ch] to better locations if/when one is decided
- * - keep current with 2.5 EDD code changes
  */
 
 #include <linux/module.h>
@@ -333,6 +333,18 @@
 }
 
 static int
+edd_show_disk80_sig(char *page, char **start, off_t off, int count, int *eof, void *data)
+{
+	char *p = page;
+	if ( !page || off) {
+		return proc_calc_metrics(page, start, off, count, eof, 0);
+	}
+
+	p += snprintf(p, left, "0x%08x\n", edd_disk80_sig);
+	return proc_calc_metrics(page, start, off, count, eof, (p - page));
+}
+
+static int
 edd_show_extensions(char *page, char **start, off_t off, int count, int *eof, void *data)
 {
 	struct edd_info *info = data;
@@ -491,6 +503,15 @@
 	return 1;
 }
 
+static int
+edd_has_disk80_sig(struct edd_device *edev)
+{
+	struct edd_info *info = edd_dev_get_info(edev);
+	if (!edev || !info)
+		return 0;
+	return info->device == 0x80;
+}
+
 static EDD_DEVICE_ATTR(raw_data, edd_show_raw_data, NULL);
 static EDD_DEVICE_ATTR(version, edd_show_version, NULL);
 static EDD_DEVICE_ATTR(extensions, edd_show_extensions, NULL);
@@ -505,6 +526,7 @@
 		       edd_has_default_sectors_per_track);
 static EDD_DEVICE_ATTR(interface, edd_show_interface,edd_has_edd30);
 static EDD_DEVICE_ATTR(host_bus, edd_show_host_bus, edd_has_edd30);
+static EDD_DEVICE_ATTR(mbr_signature, edd_show_disk80_sig, edd_has_disk80_sig);
 
 static struct edd_attribute *def_attrs[] = {
 	&edd_attr_raw_data,
@@ -517,6 +539,7 @@
 	&edd_attr_default_sectors_per_track,
 	&edd_attr_interface,
 	&edd_attr_host_bus,
+	&edd_attr_mbr_signature,
 	NULL,
 };
 
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c	Fri Oct 10 09:01:41 2003
+++ b/arch/i386/kernel/i386_ksyms.c	Fri Oct 10 09:01:41 2003
@@ -185,4 +185,5 @@
 #ifdef CONFIG_EDD_MODULE
 EXPORT_SYMBOL(edd);
 EXPORT_SYMBOL(eddnr);
+EXPORT_SYMBOL(edd_disk80_sig);
 #endif
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c	Fri Oct 10 09:01:41 2003
+++ b/arch/i386/kernel/setup.c	Fri Oct 10 09:01:41 2003
@@ -212,6 +212,7 @@
 #define KERNEL_START (*(unsigned long *) (PARAM+0x214))
 #define INITRD_START (*(unsigned long *) (PARAM+0x218))
 #define INITRD_SIZE (*(unsigned long *) (PARAM+0x21c))
+#define DISK80_SIGNATURE_BUFFER (*(unsigned int*) (PARAM+DISKSIG_BUFFER))
 #define EDD_NR     (*(unsigned char *) (PARAM+EDDNR))
 #define EDD_BUF     ((struct edd_info *) (PARAM+EDDBUF))
 #define COMMAND_LINE ((char *) (PARAM+2048))
@@ -721,6 +722,7 @@
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 unsigned char eddnr;
 struct edd_info edd[EDDMAXNR];
+unsigned int edd_disk80_sig;
 /**
  * copy_edd() - Copy the BIOS EDD information
  *              from empty_zero_page into a safe place.
@@ -730,6 +732,7 @@
 {
      eddnr = EDD_NR;
      memcpy(edd, EDD_BUF, sizeof(edd));
+     edd_disk80_sig = DISK80_SIGNATURE_BUFFER;
 }
 #else
 static inline void copy_edd(void) {}
diff -Nru a/include/asm-i386/edd.h b/include/asm-i386/edd.h
--- a/include/asm-i386/edd.h	Fri Oct 10 09:01:41 2003
+++ b/include/asm-i386/edd.h	Fri Oct 10 09:01:41 2003
@@ -1,6 +1,6 @@
 /*
  * linux/include/asm-i386/edd.h
- *  Copyright (C) 2002 Dell Computer Corporation
+ *  Copyright (C) 2002, 2003 Dell, Inc.
  *  by Matt Domsch <Matt_Domsch@dell.com>
  *
  * structures and definitions for the int 13h, ax={41,48}h
@@ -41,6 +41,10 @@
 #define EDDMAGIC1 0x55AA
 #define EDDMAGIC2 0xAA55
 
+#define READ_SECTORS 0x02
+#define MBR_SIG_OFFSET 0x1B8
+#define DISK80_SIG_BUFFER 0x228
+
 #ifndef __ASSEMBLY__
 
 #define EDD_EXT_FIXED_DISK_ACCESS           (1 << 0)
@@ -167,6 +171,7 @@
 
 extern struct edd_info edd[EDDMAXNR];
 extern unsigned char eddnr;
+extern unsigned int edd_disk80_sig;
 #endif				/*!__ASSEMBLY__ */
 
 #endif				/* _ASM_I386_EDD_H */

===================================================================


This BitKeeper patch contains the following changesets:
1.1182
## Wrapped with gzip_uu ##


M'XL( ,6[AC\  [U9^7?:2!+^&?T5E7AF%QP.M6Z<<5YL@V=Y2<9^QMGC)7F\
M1FHLC76P:H$AR_[O6]T2(+ 3;!(OMHF.ZCJ^_KJZJG, 'SE+CRH?:)8-.DG$
M75\Y@+\E/#NJ>"P,FVX2X8.K),$'+3^)6"ORI%AK>-MBGM<*@W@R:VA-HX%W
M#2_@MSRX47#,)<U<'Z8LY4<5TM173[+YF!U5KKJ_?WQ_<J4HQ\=PYM/XAO59
M!L?'2I:D4QIZ_"W-_#")FUE*8QZQC I7%BO1A::J&OZ8Q-95TUH02S7LA4L\
M0JA!F*=JAF,92D13EX7)VS"Y27C3C7'@A@J=J&I;(X9*S(5!+*(K'2!-0AP-
M5+U%5/P%U3DRU2-=:ZCFD:I"":JW2X@^%:!\@5<6-%3E%'YN&&>*"]U.YPA2
M1CT0(#OHR.D5(-8QS28IJP.;C9,T@\Q/D\F-#S@;$"7>)&0X%G^O?98RH/AG
MP'">,0Y!C,(,/O0[%WV(*,]8"D.<:#3B)JE7!YI!,AIQG!=UIFE.';7<^0%.
M843GX"9Q1E$%A3%+&WR.PZ/&) [^/6%KKYH IW.X2X,LB&_08):@R8"CHI4(
MC-(D0BU9DH3X$FU&]!:]PTC#!@; Q#"B@TO#D*-<;F)# Y^@3Y3#R].+B^N7
M,$I2&9B,16 %U5R%QZ;@J'ZM#N\%:448J =%8[26I0&;,ND>6D0=$<V"!..+
M/9AP] *A33#J:"PPI#<8.\_5HWR&>F[CY(X+-V(:,0]::*WUR>=?O$^T\?5+
M<SD+0CT7&D>3<#D%+D4#=W*"Q.UI#R<$A6+T'V==;ZK2;AC0.*M+CR<<O(3Q
M^*\9C--D&GCYP,NS'@PG7)H>Y:[W.MU6_ZS?@S!Q\X"2D9!%-2M\ZC#'.9XG
M$X@9>HYABEB*N98 HC,;B):C&<M5O00P%]R:7?$HUQ,#TFDR;O:E<QQ7"1-L
M0' EE?B8N@QU84Z:HB<%/"P:9_/!5Y8F@S&]0:J[R3@0!,Z 8T:2P E"T!%;
M6W#KTD2^*J3L-* HU4+ W-8P2+A,7Y(9@WQ%M:)A.EB[CJI0HNDBB<\D#SD:
MQGS&/%0SB3U<+F<7?YSW?A_@)!U_FD<XR>_ P!7;5B[724UI//&C*"I5E3<[
M4@@F-K\5Z([5$K/2*F MY1,#_UD08IG&PE(]APRIIMD.LT?:Z/LY[#NJ,5WB
MCVZJ6GNAHFH-W7RLKEN6QBQL24BE+DR\.FF;FD$6FJ.99&&H>MOV+,VB]I!9
MKK6_ZK*;MF-:3T"ST"6N![=\'O%<Y1I4LC!MQW(6CCT:N4.'ZM0T]:&F/]7;
M;0MEIRW#MIVG.UTP?]M?PT;="TI4W%%L@XR(ZVJV^51_2\HW\%5U0]_I:B=Q
M)Q'#'4.DH%RM6,\-L9Z;V2S;<%FW%Z:AZV3A#-4V<X9M7?-<@AOA#I<?8Z3L
MNM$FCV!P$+OAQ&,MRJ.&U"EHYF\R6%L0M:V2A6T9%M/(B'J4&,3;M="^H[KL
MIJ,;ABR4'F:\J)J>;Q'^!-4:WNJ(M"BM9%VEMEO$!*)A.75D.H^KJS03&MKS
M%59%]60T1&VT65J)C>,;VP:;;N\:RCE@.>F8-L&]0*:>"VBD=_(74_OE-^9P
MCTVBHP-1>N(+#L4.-9ZGP8V?0?6L!B+XNOC6H8-0UJ$7NTVE9Q3"10&YCG X
ME_!##G\=3F(O97?PCR"\Y?D^VL<OQL;PK@E]Q-@+PCE%%U3I@RXF4\% !MQ/
M[HK=5&!2=7V:PF&Q:\OK0Y[1-*N+RG(@Z\NZ*/!P9YU@<2,O#UF"#Z=)X,&A
M1S-:4_ZC5 I%< Q"V6NE$HR@"B_$#2P60D\-4*R"=<@DC455Y ZP9'0'D2A,
M7%[-?5@;KR]-2FMJ#57^5_FL5,;PZAAX/$[1E5%U7(>0C5#JI3K[575FG^.7
M=5$5E&(4(_>T6AU#0\930R7".A>YRQ4HX&2U=6B7GPBS/N5E>'F63MPL=XA-
M ZR=#AE>2,1*[T0]"X?R^W@I/+AAF7Q1E2,*1%^(&P'H"_&JM@9474<IWC3>
M%/8P*ZDS1\W=[YFJC80H?,9U->AT_]X[ZPY.KJ^OJAOK)$=QBR[YP\T8T;.>
M2=JHMO(7\19IF@XV5<G<^' NW9T;?R2]_P35^D)OMVWCQW(C]ISD^5*CQT9!
MC.6VZ*M$_UFT<GE#)3B /=5FQMQ(@OGVM94%'X;F_Y0%=3"4@SPJN.J>= ;]
M[MGUQ54?F:QJJS<8T:"/Q?W%^7F_>XWOR*FS>MGI]=\A/\7[TX_GY]VKO$46
M:X!8@JQLANUTC&V" $6V,ME6WG@M:;NK9ME])/)S2JL=5'Y4:55:+P8N&%.2
M6M^7U/JSDKKH,5>'(<M#@Z<06Y:/6\3>!=0>%.]9#A)*\JM2N%NIW"=@M>C3
M:DK'EMLR?FLXS$*H&S))JY4*QH[B:UD9MVS-U\6 /&/BS$7D2\-MS[@_?*LJ
M+;>+NXG[(QWLHZO2>QWL1E5*2$Y2LC=+-?+,YWW%N=2#A:F8O&W";E!4MNC?
M+$#+V.S#2Y,@P3#M/L2?S8H2?GL(QC<XN"**RW*Y";_E=P-YMY:%/AMG+!JR
M5&9TM([F25L<3@M[8NV.@I1G!7/%,5=I%:].FZ1@ >9Z65>B9!I6?E%GY\6G
M#K\R.BN>BTLLUNXMN5KE "CGN-YA1(-PJ6A8^:6\JZ JZB]?$'$75O!SD.-$
MEBNM$!#K%&6\4(K(T[-5&"L9(>#G2F@&OM"3O[S++;BS_*4[#P-Y3H4C"EA0
M;CSA_AT&Q5>7GKA,QL7#7$^^U%'9$&% D@G7B*Y4_G0K8K[%#C;PDGB)7367
M?[6Y:]8>C6,^.7SBNHQS9</"4<FYSP_WP>6SE*<DGKT/>Y[:%=\[["FE(4O3
M="LO )U]T]#S9J&B.=ZL7\2I>I %- R^YD>UQ0%1;2,#Y2=9NWK@,CS[9"+B
MB+ZC^\_+BZOK0?]?'TXOWE?O=6D/,J=P>@_2/.FP[4&^[#ICPS]#DQPTM*)%
ML*T?**>>D2$N%M[;_)#):^OL?H,;XN!P%S,*1/8A!1I"4MROV/\XN?YXU5V5
M38?5<I%^6(/JY<G5R8=78D I1]6PH-)$G_'=DKYGZYKH1<1G"X[C;[GP>OV_
8I:[/W%O<4(ZIY^B,.9KR/_S>8GZA'0  

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Jamie Lokier]

Matt Domsch wrote:
>   There are 4 bytes in the MSDOS master boot record, at offset 0x228,
>   which may contain a per-system-unique signature.  By writing into this
>   signature from a tool that makes real-mode int13 calls a unique
>   signature such as "BOOT" for the boot disk (int13 dev 80h), Linux may
>   then retrieve this information and use it to compare against disks it
>   knows as named /dev/[hs]d[a-z].

If I put a hard disk from another system into my computer, and it has
the "BOOT" signature, Linux will see two disks with the signature.  Barf!

Same if I boot from two different disks at different times, and more
so if one of them fails to boot properly so that it's not even
possible for the booted kernel to erase the signature on its boot
disk.

It would be better to have the boot loader pick a likely-unique number
such as the CMOS time in seconds since whenever and store that, and
pass it as boot parameter to the kernel.  A few bits could be reserved
to indicate that it was from our boot loaders; it would be good if we
had a list of existing per-system-unique signatures to avoid.  Do you
know of such a list?

-- Jamie

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Matt Domsch]

> If I put a hard disk from another system into my computer, and it has
> the "BOOT" signature, Linux will see two disks with the signature.  Barf!
> Same if I boot from two different disks at different times, and more
> so if one of them fails to boot properly so that it's not even
> possible for the booted kernel to erase the signature on its boot
> disk.

Yes, indeed.  For this to work, the signature on the boot disk need be 
different than the signature on any other attached disk.  4 bytes is 
not enough to put a real UUID into.
 
Where we've put this into practice, we can carefully control the state of 
the disks before Linux starts, so it hasn't been a problem.

This trick (and EDD in general) is most interesting when installing a new 
OS onto a clean (known-state) system.  After that, file system labels, 
partition labels, etc. can provide the uniqueness you're looking for.
 
> It would be better to have the boot loader pick a likely-unique number
> such as the CMOS time in seconds since whenever and store that, and
> pass it as boot parameter to the kernel.  A few bits could be reserved
> to indicate that it was from our boot loaders;

That's a pretty good idea.  I do something like this on IA-64 with 
efibootmgr.  Either the boot manager could generate and write a signature 
to the disk, and pass it via a boot parameter, or as I had envisioned, any 
other tool that speaks int13 could do it too, before the boot loader.  
That's how it's used today - some DOS app writes a constant signature to 
the boot disk, and zeros to the other disks.  Then a Linux userspace tool 
can grab the signature, and compare it against the known constant 
signature.  Passing it as a kernel parameter would remove the need to have 
two tools know the same constant signature.

> it would be good if we had a list of existing per-system-unique
> signatures to avoid.  Do you know of such a list?

I know "DELL" has been used in the past, but regardless, whatever 
signature you use really needs to be unique across all the disks in the 
system, so it isn't important exactly what value is used, as long as only 
the boot disk has it, and your code knows what to look for.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Jamie Lokier]

Matt Domsch wrote:
> it isn't important exactly what value is used, as long as only 
> the boot disk has it, and your code knows what to look for.

How can you be sure what's on other disks the code doesn't know about
at the time it writes to the boot disk?

You could just say the EDD thing is only to be used in very simple
configurations, but that's not half as useful as it could be - very
simple configurations don't need EDD anyway.

If we encourage its use, so that it's basically assumed to work and
boot processes use it by default, then people will be upset if things
like adding another disk to a system just to read data off it cause
the boot process to get confused.

-- Jamie

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Andries Brouwer]

On Fri, Oct 10, 2003 at 09:05:47AM -0500, Matt Domsch wrote:

>   There are 4 bytes in the MSDOS master boot record, at offset 0x228,
>   which may contain a per-system-unique signature.

You mean 0x1b8.

Yes, this area is used by some Microsoft systems.
I wrote somewhere:

-------------------------------------------------
Just before the partition table some operating systems save some
interesting stuff. For example, DRDOS stores a password starting
at offset 0x1b6. 

Windows NT stores a 4-byte "disk signature" or "volume ID" starting at
offset 0x1b8. It is used to map drive letters to disks: in the
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices registry item the drive letter
is coupled with this disk signature. It is used as a disk label to map
disk info to disks in the HKEY_LOCAL_MACHINE\SYSTEM\DISK registry item.
This signature is generated by the Disk Administrator when it initializes
the disk, unless there already was a nonzero value there. 

Grub had a 4-byte stage2 start address at 0x1b8, and a 2-byte version
at 0x1bc, but recent versions preserve 0x1b8-0x1bd. Also LILO v20 and later
preserves this area. 
-------------------------------------------------

Probably you can add to this.

> This is useful in the case where the BIOS is not EDD3.0 compliant,
> thus doesn't provide the PCI bus/dev/fn and IDE/SCSI location of the
> boot disk, yet you need to know which disk is the boot disk.

An old idea to distinguish disks is to store an md5sum of the first sector.
That would partly remove the dependence on one particular boot sector format.

Can you remind me why you want to retrieve the boot disk?
(Maybe we booted from ethernet or CDROM or USB device..)

Andries

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Matt Domsch]

On Tue, Oct 14, 2003 at 05:45:08AM -0500, Andries Brouwer wrote:
>    On Fri, Oct 10, 2003 at 09:05:47AM -0500, Matt Domsch wrote:
> 
>    >   There are 4 bytes in the MSDOS master boot record, at offset 0x228,
>    >   which may contain a per-system-unique signature.
> 
>    You mean 0x1b8.

Yes, my mistake, that is indeed what I meant.

I'm really glad to see recent grub and lilo versions preserve
0x1b8-0x1bb, that's necessary.

>    > This is useful in the case where the BIOS is not EDD3.0 compliant,
>    > thus doesn't provide the PCI bus/dev/fn and IDE/SCSI location of the
>    > boot disk, yet you need to know which disk is the boot disk.
> 
>    An old idea to distinguish disks is to store an md5sum of the first
>    sector.  That would partly remove the dependence on one particular boot sector
>    format.

Indeed, that's a decent idea, but I'd have to put md5sum into
real-mode assembly then? :-(

>    Can you remind me why you want to retrieve the boot disk?

Fair question.  Consider the case of automated factory install of a
new system.  One may configure the system to have multiple disk
controllers and multiple disks on them, attached in just about any
way.  One common configuration our customers like is to have two disks
attached to one controller on which to put the OS, then maybe 8 more
disks on a second SCSI backplane going to two channels of another
controller on which they want to build their database files.

Right now, there's no good way to determine programatically from
within Linux which disk controller and disk the BIOS will decide is
the boot device.  The system BIOS can be configured to say "boot to
the first disk on the first SCSI controller" for example, or if the
user instead wanted to boot to one of the 9 other drives, they could
configure that also.  So, people have choice in what their boot disk
is, but Linux doesn't know what that choice is.  All it knows is some
driver modules get loaded, in some (predetermined?) order, and sees
disks with names /dev/[hs]d[a-z] in some order that depends on driver
load order, driver PCI device lists, and PCI bus scan order (forward
or reverse).  Where should the installer put grub or lilo and your /
partition?  With 10 disks and no mechanism to know which one BIOS will
use as the boot disk, you've got a 10% chance of getting it right, and
until you try to boot into Linux after the install is complete, you
don't know if you got it right.  That doesn't cut it in the factory.

>    (Maybe we booted from ethernet or CDROM or USB device..)

For our factory process, ethernet is a distinct possibility, CD-ROM
and USB aren't - no human intervention allowed.  But you raise a good
point.

For ethernet, int13 device 80h is still your primary hard disk, the
one you would expect to boot from if not doing PXE.
For CD-ROM, int13 device 80h is still your primary hard disk, CD-ROM is
device FFh.

For USB storage, I don't know what int13 device 80h will be.  I'll
have to go play with that and see what our BIOSs do.  Hopefully, if
your BIOS is smart enough to let you boot to a USB hard drive, it will
have a mechanism to let you get/set the BIOS boot order
programatically from within Linux - Dell BIOSs allow such I know, or
it will have EDD3.0 capability.  That, combined with userspace smarts
to implement installation policy, e.g. if you booted to a USB device,
but want to install to the primary hard drive, here's how to determine
when you're in that situation and how to deal with it.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Herbert Poetzl]

On Tue, Oct 14, 2003 at 08:38:09AM -0500, Matt Domsch wrote:
> >    Can you remind me why you want to retrieve the boot disk?
> 
> Fair question.  Consider the case of automated factory install of a
> new system.  One may configure the system to have multiple disk
> controllers and multiple disks on them, attached in just about any
> way.  One common configuration our customers like is to have two disks
> attached to one controller on which to put the OS, then maybe 8 more
> disks on a second SCSI backplane going to two channels of another
> controller on which they want to build their database files.
> 
> Right now, there's no good way to determine programatically from
> within Linux which disk controller and disk the BIOS will decide is
> the boot device.

hmm, IIRC devfs makes a /dev/root symlink pointing
to the root device ... is this not what you want?

please ignore if I talk nonsense ...

best,
Herbert

Re: [RFC][PATCH 2.4] EDD 4-byte MBR disk signature for the boot disk

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Sat, 25 Oct 2003 04:28:03 +0200, Herbert Poetzl said:

> hmm, IIRC devfs makes a /dev/root symlink pointing
> to the root device ... is this not what you want?

No, he wants a pointer to the disk that has the boot block and
all that - the disk that grub/lilo and /boot are on (which could be
two separate disks I suppose) may not be the disk that / lives on....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]