Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
Frans Pop <email@example.com> writes:
> On Friday 13 June 2008, Goswin von Brederlow wrote:
>> > Earlier instances of the same problem. The 8 GiB barrier was because
>> > of the BIOS only issuing one 24-bit ATA command. I'm not sure how
>> > common will the new limit be in comparison.
>> As well as 518MB, 2GiB, 32GiB, 64GiB, 128GiB. PC BIOSes are just
>> riddled with those stupid problems.
>> >> I wonder what we should do about this:
>> >> - just always create a /boot partition when guided partitioning is
>> >> used
>> There is only one reason to have a seperate /boot: / is crypted. And
>> then you always need one.
> And LVM when used with some/most bootloaders, and most RAID setups.
That falls under "all other cases" below.
>> In all other cases a small / partition is the superior solution imho.
>> So my solution would be to default to a seperate small / partition at
>> the start of the disk unless crypted is selected and then start with a
>> small /boot.
> That may still not solve the problem for one important class of installs
> though: dual boot systems where the size of $other_os partition + the /
> partitions exceeds what the BIOS supports.
The margin between a 100MB /boot working and 300MB / not working is
negible. Actualy I only have 115MB used on / including /boot but then
I don't use the huge debian kernel.
>> The risk of detection problems certainly outweighs the drawbacks of
>> always having a small / or /boot.
> The disadvantage of that (assuming you want to avoid LVM) is that for a
> really small / you'll need at least separate /var, /usr, /tmp, /srv
> and /home partitions and then you have the question what the best
> relative sizes are for that particular user.
> Here's a wild idea that could be used to work around that.
> Create two partitions: / and a partition e.g. "/media/multifs".
> And then bind mount all other partitions inside the second one.
> /etc/fstab would look something like this:
> # /etc/fstab: static file system information.
> # <file system> <mount point> <type> <options> <dump> <pass>
> proc /proc proc defaults 0 0
> /dev/hda1 / ext3 errors=remount-ro 0 1
> /dev/hda3 /media/multifs ext3 defaults 0 2
> /dev/hda5 none swap sw 0 0
> /dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
> /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
> /media/multifs/home /home ext3 bind 0 0
> /media/multifs/srv /srv ext3 bind 0 0
> /media/multifs/usr /usr ext3 bind 0 0
> /media/multifs/var /var ext3 bind 0 0
> /media/multifs/tmp /tmp ext3 bind 0 0
> I've tested this and it actually seems to work. If people like this idea,
> all we'd need is to add support for it in partman :-)
It would be nice I guess. But I found that at some point or another I
always do need some lvm feature. And I've seen it happen often enough
on irc that someone needed to resize their partition. LVM just is the
best option. Someone that realy doesn't want it can probably bind
Maybe partman could support bind mounts without having an automatic
partitioning using them like above.
> One added advantage would be short fsck times for /.
Ideally / and /usr should be read-only. No fsck at all.