Hacker News Reader

Comment by tbrock | Hacker News Reader

Cool explanation but I wonder why other operating systems don't have the same restriction. On OSX, for example, it used to be here: /private/var/vm/sleepimage

I suppose they have a clever boot loader with advanced drivers?

View on HN

I don't know whether they do, but a clever alternative is to have a stupid boot loader. You don't need to know how to traverse directories, you just need to know what blocks on disk to read. So, just write the number of the first block of the hibernation file to a known location (say in the first disk block) and you are all set.

Well, all: the file may be fragmented. Just store information about where to find all the blocks in the first block of the hibernation file (alternative view of this is that you have a very simple alternative file system on the disk that stores only one file (or a few, if you also want the ability to find the kernel for a cold boot)

Risk with such approaches is that they may not survive defragmentation of the drive. That's a minor risk for a hibernation file, I would say.

It's not minor. It's a freaking pain in the rear to have to fix this every time you defragment or move/resize a partition.

before the os goes into hibernation it can write the location of the hibernation image file to a special place for the bootloader to find. OSX also reserves space for the hibernation image, so it shouldn't get fragmented. And the defrag program probably doesn't increase the fragmentation for large files anyway.

If your defragmenter knows about the hibernation system, it will update the 'pointer' to the hibernation file.

Also, you can only hibernate an OS that knows about hibernation. Such an OS would be foolish if it wouldn't write the current location of the hibernation file whenever it went into hibernation.

So, this only is a problem if you hibernate your system, defragment its disk on another system using a defragmenter that doesn't know about hibernation files, and then try to wake up from hibernation. That might happen to people using an old version of a defragmenter, but I doubt it will happen often.

It's because the bootloader contains support for given filesystem. GRUB supports several filesystems, and so does UEFI (FAT read-write) and EFI on Macs (FAT read-write, HFS+ read only).

Back in the good old days, when LILO was the preferred boot loader for Linux, it did not have any idea how to read filesystems, and the block locations were simply recorded into the MBR.

I remember when GRUB first came out, thinking it was somewhat heretical to have filesystem code in a boot loader.

Slackware still uses LILO. Although most people will look at you like you're a fossil for using it these days, I've found it quite simple to configure and it has generally worked without a hitch.

Grub1 was not so bad to configure either, but Grub2 looks like a real stinker.

The biggest gotcha with LILO is that thing about writing the config to the boot sector. But then i have not used it in some years...

Personally I prefer syslinux, where the config resides in a easy-to-understand textfile, /boot/syslinux/syslinux.cfg, which can be on FAT or ext2/3/4 or btrfs. The only limitation is that all files that syslinux reads must be on the same partition.

Grub2 OTOH is definitely an abomination. Whoever thought it a good idea to require compiling the bootloader config into a binary should be given a thorough slapping with a medium-sized trout. That thing is an overengineered solution looking for a problem.

Are you sure that GRUB2 saves the config as a binary? I think on my Arch update-grub generates /boot/grub/grub.cfg which looks somewhat similar to good old menu.lst.

The binary part may be a bit harsh. But if i recall correctly grub2 compiles one config into another, and the result is topped with a "do not edit!" warning.

If you poke into the resulting config, you'll notice that it's just convenience†, and you could write the file by hand.

† in the same way that autotools is "convenience" saving you from writing makefiles and configure scripts.

Yes you can write the file by hand, but what you write is going to get overwritten on the next system update to grub2.

However, it is not due to fault of grub2, but due to distro-specific scripts that "helpfully" generate grub config.

I think bootloaders for Linux have more stages: the initial problem is the same, but then GRUB loads its configuration from [/boot]/grub2/grub.cfg. If it can load a config file, it can also load FS drivers or hibernation files, and prepare the actual kernel boot more subtlety.

Keep in mind this article was written in 2007 about the majority of NT installations at that time. Vista introduced a new unified boot architecture that replaced NTLDR with something that could work on BIOS and UEFI as well (and removed the monolithic EFI loader).

HFS+ stores the extent records for certain essential files (the bootloader, the catalog file, the extents overflow file, the journal, etc) in the file system header. So in order to find their physical locations you just need to read in the files system header and parse it.

Reply on news.ycombinator.com