Hello, thanks for the answer, but the text below, I had read, but definitly misunderstood things. I found that text under internals in a GRUB of some weeks ago.
And again I understand the xx and yy in the 0xaaxxyyzz notation. I also understand the combimations of xx with yy=0xff and xx=0xff and yy is the slice and the combination of xx and yy. But I cannot understand the last 0xFF in the 32bit value (LSB(yte)) and I have big problems with the first 0xFF, as unpartitioned can also be coded as 0xFFFFFF (24bit) and is consistent ... or have I something missunderstood. In case of xx=0xFF I have a flat disk device with no MBR (plus empty track where stage 1.5 can be placed in) and inside this flat disk the slices are organized (so I think there will also be a header, which then is on sector 0 (lba) like a MBR. In case of xx=0,1,2,3, ... I have a parition table and a MBR (plus free track 0) and an partitioned image. Each image may also be organized in slices, so the first track of each partition may also have info. If slices are used, yy != 0xFF, otherwise the partition is flat holding a file system. The LSB 0xFF is for what ? And without the 0xFF NSB(yte) I can cover all cases from unpartitioned up to partitions plus slices, so what are the 0xFF on MSB for ? The description below, the thrid paragraph discusses in my oppinion the xx not the MSB(yte). Sorry that I ask again, but I am interested in this detail at the moment. With friendly regards Christoph P. "Yoshinori K. Okuji" wrote: > > 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 -- ------------------------------------------------------- private: [EMAIL PROTECTED] company: [EMAIL PROTECTED] _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub