At Thu, 22 Nov 2001 09:45:57 +0100, Christoph Plattner wrote: > What is the last 0xff for ?
The manual in the original GRUB distribution (i.e. 0.5) says: -- at offset 0x8 : "install_partition" This is an unsigned long representing the partition on the currently booted disk which GRUB should expect to find it's data files and treat as the default root partition. The format of is exactly the same as the "partition" part (the "disk" part is ignored) of the data passed to an OS by a Multiboot-compliant bootloader in the "boot_device" data element, with one exception. The exception is that if the first level of disk partitioning is left as 0xFF (decimal 255, which is marked as no partitioning being used), but the second level does have a partition number, it looks for the first BSD-style PC partition, and finds the numbered BSD sub-partition in it. The default "install_partition" 0xFF00FF, would then find the first BSD-style PC partition, and use the "a" partition in it, and 0xFF01FF would use the "b" partition, etc. If an explicit first-level partition is given, then no search is performed, and it will expect that the BSD-style PC partition is in the appropriate location, else a "no such partition" error will be returned. I don't quote the relevant part of the Multiboot Specification, as I assume you should have it within your computer. I'm not sure why this information was lost... Probably because I reorganized Stage 1, so Stage 1 doesn't possess INSTALL_PARTITION any longer. I'll fix the documentation later. > What is the point that the MSB (byte) 0xff is written to disk, but > inside > the code the byte must be 0x00, otherwise code lines as > > part_nr = installed_partition >> 16 > > cannot work !! You mistake the notation for human from the internal representation, that is, the x86 processor family uses little-endian, so the 0xff is LSB but not MSB. Okuji _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub