1

I have a dual boot system with this partition layout:

# fdisk -l Disk /dev/sda: 596.2 GiB, 640135028736 bytes, 1250263728 sectors Disk model: SAMSUNG HM640JJ Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x08c427b9 Device Boot Start End Sectors Size Id Type /dev/sda1 80325 30800324 30720000 14.7G 7 HPFS/NTFS/exFAT /dev/sda2 30800325 440400559 409600235 195.3G 7 HPFS/NTFS/exFAT /dev/sda3 440403966 1132820479 692416514 330.2G f W95 Ext'd (LBA) /dev/sda4 * 1132820480 1250263039 117442560 56G 83 Linux /dev/sda5 440403968 1116043263 675639296 322.2G 7 HPFS/NTFS/exFAT /dev/sda6 1116045312 1132820479 16775168 8G 82 Linux swap / Solaris Partition table entries are not in disk order.

and it's MBR according to parted and gdisk. After I installed linux I never booted to windows again and regularly backup the entire 60G partition of linux and first 63 sectors of HDD using dd to an external HDD while I boot from a live linux image.

dd if=/dev/sda4 of=linux.img bs=4096 conv=fdatasync dd if=/dev/sda of=boot.img bs=512 count=63 conv=fdatasync

after my linux broke (for the first time) I attempted to restore it using the inverse above boot from live then

dd if=linux.img of=/dev/sda4 bs=4096 conv=fdatasync dd if=boot.img of=/dev/sda bs=512 conv=fdatasync

dd didn't report any errors and linux partition recovered as intended. however I was unable to boot (system was keeping reboot as there was something wrong with Grub, a blinking cursor then sudden restart over and over). Finally booted again using live then chroot and grub-install. after this I was able to boot again normally.

I backup the first 63 sectors because Grub uses there for the core image (if I'm not wrong). and the first thing I did after booting was dumping there to a newboot.img file, then:

 diff boot.img newboot.img

returned nothing, which means even after re-installing grub, that area is the same.

  • What's the root cause of not being able to boot in this case?
  • How should I do the backup (avoiding 3rd parties)?

To best of my knowledge, no partition changes, no UUIDs... both images created together. Can grub code continues somewhere after sector 63? where and how long?

Thank you.

Improve this question

1 Answer 1

Reset to default
1 
dd if=/dev/sda of=boot.img bs=512 count=63 conv=fdatasync

You're backing up the Master Boot Record and 62 other sectors, so 31.5 kilobytes. But the part of GRUB2 embedded on the first track of the disk after the MBR can easily be bigger than that.

Yes, you may have checked the size of /boot/grub/i386-pc/core.img and found it smaller than that. But the core.img is not all that gets embedded into the space between the MBR and the beginning of the first partition. At minimum, modern GRUB2 also embeds some GRUB modules:

  • fshelp.mod, a generic support module for various filesystems
  • part_msdos.mod, MBR partition table support
  • a filesystem support module to match the filesystem containing your Linux /boot directory.

On my system, the total size of core.img and those minimal modules, assuming that your /boot filesystem is ext2/3/4 (i.e. supported by ext2.mod which is pretty small) works out to a bit over 36 kilobytes. Your Linux distribution may choose to embed more modules in order to provide more functionality: the modules listed above are a very bare-bones set.

The modules can be compressed with the LZMA algorithm to keep the total size down, but modern GRUB2 also uses Reed-Solomon error correction codes to protect the embedded code from bit errors, which pushes up the size again.

I've been trying to develop a program to detect various bootloaders and read their low-level configuration for diagnostic/forensic purposes. As it turns out, I've been essentially duplicating the functionality of bootinfoscript (with some differences). But if I'm reading the on-disk structures correctly, the total size of the embedded GRUB2 code on my system is 102 sectors, so 51 kilobytes.

Improve this answer
6
  • Tysm. So, essentially there's no robust way to find out the exact amount and placement of the code... besides it warns me that sector 23 is using by some program, avoiding it... So the only remaining option is to backup nearly 40MB of junk... Then will the final result be reliable if doing dd with count of 80324? Commented Mar 24, 2019 at 23:52
  • Since the modern convention would be to place the beginning of the first partition exactly 1 MB from the beginning of the disk and GRUB2 will practically always fit in there, backing up the first 1 MB should be enough in the vast majority of cases. Commented Mar 25, 2019 at 0:21
  • Ok... 63 was somewhere back in my mind as starting of first partition was traditionally on 64 that's why I used to do it. Commented Mar 25, 2019 at 0:29
  • Sounds like the old DOS-era convention that predates modern data alignment recommendations. Commented Mar 25, 2019 at 0:41
  • 1
    @pevik That page you linked is from year 2014, and my answer is from year 2019. There might have been some developments in between the two. Anyway, the idea that the first partition will begin at block #64 is no longer accurate: modern OSs will prefer to start the first partition exactly 1 MiB from the start of the disk, or at block #2048 on disks using the common 512-byte blocksize. So there's often more than 62 blocks available for the GRUB core.img and any GRUB modules that have been appended to the core.img. Commented Feb 10, 2021 at 10:44

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.