Message ID | 1434017929-1792-1-git-send-email-nikunj@linux.vnet.ibm.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On Thu, 11 Jun 2015 15:48:49 +0530 Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > For a GPT+LVM combination disk, older bootloader that does not support > LVM, cannot load kernel from LVM. > > The patch add support to read from BASIC_DATA UUID > partition. Installer has installed CHRP-BOOT config on a FAT file > system. > > Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> > --- > slof/fs/packages/disk-label.fs | 72 ++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 70 insertions(+), 2 deletions(-) > > diff --git a/slof/fs/packages/disk-label.fs b/slof/fs/packages/disk-label.fs > index fe1c25e..bf5fb5c 100644 > --- a/slof/fs/packages/disk-label.fs > +++ b/slof/fs/packages/disk-label.fs > @@ -266,7 +266,7 @@ CONSTANT /gpt-part-entry > > : try-dos-partition ( -- okay? ) > \ Read partition table and check magic. > - no-mbr? IF cr ." No DOS disk-label found." cr false EXIT THEN > + no-mbr? IF false EXIT THEN Maybe keep the output when "debug-disk-label?" is set? > count-dos-logical-partitions TO dos-logical-partitions > > @@ -408,6 +408,73 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 > FALSE > ; > > +\ Check for GPT MSFT BASIC DATA GUID - vfat based > +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 > +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 > +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 > +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 > +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 > + > +: gpt-basic-data-partition? ( -- true|false ) > + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 = IF > + block gpt-part-entry>part-type-guid 4 + w@-le > + GPT-BASIC-DATA-PARTITION-2 = IF > + block gpt-part-entry>part-type-guid 6 + w@-le > + GPT-BASIC-DATA-PARTITION-3 = IF > + block gpt-part-entry>part-type-guid 8 + w@ Don't you have to byte-swap (w@-le) here, too? Looks somehow strange that the other UID parts are read byte-swapped but this one is not? > + GPT-BASIC-DATA-PARTITION-4 = IF > + block gpt-part-entry>part-type-guid a + w@ > + block gpt-part-entry>part-type-guid c + l@ swap lxjoin dito ... here again no byteswap? > + GPT-BASIC-DATA-PARTITION-5 = IF > + TRUE EXIT > + THEN > + THEN > + THEN > + THEN > + THEN > + FALSE > +; I'm not a fan of deep nesting, so I'd maybe write this function rather like this instead: : gpt-basic-data-partition? ( -- true|false ) block gpt-part-entry>part-type-guid dup l@-le GPT-BASIC-DATA-PARTITION-1 <> IF FALSE EXIT THEN dup 4 + w@-le GPT-BASIC-DATA-PARTITION-2 <> IF FALSE EXIT THEN dup 6 + w@-le GPT-BASIC-DATA-PARTITION-3 <> IF FALSE EXIT THEN ... TRUE ; ... but that's just cosmetics. > +: try-gpt-vfat-partition ( -- okay? ) > + \ Read partition table and check magic. > + no-gpt? IF cr ." No GPT disk-label found." cr false EXIT THEN Not directly related to this patch, but "no-gpt?" seems somewhat imprecise to me ... what if the whole MBR is accidentially filled with EE for example? That certainly does not indicate a valid GPT, does it? I might be wrong, but as far as I can say that function should also check for the aa55 magic at the end of the MBR, shouldn't it? Also I wonder whether you should check gpt>signature somewhere, either in "no-gpt?" or here before touching gpt>part-entry-lba entry below? I think that would contribute to the robustness of the code. > + 1 read-sector block gpt>part-entry-lba l@-le gpt>part-entry-lba seems to be an 8-bytes field ... so shouldn't you access it with "x@ xbflip" instead? By the way, it might be a good idea to add a "x@-le" helper for this to little-endian.fs. > + block-size * to seek-pos > + block gpt>part-entry-size l@-le to gpt-part-size > + block gpt>num-part-entry l@-le dup 0= IF FALSE EXIT THEN > + 1+ 1 ?DO > + seek-pos 0 seek drop > + block gpt-part-size read drop Can you be sure that gpt-part-size is only smaller than 4096 bytes here? If not, you might overflow the block array, don't you? > + gpt-basic-data-partition? IF > + debug-disk-label? IF > + ." GPT LINUX DATA partition found " cr > + THEN > + block gpt-part-entry>first-lba x@ xbflip > + dup to part-start > + block gpt-part-entry>last-lba x@ xbflip > + over - 1+ ( addr offset len ) > + dup block-size * to part-size > + swap ( addr len offset ) > + block-size * to part-offset > + 0 0 seek > + block block-size read > + 3drop > + \ block 0 byte 0-2 is a jump instruction in all FAT > + \ filesystems. > + \ e9 and eb are jump instructions in x86 assembler. > + block c@ e9 <> IF > + block c@ eb <> > + block 2+ c@ 90 <> or > + IF false EXIT THEN > + THEN That's a copy of the code in try-dos-files ... could you please factor out that stuff into a separate function to avoid duplicate code? Thanks! (especially you also lack a UNLOOP before above EXIT otherwise, I think) > + TRUE > + UNLOOP EXIT > + THEN > + seek-pos gpt-part-size i * + to seek-pos > + LOOP > + FALSE > +; > + > \ Extract the boot loader path from a bootinfo.txt file > \ In: address and length of buffer where the bootinfo.txt has been loaded to. > \ Out: string address and length of the boot loader (within the input buffer) > @@ -493,7 +560,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 > > debug-disk-label? IF ." Trying CHRP boot " .s cr THEN > 1 disk-chrp-boot ! > - dup load-chrp-boot-file ?dup 0 <> IF .s cr nip EXIT THEN > + dup load-chrp-boot-file ?dup 0 <> IF nip EXIT THEN > 0 disk-chrp-boot ! > > debug-disk-label? IF ." Trying GPT boot " .s cr THEN > @@ -600,6 +667,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 > > : try-partitions ( -- found? ) > try-dos-partition IF try-files EXIT THEN > + try-gpt-vfat-partition IF try-files EXIT THEN > \ try-iso9660-partition IF try-files EXIT THEN > \ ... more partition types here... > false Thomas
Thomas Huth <thuth@redhat.com> writes: > On Thu, 11 Jun 2015 15:48:49 +0530 > Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > >> For a GPT+LVM combination disk, older bootloader that does not support >> LVM, cannot load kernel from LVM. >> >> The patch add support to read from BASIC_DATA UUID >> partition. Installer has installed CHRP-BOOT config on a FAT file >> system. >> >> Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> >> --- >> slof/fs/packages/disk-label.fs | 72 ++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 70 insertions(+), 2 deletions(-) >> >> diff --git a/slof/fs/packages/disk-label.fs b/slof/fs/packages/disk-label.fs >> index fe1c25e..bf5fb5c 100644 >> --- a/slof/fs/packages/disk-label.fs >> +++ b/slof/fs/packages/disk-label.fs >> @@ -266,7 +266,7 @@ CONSTANT /gpt-part-entry >> >> : try-dos-partition ( -- okay? ) >> \ Read partition table and check magic. >> - no-mbr? IF cr ." No DOS disk-label found." cr false EXIT THEN >> + no-mbr? IF false EXIT THEN > > Maybe keep the output when "debug-disk-label?" is set? Sure. > >> count-dos-logical-partitions TO dos-logical-partitions >> >> @@ -408,6 +408,73 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 >> FALSE >> ; >> >> +\ Check for GPT MSFT BASIC DATA GUID - vfat based >> +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 >> +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 >> +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 >> +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 >> +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 >> + >> +: gpt-basic-data-partition? ( -- true|false ) >> + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 = IF >> + block gpt-part-entry>part-type-guid 4 + w@-le >> + GPT-BASIC-DATA-PARTITION-2 = IF >> + block gpt-part-entry>part-type-guid 6 + w@-le >> + GPT-BASIC-DATA-PARTITION-3 = IF >> + block gpt-part-entry>part-type-guid 8 + w@ > > Don't you have to byte-swap (w@-le) here, too? Looks somehow strange > that the other UID parts are read byte-swapped but this one is not? Interesting observation, I had used code from gpt-prep-partition? and did not doubt the validity of it. But that is how I see it in the memory though. 4 > 7e50d000 10 dump 7e50d000: a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 ......3D..h..&.. ok 4 > > >> + GPT-BASIC-DATA-PARTITION-4 = IF >> + block gpt-part-entry>part-type-guid a + w@ >> + block gpt-part-entry>part-type-guid c + l@ swap lxjoin > > dito ... here again no byteswap? > >> + GPT-BASIC-DATA-PARTITION-5 = IF >> + TRUE EXIT >> + THEN >> + THEN >> + THEN >> + THEN >> + THEN >> + FALSE >> +; > > I'm not a fan of deep nesting, so I'd maybe write this function rather > like this instead: Sure, looks much simpler. > > : gpt-basic-data-partition? ( -- true|false ) > block gpt-part-entry>part-type-guid > dup l@-le GPT-BASIC-DATA-PARTITION-1 <> IF FALSE EXIT THEN > dup 4 + w@-le GPT-BASIC-DATA-PARTITION-2 <> IF FALSE EXIT THEN > dup 6 + w@-le GPT-BASIC-DATA-PARTITION-3 <> IF FALSE EXIT THEN > ... > TRUE > ; > > ... but that's just cosmetics. > >> +: try-gpt-vfat-partition ( -- okay? ) >> + \ Read partition table and check magic. >> + no-gpt? IF cr ." No GPT disk-label found." cr false EXIT THEN > > Not directly related to this patch, but "no-gpt?" seems somewhat > imprecise to me ... what if the whole MBR is accidentially filled > with EE for example? That certainly does not indicate a valid GPT, > does it? > > I might be wrong, but as far as I can say that function should also > check for the aa55 magic at the end of the MBR, shouldn't it? > > Also I wonder whether you should check gpt>signature somewhere, either > in "no-gpt?" or here before touching gpt>part-entry-lba entry below? > I think that would contribute to the robustness of the code. Sure, we can make this changes. >> + 1 read-sector block gpt>part-entry-lba l@-le > > gpt>part-entry-lba seems to be an 8-bytes field ... so shouldn't you > access it with "x@ xbflip" instead? I will verfy this and make appropriate changes. > > By the way, it might be a good idea to add a "x@-le" helper for this to > little-endian.fs. > >> + block-size * to seek-pos >> + block gpt>part-entry-size l@-le to gpt-part-size >> + block gpt>num-part-entry l@-le dup 0= IF FALSE EXIT THEN >> + 1+ 1 ?DO >> + seek-pos 0 seek drop >> + block gpt-part-size read drop > > Can you be sure that gpt-part-size is only smaller than 4096 bytes > here? If not, you might overflow the block array, don't you? True. >> + gpt-basic-data-partition? IF >> + debug-disk-label? IF >> + ." GPT LINUX DATA partition found " cr >> + THEN >> + block gpt-part-entry>first-lba x@ xbflip >> + dup to part-start >> + block gpt-part-entry>last-lba x@ xbflip >> + over - 1+ ( addr offset len ) >> + dup block-size * to part-size >> + swap ( addr len offset ) >> + block-size * to part-offset >> + 0 0 seek >> + block block-size read >> + 3drop >> + \ block 0 byte 0-2 is a jump instruction in all FAT >> + \ filesystems. >> + \ e9 and eb are jump instructions in x86 assembler. >> + block c@ e9 <> IF >> + block c@ eb <> >> + block 2+ c@ 90 <> or >> + IF false EXIT THEN >> + THEN > > That's a copy of the code in try-dos-files ... could you please factor > out that stuff into a separate function to avoid duplicate code? Thanks! > (especially you also lack a UNLOOP before above EXIT otherwise, I > think) Yes. > >> + TRUE >> + UNLOOP EXIT >> + THEN >> + seek-pos gpt-part-size i * + to seek-pos >> + LOOP >> + FALSE >> +; >> + >> \ Extract the boot loader path from a bootinfo.txt file >> \ In: address and length of buffer where the bootinfo.txt has been loaded to. >> \ Out: string address and length of the boot loader (within the input buffer) >> @@ -493,7 +560,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 >> >> debug-disk-label? IF ." Trying CHRP boot " .s cr THEN >> 1 disk-chrp-boot ! >> - dup load-chrp-boot-file ?dup 0 <> IF .s cr nip EXIT THEN >> + dup load-chrp-boot-file ?dup 0 <> IF nip EXIT THEN >> 0 disk-chrp-boot ! >> >> debug-disk-label? IF ." Trying GPT boot " .s cr THEN >> @@ -600,6 +667,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 >> >> : try-partitions ( -- found? ) >> try-dos-partition IF try-files EXIT THEN >> + try-gpt-vfat-partition IF try-files EXIT THEN >> \ try-iso9660-partition IF try-files EXIT THEN >> \ ... more partition types here... >> false > > Thomas Regards Nikunj
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> writes: > Thomas Huth <thuth@redhat.com> writes: >>> +\ Check for GPT MSFT BASIC DATA GUID - vfat based >>> +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 >>> +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 >>> +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 >>> +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 >>> +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 >>> + >>> +: gpt-basic-data-partition? ( -- true|false ) >>> + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 = IF >>> + block gpt-part-entry>part-type-guid 4 + w@-le >>> + GPT-BASIC-DATA-PARTITION-2 = IF >>> + block gpt-part-entry>part-type-guid 6 + w@-le >>> + GPT-BASIC-DATA-PARTITION-3 = IF >>> + block gpt-part-entry>part-type-guid 8 + w@ >> >> Don't you have to byte-swap (w@-le) here, too? Looks somehow strange >> that the other UID parts are read byte-swapped but this one is not? > > Interesting observation, I had used code from gpt-prep-partition? and > did not doubt the validity of it. But that is how I see it in the memory > though. > > 4 > 7e50d000 10 dump > 7e50d000: a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 ......3D..h..&.. ok > 4 > And here the answer for that: https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-26 The GUIDs in this table are written assuming a little-endian byte order. For example, the GUID for an EFI System partition is written as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to the 16 byte sequence 28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h C9h 3Eh C9h 3Bh – only the first three blocks are byte-swapped. "only the first three blocks are byte-swapped" Regards, Nikunj
Thomas Huth <thuth@redhat.com> writes: > On Thu, 11 Jun 2015 15:48:49 +0530 > Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > >> + block-size * to seek-pos >> + block gpt>part-entry-size l@-le to gpt-part-size >> + block gpt>num-part-entry l@-le dup 0= IF FALSE EXIT THEN >> + 1+ 1 ?DO >> + seek-pos 0 seek drop >> + block gpt-part-size read drop > > Can you be sure that gpt-part-size is only smaller than 4096 bytes > here? So the size is usually 128, so this should be fine. https://en.wikipedia.org/wiki/GUID_Partition_Table Section: GPT header format "84 (0x54) 4 bytes Size of a single partition entry (usually 128)" > If not, you might overflow the block array, don't you? Regards Nikunj
On Wed, 17 Jun 2015 17:34:13 +0530 Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> writes: > > > Thomas Huth <thuth@redhat.com> writes: > >>> +\ Check for GPT MSFT BASIC DATA GUID - vfat based > >>> +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 > >>> +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 > >>> +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 > >>> +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 > >>> +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 > >>> + > >>> +: gpt-basic-data-partition? ( -- true|false ) > >>> + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 = IF > >>> + block gpt-part-entry>part-type-guid 4 + w@-le > >>> + GPT-BASIC-DATA-PARTITION-2 = IF > >>> + block gpt-part-entry>part-type-guid 6 + w@-le > >>> + GPT-BASIC-DATA-PARTITION-3 = IF > >>> + block gpt-part-entry>part-type-guid 8 + w@ > >> > >> Don't you have to byte-swap (w@-le) here, too? Looks somehow strange > >> that the other UID parts are read byte-swapped but this one is not? > > > > Interesting observation, I had used code from gpt-prep-partition? and > > did not doubt the validity of it. But that is how I see it in the memory > > though. > > > > 4 > 7e50d000 10 dump > > 7e50d000: a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 ......3D..h..&.. ok > > 4 > > > And here the answer for that: > > https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-26 > > The GUIDs in this table are written assuming a little-endian byte > order. For example, the GUID for an EFI System partition is written > as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to > the 16 byte sequence 28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h > C9h 3Eh C9h 3Bh – only the first three blocks are byte-swapped. > > "only the first three blocks are byte-swapped" Ok, this seems to be a GUID specialty (as opposed to UUIDs), also see: https://en.wikipedia.org/wiki/Globally_unique_identifier#Binary_encoding ... but that means that the last 8 bytes are always "big endian", so I think you could simplify your code here and check the last 8 bytes at once instead of checking 2 + 6 bytes separately, can't you? Thomas
On Thu, 18 Jun 2015 11:54:13 +0530 Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > Thomas Huth <thuth@redhat.com> writes: > > > On Thu, 11 Jun 2015 15:48:49 +0530 > > Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > > > >> + block-size * to seek-pos > >> + block gpt>part-entry-size l@-le to gpt-part-size > >> + block gpt>num-part-entry l@-le dup 0= IF FALSE EXIT THEN > >> + 1+ 1 ?DO > >> + seek-pos 0 seek drop > >> + block gpt-part-size read drop > > > > Can you be sure that gpt-part-size is only smaller than 4096 bytes > > here? > > So the size is usually 128, so this should be fine. > > https://en.wikipedia.org/wiki/GUID_Partition_Table > > Section: GPT header format > > "84 (0x54) 4 bytes Size of a single partition entry (usually 128)" Ok, so it should be fine when you have a valid GPT ... however, one thing I learnt during my past years: Never ever blindly trust data that you get from an external medium ... it could have been corrupted by accident or on purpose. So if you want to make your code more robust, maybe better check gpt>part-entry-size for being in the range of d# 128 to d# 4096 or you might have to debug very strange crashes one day... Thomas
Thomas Huth <thuth@redhat.com> writes: > On Wed, 17 Jun 2015 17:34:13 +0530 > Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> wrote: > >> Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> writes: >> >> > Thomas Huth <thuth@redhat.com> writes: >> >>> +\ Check for GPT MSFT BASIC DATA GUID - vfat based >> >>> +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 >> >>> +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 >> >>> +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 >> >>> +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 >> >>> +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 >> >>> + >> >>> +: gpt-basic-data-partition? ( -- true|false ) >> >>> + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 = IF >> >>> + block gpt-part-entry>part-type-guid 4 + w@-le >> >>> + GPT-BASIC-DATA-PARTITION-2 = IF >> >>> + block gpt-part-entry>part-type-guid 6 + w@-le >> >>> + GPT-BASIC-DATA-PARTITION-3 = IF >> >>> + block gpt-part-entry>part-type-guid 8 + w@ >> >> >> >> Don't you have to byte-swap (w@-le) here, too? Looks somehow strange >> >> that the other UID parts are read byte-swapped but this one is not? >> > >> > Interesting observation, I had used code from gpt-prep-partition? and >> > did not doubt the validity of it. But that is how I see it in the memory >> > though. >> > >> > 4 > 7e50d000 10 dump >> > 7e50d000: a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 ......3D..h..&.. ok >> > 4 > >> >> And here the answer for that: >> >> https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-26 >> >> The GUIDs in this table are written assuming a little-endian byte >> order. For example, the GUID for an EFI System partition is written >> as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to >> the 16 byte sequence 28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h >> C9h 3Eh C9h 3Bh – only the first three blocks are byte-swapped. >> >> "only the first three blocks are byte-swapped" > > Ok, this seems to be a GUID specialty (as opposed to UUIDs), also see: > > https://en.wikipedia.org/wiki/Globally_unique_identifier#Binary_encoding > > ... but that means that the last 8 bytes are always "big endian", so I > think you could simplify your code here and check the last 8 bytes at > once instead of checking 2 + 6 bytes separately, can't you? Yes, I am making these changes, will be sending the series after testing. Regards Nikunj
diff --git a/slof/fs/packages/disk-label.fs b/slof/fs/packages/disk-label.fs index fe1c25e..bf5fb5c 100644 --- a/slof/fs/packages/disk-label.fs +++ b/slof/fs/packages/disk-label.fs @@ -266,7 +266,7 @@ CONSTANT /gpt-part-entry : try-dos-partition ( -- okay? ) \ Read partition table and check magic. - no-mbr? IF cr ." No DOS disk-label found." cr false EXIT THEN + no-mbr? IF false EXIT THEN count-dos-logical-partitions TO dos-logical-partitions @@ -408,6 +408,73 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 FALSE ; +\ Check for GPT MSFT BASIC DATA GUID - vfat based +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 + +: gpt-basic-data-partition? ( -- true|false ) + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 = IF + block gpt-part-entry>part-type-guid 4 + w@-le + GPT-BASIC-DATA-PARTITION-2 = IF + block gpt-part-entry>part-type-guid 6 + w@-le + GPT-BASIC-DATA-PARTITION-3 = IF + block gpt-part-entry>part-type-guid 8 + w@ + GPT-BASIC-DATA-PARTITION-4 = IF + block gpt-part-entry>part-type-guid a + w@ + block gpt-part-entry>part-type-guid c + l@ swap lxjoin + GPT-BASIC-DATA-PARTITION-5 = IF + TRUE EXIT + THEN + THEN + THEN + THEN + THEN + FALSE +; + +: try-gpt-vfat-partition ( -- okay? ) + \ Read partition table and check magic. + no-gpt? IF cr ." No GPT disk-label found." cr false EXIT THEN + 1 read-sector block gpt>part-entry-lba l@-le + block-size * to seek-pos + block gpt>part-entry-size l@-le to gpt-part-size + block gpt>num-part-entry l@-le dup 0= IF FALSE EXIT THEN + 1+ 1 ?DO + seek-pos 0 seek drop + block gpt-part-size read drop + gpt-basic-data-partition? IF + debug-disk-label? IF + ." GPT LINUX DATA partition found " cr + THEN + block gpt-part-entry>first-lba x@ xbflip + dup to part-start + block gpt-part-entry>last-lba x@ xbflip + over - 1+ ( addr offset len ) + dup block-size * to part-size + swap ( addr len offset ) + block-size * to part-offset + 0 0 seek + block block-size read + 3drop + \ block 0 byte 0-2 is a jump instruction in all FAT + \ filesystems. + \ e9 and eb are jump instructions in x86 assembler. + block c@ e9 <> IF + block c@ eb <> + block 2+ c@ 90 <> or + IF false EXIT THEN + THEN + TRUE + UNLOOP EXIT + THEN + seek-pos gpt-part-size i * + to seek-pos + LOOP + FALSE +; + \ Extract the boot loader path from a bootinfo.txt file \ In: address and length of buffer where the bootinfo.txt has been loaded to. \ Out: string address and length of the boot loader (within the input buffer) @@ -493,7 +560,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 debug-disk-label? IF ." Trying CHRP boot " .s cr THEN 1 disk-chrp-boot ! - dup load-chrp-boot-file ?dup 0 <> IF .s cr nip EXIT THEN + dup load-chrp-boot-file ?dup 0 <> IF nip EXIT THEN 0 disk-chrp-boot ! debug-disk-label? IF ." Trying GPT boot " .s cr THEN @@ -600,6 +667,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 : try-partitions ( -- found? ) try-dos-partition IF try-files EXIT THEN + try-gpt-vfat-partition IF try-files EXIT THEN \ try-iso9660-partition IF try-files EXIT THEN \ ... more partition types here... false
For a GPT+LVM combination disk, older bootloader that does not support LVM, cannot load kernel from LVM. The patch add support to read from BASIC_DATA UUID partition. Installer has installed CHRP-BOOT config on a FAT file system. Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> --- slof/fs/packages/disk-label.fs | 72 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 70 insertions(+), 2 deletions(-)