Jump to content











Photo
- - - - -

which MBR suitable to bootstrap Linux on 4K-sectors ?


  • Please log in to reply
9 replies to this topic

#1 Ninho

Ninho

    Member

  • Members
  • 63 posts

Posted 19 October 2015 - 01:29 PM

Still after booting the "unbootable" external (USB) disk with 4K (native) sectors,
using MBR-style partitionment. I'm loading and transferring initial control to the
MBR using Chenall and Yaya2007's Grub4DOS with its integrated USB2-driver and
real-mode int13.

I installed a modern Linux distro - AntiX 15 - to the device, also setting up the companion grub (2) to the MBR.

Unfortunately Grub(2) does not seem up to the task :-( It loses foot and crashes very early while still in the MBR (custom BIOS-level debugger trapped the faulting instruction and I examined the memory, so there is no doubt that grub's MBR - 1st full 4K - was loaded and run and /it/ faulted, @ some 0x20D bytes into the sector).

Is the "grand" bootloader advertised to understand 4K-native+MBR ?
Else what MBR code should I try ? Syslinux ?

another leas : while Grub4DOS will not interpret file systems on the 4K-device, it occurred to me I could, perhaps, have it load the "vmlinuz" kernel as a "blocklist".
Would one of the bootland Wizzards suggest an easy way to get the blocklist (list of sectors) in question ?

Edited by Ninho, 19 October 2015 - 01:35 PM.


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14757 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 October 2015 - 02:47 PM

another leas : while Grub4DOS will not interpret file systems on the 4K-device, it occurred to me I could, perhaps, have it load the "vmlinuz" kernel as a "blocklist".
Would one of the bootland Wizzards suggest an easy way to get the blocklist (list of sectors) in question ?

I am not sure to understand. :unsure:

The blocklist command in grub4dos will list extent(s) for a file (provided that it "sees" the file through the filesystem).

Under NT there are a couple tools, getFileExtents.exe or myfragmenter.exe, some reference here:

http://www.msfn.org/...essful-unbrick/

 

I am pretty sure that there similar ones in Linux, though I know none of them.

Provided that they actually work with 4K sectors, the findpart tools may also contain something useful (but it's a lot of time I don't use them and the feature may be in them or maybe it not :unsure::

http://www.partition...m/utilities.htm

 

:duff:

Wonko



#3 Ninho

Ninho

    Member

  • Members
  • 63 posts

Posted 19 October 2015 - 03:34 PM

another leasIDEA : while Grub4DOS will not interpret file systems on the 4K-devic...

I am not sure to understand. :unsure:

No wonder ;=) I made a mess while editing. Eyesight is worse and worse (sigh).

The blocklist command in grub4dos will list extent(s) for a file (provided that it "sees" the file through the filesystem).

Agreed, and it is the issue since Grub4dos 0.4.6.a even the newest build is still broken on 4K-sectors; does not "see" any file systems, so that only absolute (MBR based) offsets can be used, not files. Blocklists /should/ be OK.

{Note to myself : collect sample hex dumps of critical disk areas from partitions (various file systems) and send attention / Mr. Yaya2007.}

Under NT there are a couple tools, getFileExtents.exe or myfragmenter.exe, some reference here:
http://www.msfn.org/...essful-unbrick/

noting for further reference. However, since the file I would have to gather the "blocklist" for is on an ext3 Linux partition, operating from NT is probably not the shortest route (I do use "ext2fsd" occasionally to access Linux file systems)

I am pretty sure that there similar ones in Linux, though I know none of them.

Some one else will hopefully chime in proudly with Linux command line magix !

Provided that they actually work with 4K sectors, the findpart tools may also contain something useful
http://www.partition...m/utilities.htm

Noted...but alas,

Svend Olaf Mikkelsen, 1999-2014.
Note: All utilities are for disks with a 512 bytes logical sector size.


Edited by Ninho, 19 October 2015 - 04:28 PM.


#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14757 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 October 2015 - 03:51 PM

It seems like you have to compile your own little proggy using the FS_IOC_FIEMAP:

https://freethreads....u-ext3-extents/

http://smackerelofop...le-extents.html

 

:duff:

Wonko



#5 Ninho

Ninho

    Member

  • Members
  • 63 posts

Posted 19 October 2015 - 04:36 PM

It seems like you have to compile your own little proggy using the FS_IOC_FIEMAP:
Wonko


Maybe not. I found this - while you were typing your answer - which looks promising :
http://serverfault.c...blocks-on-linux

#6 Ninho

Ninho

    Member

  • Members
  • 63 posts

Posted 19 October 2015 - 05:45 PM

...From the antix (live) now running from an "iso" in VMware player in a corner of this Windoze XP destop
(aren't these toys wonderful?) I mounted the 4K-sector-thing and ran > debugfs /dev/sda2, then
" stat /boot/vmlinuz-4.0.5-antix. bla blah...", in response getting (abridged) :
______________________________________________________________

Inode: 376849 ... Size: 3633152

Fragment: Address:0 Number:0 Size:0

BLOCKS:

(0-11): 788119-188130, (IND):788131, (12-886): 788132-789006

TOTAL: 888

_____________________________________________________________


Scary, no :=) ? At least the number of blocks is 888, NOT 666.
Without knowing much (or zilch) about ext3 internals, it appears
after an elementary calculation that the "blocks" in the above report
are 4,096 bytes long, so numbers will have to be multiplied by 8
in order to satisfy Grub4DOS (which counts by 512 byte units always).

Next it appears the vmlinuz 'kernel' is contiguous, though I wonder
whether the embedded "IND" (index?) block should be included or not
when passing the extent to Grub4DOS as a blocklist.

Finally I'll have to peek inside the partition and determine if
the block numbers are indeed absolute offsets from the disk's start,
or else from the partition's starting point.

Or, anybody familiar with linux extended systems, help with the sleuthing ?

Edited by Ninho, 19 October 2015 - 05:47 PM.


#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14757 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 October 2015 - 06:03 PM

Just dd (from Linux of course) the kernel file to a new file, then dd the sector range you think correct to another file and compare if files are the same? :unsure:

 

:duff:

Wonko



#8 Ninho

Ninho

    Member

  • Members
  • 63 posts

Posted 19 October 2015 - 08:08 PM

Just dd (from Linux of course) the kernel file to a new file, then dd the sector range you think correct to another file and compare if files are the same? :unsure:


Yep, a good plan. Alternatively, since I'm more at ease and have more tools handy in Windows than Linux, I mounted the ext partition using Ext2fs (unpaid promotion again) and copied the kernel file to the desktop ! "Real men" use dd, they say... smart ones are content to drag-n-drop :=)

And examination of the file has confirmed calculations along the line of thought introduced above, which is comforting ! I'll translate the findings into the language that Grub4DOS understands and try to boot it tomorrow;

Surprisingly that compressed binary kernel starts like an MS executable mock-up, "MZ" etc and even a "PE" header. The beast is everywhere, even where you'd expect to find her the less !

#9 Ninho

Ninho

    Member

  • Members
  • 63 posts

Posted 21 October 2015 - 04:21 PM

Update : as it turns out, Grub4DOS does /not/ accept a 'kernel' file specified in 'blocklist' notation. This last coup du sort nails the coffin, at the moment I have more important real-life issues to sort out than this. It's not been time completely lost : I learnt about debugfs and added its 'stat' command to my bag of tricks, at least...

#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14757 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 October 2015 - 07:43 AM

Update : as it turns out, Grub4DOS does /not/ accept a 'kernel' file specified in 'blocklist' notation. This last coup du sort nails the coffin, at the moment I have more important real-life issues to sort out than this. It's not been time completely lost : I learnt about debugfs and added its 'stat' command to my bag of tricks, at least...

I am wondering (just an idea for your next experiment, when you will have time) if it would be possible to make something similar to what the good ol' hmload was used for:

https://web.archive....ent/GrubForDOS/

through dd and/or some other internal grub4dos commands.

 

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users