Le 06/08/2016 à 16:18, Felix Miata a écrit :
Pascal Hambourg composed on 2016-08-06 12:01 (UTC+0200):
(location of GRUB's core image)
- or as a regular file in a filesystem appearing as /boot/grub/i386-pc/core.img (or /boot/grub/core.img with older versions of GRUB such as the one in Wheezy). This option is not recommended as the filesystem may move the blocks around and the location of the core image is hardcoded into the boot image.This "not recommended" philosophy corresponds almost perfectly with the practice universally complained about that Windows' installer replaces Grub code that it finds in the MBR with its own legacy/generic boot code, code which is just as capable of loading Grub code from a primary partition's PBR as it is loading Windows code from a primary partition's PBR, which is how Windows normally boots. When Grub is installed to a primary partition's PBR in the first place, Windows "hijacking" the MBR is a non-issue.[1]
I'm not sure I get your point and how it relates to the above.
As a practical matter, moving core image blocks around is uncommon, and
Indeed, but it may become less uncommon with modern filesystems such as ext4 and btrfs. Of course you can stick to good old ext2 for /boot if you can afford a separate partition for it.
I also thought about setting the "i" flag (immutable file) with chattr, but the manpage does not mention that it prevents the filesystem handler from moving the file blocks around for garbage collection, defragmentation or whatever.
I once had a boot failure on a system with the core image in /boot/grub. The only explaination which came into my mind was that the core image blocks had been moved around. FWIW, the filesystem was ext4.
However it might be worth noting that writing GRUB's core image as a regular file is perfectly safe if it is not the primary bootloader but is chainloaded by another instance of GRUB with the "multiboot" command (taking the core image location as argument) instead of the usual "chainloader" command (taking the boot sector location as argument).
just as easily fixed if and when it does occur as is reinstalling Grub to the MBR.
Easily fixed only if you can get your hands on the machine and boot a rescue system, e.g. by physical/KVM access or network boot.