7:31 a.m.
On 19Jun, 2015, at 14:09, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
On Fri, Jun 19, 2015 at 01:53:13PM +0300, Nikos Skalkotos wrote:
> Hello,
>
> I was looking for a way to detect the installed boot loader of an image
> and I found this: https://github.com/arvidjaar/bootinfoscript
> This script will inspection a lot of things on a running system and will
> output a Report. The most interesting part is that it uses known Master
> and Volume Boot Record byte-patterns to determine the installed boot loader:
> https://github.com/arvidjaar/bootinfoscript/blob/master/bootinfoscript#L2...
> https://github.com/arvidjaar/bootinfoscript/blob/master/bootinfoscript#L2...
>
> Those signatures (byte patterns) are from real mode machine code but this
> code is not generated by a compiler and does not change often.
>
> I’ve isolated and simplified the signatures database here:
>
>
https://github.com/skalkoto/snf-image-creator/blob/develop/image_creator/...
>
> and I was wondering if you care to add 2 new libguestfs API methods e.g.:
>
> char * guestfs_inspect_get_mbr_bootloader(guestfs *g)
> char * guestfs_inspect_get_vbr_bootloader(guests *g, char *device)
What is 'vbr’?
When I refer to vbr I mean the Volume Boot Record. The boot record of a
partition: https://en.wikipedia.org/wiki/Volume_boot_record
In grub it is used if you choose to install the boot loader on the
partition and not the MBR. SYSLINUX on the other hand always
installs a generic boot loader on MBR that will execute the code
found in the VBR of the active partition. So EXTLINUX is installed on the
VBR of the /boot of / partition.
When a boot loader is installed on the VBR of a partition, it is not safe
most of the time to move around specific partition files. Grub-legacy for
example will try to put stage 1 in the MBR, stage 1.5 in the space between
the MBR and the first partition and will read stage 2 from the file system.
This can be done because stage 1.5 will load a read-only file system driver.
If there is not enough space between MBR and the first partition it will omit
stage 1.5 and will add a part of stage2 in the VBR. If this is the case, then
shrinking the partition of moving data is not safe. It’s important to know if
your partition record hosts any boot loader code if you are about to shrink it.
> that would return a string like “grub2”, “syslinux”, “windows”, etc.
> I can write the code.
>
> What do you think?
I wonder if an easier and more general path here is to add the
advanced detection signatures to 'file'. At the moment when you run
'file' on a hard drive it does some sort of detection like this:
# file -bsL /dev/sdb
DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x0,32,33), end-CHS (0xce,29,63),
startsector 2048, 250067632 sectors, extended partition table (last)
Adding it to file means it will be available in libguestfs automatically
(via 'guestfs_file' API), and means it would be generally useful
to other people as well.
However I'm not opposed to adding it to libguestfs if for some reason
it's not possible to add this to file.
Well, I can ask the file folks, but I’m not sure file is a suitable place.
I think file uses real signatures and magic patterns to determine the various
file types. The ones provided here are byte code patterns that were extracted
simply by observing the first bytes of MBR after installing the various boot
loaders on them. This works in practice, but is hacky.
If you check the last 2 bytes of the first sector of a block device and
they are 0x55,0xaa, then you can safely assume that this is a DOS/MBR boot
sector since the last 2 bytes which according to the MBR specification are
the boot signature have the correct value. After this you may read the
partition table and extract the info that your execution of file displays.
Matching patterns in the Bootstrap code area of the MBR is a different thing.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
You received this message because you are subscribed to the Google Groups "Synnefo
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
synnefo-devel+unsubscribe(a)googlegroups.com.
For more options, visit https://groups.google.com/d/optout.