> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)
Posted Jan 27, 2012 1:53 UTC (Fri) by rgmoore (✭ supporter ✭, #75)
[Link]
Or a root filesystem on LVM, software RAID, or any other kind of complicated filesystem the bootloader can't understand. Although it looks as though GRUB2 is smart enough to get all those systems (including encrypted filesystems), so maybe separate /boot partitions are going to be as unnecessary as separate /bin, /sbin, and /lib directories.
The case for the /usr merge
Posted Jan 27, 2012 4:49 UTC (Fri) by jackb (subscriber, #41909)
[Link]
Is it possible to install grub 2 on a hard drive that has a LUKS header instead of a partition table?
The case for the /usr merge
Posted Jan 27, 2012 9:54 UTC (Fri) by jengelh (subscriber, #33263)
[Link]
There is no bootblock hole like there is on ext2, so the answer is no.
The case for the /usr merge
Posted Jan 30, 2012 19:13 UTC (Mon) by blitzkrieg3 (subscriber, #57873)
[Link]
Not _instead_ of, but you could get grub to read your partition table and then read the luks volume inside the partition.
The case for the /usr merge
Posted Jan 27, 2012 9:01 UTC (Fri) by job (guest, #670)
[Link]
I think it's much more common to utilize an initrd to boot from encrypted or DMed filesystems. At least all the normal distros do it that way.
The case for the /usr merge
Posted Jan 30, 2012 19:16 UTC (Mon) by blitzkrieg3 (subscriber, #57873)
[Link]
Initrd and separate /boot are two separate things. You could have the initrd on a / file system in your /boot directory, as you can have a separate /boot partition that just tells linux to load / on another partition and execute /bin/init there.
The case for the /usr merge
Posted Jan 28, 2012 12:04 UTC (Sat) by gbrun (guest, #82611)
[Link]
> Encrypted root filesystems, for one thing.
Yes. Another reason are special requirements for the boot loader itself.
For instance, I'm using ReiserFS for /. This FS employs "tail packing", i. e. there are cases when file data will be stored in units smaller than a full cluster ("sector").
File-system agnostic boot-loaders like LILO assume that all sectors in a block list have the same size, and therefore require ReiserFS volumes to be mounted with a special option which disables tail packing when updating the LILO configuration/mapping files.
But mounting ReiserFS with this option defeats its main advantage of space-efficiency for small files, so one does not generally want to do that.
As long as /boot is a separate small file system, this does not matter: One can either use ReiserFS for /boot and mount it with tail packing disabled, or use a different FS like ext2 there which only uses equally-sized clusters (this is what I do).
Also, the current FHS does not force anyone to put /boot onto a different partition - it's just an option.
Therefore, no matter where the basic discussion /bin vs. /usr/bin will eventually lead to, I strongly advise *not* to change the existing practice regarding /boot.