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#L2983-L3151 https://github.com/arvidjaar/bootinfoscript/blob/master/bootinfoscript#L2343-L2459 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/bootloader.py 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) that would return a string like “grub2”, “syslinux”, “windows”, etc. I can write the code. What do you think? Nikos
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#L2983-L3151 > https://github.com/arvidjaar/bootinfoscript/blob/master/bootinfoscript#L2343-L2459 > > 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/bootloader.py > > 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'?> 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. 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
Nikos Skalkotos
2015-Jun-19 12:31 UTC
Re: [Libguestfs] [synnefo-devel] boot loader detection
> On 19Jun, 2015, at 14:09, Richard W.M. Jones <rjones@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#L2983-L3151 >> https://github.com/arvidjaar/bootinfoscript/blob/master/bootinfoscript#L2343-L2459 >> >> 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/bootloader.py >> >> 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@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.