Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
On Sun, Jun 15, 2008 at 04:52:32PM +0200, Frans Pop wrote: 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: snip # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/hda1 / ext3errors=remount-ro 0 1 /dev/hda3 /media/multifs ext3defaults0 2 /dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /media/multifs/home /home ext3bind0 0 /media/multifs/srv/srvext3bind0 0 /media/multifs/usr/usrext3bind0 0 /media/multifs/var/varext3bind0 0 /media/multifs/tmp/tmpext3bind0 0 /snip 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 :-) One added advantage would be short fsck times for /. I've done this sort of thing before, in the distant past; I've moved away from it because I couldn't find any real advantages to not just using a single large root partition plus a small /boot. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
Frans Pop [EMAIL PROTECTED] 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. Yep. 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: snip # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/hda1 / ext3errors=remount-ro 0 1 /dev/hda3 /media/multifs ext3defaults0 2 /dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /media/multifs/home /home ext3bind0 0 /media/multifs/srv/srvext3bind0 0 /media/multifs/usr/usrext3bind0 0 /media/multifs/var/varext3bind0 0 /media/multifs/tmp/tmpext3bind0 0 /snip 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 mount themself. 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. Cheers, FJP MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
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. Yep. 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. 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 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: snip # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/hda1 / ext3errors=remount-ro 0 1 /dev/hda3 /media/multifs ext3defaults0 2 /dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /media/multifs/home /home ext3bind0 0 /media/multifs/srv /srvext3bind0 0 /media/multifs/usr /usrext3bind0 0 /media/multifs/var /varext3bind0 0 /media/multifs/tmp /tmpext3bind0 0 /snip 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 :-) One added advantage would be short fsck times for /. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
Robert Millan [EMAIL PROTECTED] writes: On Thu, Jun 12, 2008 at 12:58:13PM +0200, Frans Pop wrote: On Wednesday 11 June 2008, Robert Millan wrote: This is not a bug about a problem I found, but about a problem I think can become common with the introduction of 2 TiB disks. A while ago, I found that bochsbios (the free BIOS used by bochs and qemu) had an incomplete implementation of LBA48 that caused a fatal error when attempting to access a disk sector above 2^32: There is also the (already current and somewhat common, see e.g. #481169) issue described here: http://wiki.linuxquestions.org/wiki/GRUB#Error_18 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. 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. - add some special cases, but how to reliably detect them? - always ask if a separate /boot should be created (or probably better: create separate recipes for that) - only document the issues and how to solve them manually The problem with attempting to detect this bug, is that there's a chance our probe causes the BIOS to crash, or abort with fatal error. I think this would outweight the benefit. The risk of detection problems certainly outweighs the drawbacks of always having a small / or /boot. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
On Wednesday 11 June 2008, Robert Millan wrote: This is not a bug about a problem I found, but about a problem I think can become common with the introduction of 2 TiB disks. A while ago, I found that bochsbios (the free BIOS used by bochs and qemu) had an incomplete implementation of LBA48 that caused a fatal error when attempting to access a disk sector above 2^32: There is also the (already current and somewhat common, see e.g. #481169) issue described here: http://wiki.linuxquestions.org/wiki/GRUB#Error_18 That is something we also do not handle, so I don't know why your case should be different. I wonder what we should do about this: - just always create a /boot partition when guided partitioning is used - add some special cases, but how to reliably detect them? - always ask if a separate /boot should be created (or probably better: create separate recipes for that) - only document the issues and how to solve them manually Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
On Thu, Jun 12, 2008 at 12:58:13PM +0200, Frans Pop wrote: On Wednesday 11 June 2008, Robert Millan wrote: This is not a bug about a problem I found, but about a problem I think can become common with the introduction of 2 TiB disks. A while ago, I found that bochsbios (the free BIOS used by bochs and qemu) had an incomplete implementation of LBA48 that caused a fatal error when attempting to access a disk sector above 2^32: There is also the (already current and somewhat common, see e.g. #481169) issue described here: http://wiki.linuxquestions.org/wiki/GRUB#Error_18 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. I wonder what we should do about this: - just always create a /boot partition when guided partitioning is used - add some special cases, but how to reliably detect them? - always ask if a separate /boot should be created (or probably better: create separate recipes for that) - only document the issues and how to solve them manually The problem with attempting to detect this bug, is that there's a chance our probe causes the BIOS to crash, or abort with fatal error. I think this would outweight the benefit. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485790: generate separate /boot as workaround for buggy LBA48 ?
Package: debian-installer Severity: normal This is not a bug about a problem I found, but about a problem I think can become common with the introduction of 2 TiB disks. A while ago, I found that bochsbios (the free BIOS used by bochs and qemu) had an incomplete implementation of LBA48 that caused a fatal error when attempting to access a disk sector above 2^32: http://sourceforge.net/tracker/index.php?func=detailaid=1921733group_id=12580atid=312580 Although this was fixed, seening how often it happens that we find bugs in all the variety of BIOS implementations out there, I would expect some of them will have similar problems. Of course, there's no way for me to reliably find how common will this be; perhaps we're lucky and bochsbios is the only one which had this, but I think it's better to be safe than sorry, so I would propose that D-I avoids possible problems by generating a separate /boot in the default partition layout whenever the disk size is above 2 TiB. Excuse me for not providing a patch, but I'm totally clueless about how the auto-partitioning heuristics work. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
