* Disk Geometries reported incorrectly on 2.6.0-testX @ 2003-11-28 4:58 Apurva Mehta 2003-11-28 14:24 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Apurva Mehta @ 2003-11-28 4:58 UTC (permalink / raw) To: Linux Kernel Mailing List Hi, On 2.6.0-testx kernels, I have noticed that there are problems with GNU Parted. Parted says that the disk geometries reported by the kernel are incorrect. Here is a sample error message : --- Error: The partition table on /dev/hdb is inconsistent. There are many reasons why this might be the case. However, the most likely reason is that Linux detected the BIOS geometry for /dev/hdb incorrectly. GNU Parted suspects the real geometry should be 782/128/63 (not 6256/16/63). You should check with your BIOS first, as this may not be correct. You can inform Linux by adding the parameter hdb=782,128,63 to the command line. See the LILO or GRUB documentation for more information. If you think Parted's suggested geometry is correct, you may select Ignore to continue (and fix Linux later). Otherwise, select Cancel (and fix Linux and/or the BIOS now). --- Please let me know if you'll need any additional information. I am not subscribed to this list so please cc me any replies. Regards, - Apurva ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-28 4:58 Disk Geometries reported incorrectly on 2.6.0-testX Apurva Mehta @ 2003-11-28 14:24 ` Andries Brouwer 2003-11-29 2:22 ` Andrew Clausen 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-11-28 14:24 UTC (permalink / raw) To: Apurva Mehta, Linux Kernel Mailing List; +Cc: bug-parted On Fri, Nov 28, 2003 at 10:28:54AM +0530, Apurva Mehta wrote: > On 2.6.0-testx kernels, I have noticed that there are problems with > GNU Parted. Parted says that the disk geometries reported by the > kernel are incorrect. Yes. Parted should be fixed not to complain. There is no such thing as a "correct" disk geometry. Roughly speaking the kernel no longer attempts to report anything, so calling HDIO_GETGEO is useless (for this purpose). Andries ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-28 14:24 ` Andries Brouwer @ 2003-11-29 2:22 ` Andrew Clausen 2003-11-29 5:16 ` Szakacsits Szabolcs 0 siblings, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-11-29 2:22 UTC (permalink / raw) To: Andries Brouwer; +Cc: Apurva Mehta, Linux Kernel Mailing List, bug-parted On Fri, Nov 28, 2003 at 03:24:52PM +0100, Andries Brouwer wrote: > On Fri, Nov 28, 2003 at 10:28:54AM +0530, Apurva Mehta wrote: > > > On 2.6.0-testx kernels, I have noticed that there are problems with > > GNU Parted. Parted says that the disk geometries reported by the > > kernel are incorrect. > > Yes. Parted should be fixed not to complain. > There is no such thing as a "correct" disk geometry. Yes there is. "Correct" is defined by the BIOS. It is important for boot loaders (in particular Windows). I'm not sure if this is still a big issue worth worrying about. Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 2:22 ` Andrew Clausen @ 2003-11-29 5:16 ` Szakacsits Szabolcs 2003-11-29 9:18 ` Sven Luther ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-11-29 5:16 UTC (permalink / raw) To: Andrew Clausen Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, 29 Nov 2003, Andrew Clausen wrote: > On Fri, Nov 28, 2003 at 03:24:52PM +0100, Andries Brouwer wrote: > > > > There is no such thing as a "correct" disk geometry. > > Yes there is. "Correct" is defined by the BIOS. It is important > for boot loaders (in particular Windows). I suspected the same ... What Windows you mean? DOS (9x/ME/etc) or NT based (NT4/2000/XP/2003)? All? > I'm not sure if this is still a big issue worth worrying about. IMHO it might be. At least I'm getting an increasing number of emails from people who can't boot Windows anymore after resizing and repartitioning NTFS on Linux. Everybody thinks it's the Linux NTFS code's fault but so far it was always about the repartitioning going wrong. I just had to write a FAQ entry about this issue recently http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot Some users, having problems, did mention the usage of 2.6 kernel. If the geometry changed during the fdisk, etc process then it could result also booting problem? It's just a speculation because I've never had enough information to investigate. Also, can Parted save/restore the full and exact partition table a scriptable way? I mean something like this: sfdisk -d /dev/hda > hda.pt # save sfdisk /dev/hda < hda.pt # restore sfdisk can't recover geometry so apparently no one-liner, widely available, partition table backup/recovery is possible at present on Linux :-o dd if=/dev/hda of=hda.mbr bs=512 count=1 won't save the logical partitions. Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 5:16 ` Szakacsits Szabolcs @ 2003-11-29 9:18 ` Sven Luther 2003-11-29 12:41 ` Andries Brouwer 2003-11-29 12:34 ` Andries Brouwer 2003-11-29 22:33 ` Andrew Clausen 2 siblings, 1 reply; 49+ messages in thread From: Sven Luther @ 2003-11-29 9:18 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andrew Clausen, Apurva Mehta, Andries Brouwer, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 07:16:31AM +0200, Szakacsits Szabolcs wrote: > > On Sat, 29 Nov 2003, Andrew Clausen wrote: > > On Fri, Nov 28, 2003 at 03:24:52PM +0100, Andries Brouwer wrote: > > > > > > There is no such thing as a "correct" disk geometry. > > > > Yes there is. "Correct" is defined by the BIOS. It is important > > for boot loaders (in particular Windows). > > I suspected the same ... What Windows you mean? DOS (9x/ME/etc) or NT based > (NT4/2000/XP/2003)? All? > > > I'm not sure if this is still a big issue worth worrying about. > > IMHO it might be. At least I'm getting an increasing number of emails from > people who can't boot Windows anymore after resizing and repartitioning > NTFS on Linux. Everybody thinks it's the Linux NTFS code's fault but so far > it was always about the repartitioning going wrong. I just had to write a > FAQ entry about this issue recently > > http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot > > Some users, having problems, did mention the usage of 2.6 kernel. If the > geometry changed during the fdisk, etc process then it could result also > booting problem? It's just a speculation because I've never had enough > information to investigate. > > Also, can Parted save/restore the full and exact partition table a > scriptable way? I mean something like this: > > sfdisk -d /dev/hda > hda.pt # save > sfdisk /dev/hda < hda.pt # restore > > sfdisk can't recover geometry so apparently no one-liner, widely available, > partition table backup/recovery is possible at present on Linux :-o > dd if=/dev/hda of=hda.mbr bs=512 count=1 won't save the logical partitions. Yes, that would be a good idea, it would be even nice to automatically save the partition table the first time parted access the harddisk. The problem is that it needs to be saved on a separate harddisk though, or printed or something such. The partition table saving/restoring would be part of the partition table specific code, so you could know the logical partitions or whatever your precise non-mbr partition table mandates. Friendly, Sven Luther ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 9:18 ` Sven Luther @ 2003-11-29 12:41 ` Andries Brouwer 2003-11-30 11:44 ` Szakacsits Szabolcs 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-11-29 12:41 UTC (permalink / raw) To: Sven Luther Cc: Szakacsits Szabolcs, Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted > > Also, can Parted save/restore the full and exact partition table a > > scriptable way? I mean something like this: > > > > sfdisk -d /dev/hda > hda.pt # save > > sfdisk /dev/hda < hda.pt # restore > > > > sfdisk can't recover geometry so apparently no one-liner, widely available, > > partition table backup/recovery is possible at present on Linux :-o > > dd if=/dev/hda of=hda.mbr bs=512 count=1 won't save the logical partitions. sfdisk has a slightly different option: -O will save all sectors that you change during an sfdisk operation, so that you can restore them later. You see, saving the logical partitions is not enough - these sectors are spread out over the disk, and there used to be something else where these sectors are written. If the user makes a partitioning mistake he destroys a sector worth of data. It is that data that sfdisk -O will save (and -I will restore). ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 12:41 ` Andries Brouwer @ 2003-11-30 11:44 ` Szakacsits Szabolcs 2003-11-30 15:19 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-11-30 11:44 UTC (permalink / raw) To: Andries Brouwer Cc: Sven Luther, Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, 29 Nov 2003, Andries Brouwer wrote: > You see, saving the logical partitions is not enough - these sectors > are spread out over the disk, and there used to be something else > where these sectors are written. Yes but fdisk, cfdisk and parted doesn't have this feature either. Those are what people use most often from the command line for interactive partitioning (use the right tool for the job). Saving the table with sfdisk is the best but imperfect workaround. sfdisk can't know what steps will be done later on with a different partitioning tool. But at least its data should be enough to diagnose problems in the other partitioning tools. Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 11:44 ` Szakacsits Szabolcs @ 2003-11-30 15:19 ` Andries Brouwer 0 siblings, 0 replies; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 15:19 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Sven Luther, Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 01:44:44PM +0200, Szakacsits Szabolcs wrote: > > On Sat, 29 Nov 2003, Andries Brouwer wrote: > > > You see, saving the logical partitions is not enough - these sectors > > are spread out over the disk, and there used to be something else > > where these sectors are written. > Saving the table with sfdisk is the best but imperfect workaround. sfdisk > can't know what steps will be done later on with a different partitioning > tool. > > But at least its data should be enough to diagnose problems in the other > partitioning tools. You can save the data using "cfdisk -Pr". Slightly more readable versions are given by "cfdisk -Pt", "cfdisk -Ps", "sfdisk -d", "sfdisk -x -uS -l". ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 5:16 ` Szakacsits Szabolcs 2003-11-29 9:18 ` Sven Luther @ 2003-11-29 12:34 ` Andries Brouwer 2003-11-29 13:50 ` John Bradford 2003-11-29 22:27 ` Andrew Clausen 2003-11-29 22:33 ` Andrew Clausen 2 siblings, 2 replies; 49+ messages in thread From: Andries Brouwer @ 2003-11-29 12:34 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 07:16:31AM +0200, Szakacsits Szabolcs wrote: > http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot > > Some users, having problems, did mention the usage of 2.6 kernel. If the > geometry changed during the fdisk, etc process then it could result also > booting problem? Let me continue to stress: geometry does not exist. Consequently, it cannot change. fdisk does not set any geometry, it writes a partition table. Start and size of each partition are given twice: in absolute sector units (LBA) and in CHS units. The former uses 32 bits, and with 512-byte sectors this works up to 2TB. People are starting to hit that boundary now. The latter uses 24 bits, which works up to 8GB. Modern systems no longer use it (but the details are complicated). Usually booting goes like this: the BIOS reads sector 0 (the MBR) from the first disk, and starts the code found there. What happens afterwards is up to that code. If that code uses CHS units to find a partition, and if the program that wrote the table has different ideas about those units than the BIOS, booting may fail. Andries ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 12:34 ` Andries Brouwer @ 2003-11-29 13:50 ` John Bradford 2003-11-29 14:04 ` Stefan Smietanowski ` (2 more replies) 2003-11-29 22:27 ` Andrew Clausen 1 sibling, 3 replies; 49+ messages in thread From: John Bradford @ 2003-11-29 13:50 UTC (permalink / raw) To: Andries Brouwer, Szakacsits Szabolcs Cc: Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted > Let me continue to stress: geometry does not exist. > Consequently, it cannot change. > fdisk does not set any geometry, it writes a partition table. > > Start and size of each partition are given twice: in absolute sector > units (LBA) and in CHS units. The former uses 32 bits, and with 512-byte > sectors this works up to 2TB. People are starting to hit that boundary now. > The latter uses 24 bits, which works up to 8GB. Modern systems no longer > use it (but the details are complicated). Why don't we take the opporunity to make all CHS code configurable out of the kernel, and define a new, more compact, partition table format which used LBA exclusively, and allowed more than four partitions in the main partition table? I know it sounds pointless to define a new partitioning scheme when there are so many already in existance, but for dedicated Linux machines, only being able to define four partitions without resorting to 'extended' partitions, which store there partitioning data in other parts of the disk, is a needless limitation. We could also ensure that there is sufficient magic in the partition table to make identifying it easy and reliable. John. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 13:50 ` John Bradford @ 2003-11-29 14:04 ` Stefan Smietanowski 2003-11-29 17:01 ` Sven Luther 2003-11-29 22:31 ` Andrew Clausen 2 siblings, 0 replies; 49+ messages in thread From: Stefan Smietanowski @ 2003-11-29 14:04 UTC (permalink / raw) To: John Bradford Cc: Andries Brouwer, Szakacsits Szabolcs, Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted Hi. > Why don't we take the opporunity to make all CHS code configurable out > of the kernel, and define a new, more compact, partition table format > which used LBA exclusively, and allowed more than four partitions in > the main partition table? > > I know it sounds pointless to define a new partitioning scheme when > there are so many already in existance, but for dedicated Linux > machines, only being able to define four partitions without resorting > to 'extended' partitions, which store there partitioning data in other > parts of the disk, is a needless limitation. We could also ensure > that there is sufficient magic in the partition table to make > identifying it easy and reliable. Then just select a partitioning scheme that fills those features you request instead, as you say - there are very many out there and you're bound to find at least ONE that has those features (I can name a few straight off) :) // Stefan ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 13:50 ` John Bradford 2003-11-29 14:04 ` Stefan Smietanowski @ 2003-11-29 17:01 ` Sven Luther 2003-11-29 22:14 ` Andries Brouwer 2003-11-29 22:31 ` Andrew Clausen 2 siblings, 1 reply; 49+ messages in thread From: Sven Luther @ 2003-11-29 17:01 UTC (permalink / raw) To: John Bradford Cc: Andries Brouwer, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 01:50:00PM +0000, John Bradford wrote: > > Let me continue to stress: geometry does not exist. > > Consequently, it cannot change. > > fdisk does not set any geometry, it writes a partition table. > > > > Start and size of each partition are given twice: in absolute sector > > units (LBA) and in CHS units. The former uses 32 bits, and with 512-byte > > sectors this works up to 2TB. People are starting to hit that boundary now. > > The latter uses 24 bits, which works up to 8GB. Modern systems no longer > > use it (but the details are complicated). > > Why don't we take the opporunity to make all CHS code configurable out > of the kernel, and define a new, more compact, partition table format > which used LBA exclusively, and allowed more than four partitions in > the main partition table? The only problem is that your BIOS will probably not be able to boot from it, so unless you use some kind of free bios implementation or even some kind of free OF or something such, you will never be able to boot from these drives. For non booting drives, nothing stops you from using alternate partition tables, the Mac OS on as well as the Amiga partition tables seems nice to me (maybe others too, but i mostly know these two of the alternative partition tables) as these are simply linked list of partition entries, you can have as many as you want (limit to 128 partitions for amiga partition in the libparted implementation i made for example). Friendly, Sven Luther ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 17:01 ` Sven Luther @ 2003-11-29 22:14 ` Andries Brouwer 2003-11-29 22:44 ` Sven Luther 2003-11-30 9:35 ` Sergey Vlasov 0 siblings, 2 replies; 49+ messages in thread From: Andries Brouwer @ 2003-11-29 22:14 UTC (permalink / raw) To: Sven Luther Cc: John Bradford, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 06:01:03PM +0100, Sven Luther wrote: > The only problem is that your BIOS will probably not be able > to boot from it You seem to misunderstand the boot sequence. The BIOS does not generally do any parsing of partition tables. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 22:14 ` Andries Brouwer @ 2003-11-29 22:44 ` Sven Luther 2003-11-30 0:39 ` Andries Brouwer 2003-11-30 9:35 ` Sergey Vlasov 1 sibling, 1 reply; 49+ messages in thread From: Sven Luther @ 2003-11-29 22:44 UTC (permalink / raw) To: Andries Brouwer Cc: Sven Luther, John Bradford, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 11:14:24PM +0100, Andries Brouwer wrote: > On Sat, Nov 29, 2003 at 06:01:03PM +0100, Sven Luther wrote: > > > The only problem is that your BIOS will probably not be able > > to boot from it > > You seem to misunderstand the boot sequence. > The BIOS does not generally do any parsing of partition tables. A, ok. I am more familiar with open firmware, which does contain partition table reading code. That said, i really doubt that a standard BIOS can boot from a not MBR containing disk, but i may be wrong. Friendly, Sven Luther ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 22:44 ` Sven Luther @ 2003-11-30 0:39 ` Andries Brouwer 0 siblings, 0 replies; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 0:39 UTC (permalink / raw) To: Sven Luther Cc: John Bradford, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 11:44:11PM +0100, Sven Luther wrote: > That said, i really doubt that a standard BIOS can boot from a not MBR > containing disk, but i may be wrong. The BIOS reads the MBR and jumps to the code loaded from there. There is no need for any partition table, or, if there is a table, for any particular format. It is all up to the code that is found in the MBR. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 22:14 ` Andries Brouwer 2003-11-29 22:44 ` Sven Luther @ 2003-11-30 9:35 ` Sergey Vlasov 1 sibling, 0 replies; 49+ messages in thread From: Sergey Vlasov @ 2003-11-30 9:35 UTC (permalink / raw) To: linux-kernel; +Cc: bug-parted On Sat, 29 Nov 2003 23:14:24 +0100, Andries Brouwer wrote: > On Sat, Nov 29, 2003 at 06:01:03PM +0100, Sven Luther wrote: > >> The only problem is that your BIOS will probably not be able >> to boot from it > > You seem to misunderstand the boot sequence. > The BIOS does not generally do any parsing of partition tables. In theory, the BIOS does not need to look in the partition tables. However, in practice it does this :( Many BIOSes look at least at the partition table in the MBR to autodetect the CHS parameters which were used when partitioning the disk. E.g. if you partition a disk with LBA turned off in the BIOS (so the CHS parameters will have 16 heads), then notice the mistake and turn LBA on, in many cases BIOS will still show 16 heads in the CHS parameters. However, after cleaning the MBR the same BIOS with the same settings will report 255 heads. Who knows what such BIOS will do if it will find something other than a DOS partition table in the first sector... ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 13:50 ` John Bradford 2003-11-29 14:04 ` Stefan Smietanowski 2003-11-29 17:01 ` Sven Luther @ 2003-11-29 22:31 ` Andrew Clausen 2003-11-30 8:57 ` Arjan van de Ven 2 siblings, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-11-29 22:31 UTC (permalink / raw) To: John Bradford Cc: Andries Brouwer, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 01:50:00PM +0000, John Bradford wrote: > Why don't we take the opporunity to make all CHS code configurable out > of the kernel, and define a new, more compact, partition table format > which used LBA exclusively, and allowed more than four partitions in > the main partition table? Intel's EFI GPT partition table format seems quite acceptable. Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 22:31 ` Andrew Clausen @ 2003-11-30 8:57 ` Arjan van de Ven 2003-11-30 7:38 ` Szakacsits Szabolcs ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Arjan van de Ven @ 2003-11-30 8:57 UTC (permalink / raw) To: Andrew Clausen Cc: John Bradford, Andries Brouwer, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted [-- Attachment #1: Type: text/plain, Size: 696 bytes --] On Sat, 2003-11-29 at 23:31, Andrew Clausen wrote: > On Sat, Nov 29, 2003 at 01:50:00PM +0000, John Bradford wrote: > > Why don't we take the opporunity to make all CHS code configurable out > > of the kernel, and define a new, more compact, partition table format > > which used LBA exclusively, and allowed more than four partitions in > > the main partition table? > > Intel's EFI GPT partition table format seems quite acceptable. EFI GPT has some severe downsides (like requiring the last sector on disk, which in linux may not be accessible if the total number of sectors is not a multiple of 2, and making dd of one disk to another impossible if the second one is bigger) [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 8:57 ` Arjan van de Ven @ 2003-11-30 7:38 ` Szakacsits Szabolcs 2003-11-30 10:40 ` John Bradford 2003-11-30 22:54 ` Andrew Clausen 2 siblings, 0 replies; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-11-30 7:38 UTC (permalink / raw) To: Arjan van de Ven Cc: Andrew Clausen, John Bradford, Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, 30 Nov 2003, Arjan van de Ven wrote: > EFI GPT has some severe downsides (like requiring the last sector on > disk, which in linux may not be accessible if the total number of > sectors is not a multiple of 2, and making dd of one disk to another > impossible if the second one is bigger) Isn't this Linux's shortcoming? NT could always access odd last sectors. Actually in the majority of cases it stores the backup of its boot sector in the last sector of the partition for recovery purpose (outside of NTFS). Anton made a fix for this years ago. It's PITA (and wasting time) explaining and working around constantly how Linux can (not) access it. Is it fixed in 2.6? Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 8:57 ` Arjan van de Ven 2003-11-30 7:38 ` Szakacsits Szabolcs @ 2003-11-30 10:40 ` John Bradford 2003-11-30 11:24 ` Sven Luther 2003-11-30 23:51 ` Andrew Clausen 2003-11-30 22:54 ` Andrew Clausen 2 siblings, 2 replies; 49+ messages in thread From: John Bradford @ 2003-11-30 10:40 UTC (permalink / raw) To: Arjan van de Ven, Andrew Clausen Cc: John Bradford, Andries Brouwer, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted Quote from Arjan van de Ven <arjanv@redhat.com>: > On Sat, 2003-11-29 at 23:31, Andrew Clausen wrote: > > On Sat, Nov 29, 2003 at 01:50:00PM +0000, John Bradford wrote: > > > Why don't we take the opporunity to make all CHS code configurable out > > > of the kernel, and define a new, more compact, partition table format > > > which used LBA exclusively, and allowed more than four partitions in > > > the main partition table? > > > > Intel's EFI GPT partition table format seems quite acceptable. > > EFI GPT has some severe downsides (like requiring the last sector on > disk, which in linux may not be accessible if the total number of > sectors is not a multiple of 2, and making dd of one disk to another > impossible if the second one is bigger) EFI GPT is also a far more elaborate scheme than is necessary for a lot of installations. My 'requirements' are: * Good magic We have seen support for not very widely used partitioning schemes broken in the past when other schemes are checked for ahead of them. A simple scheme with well defined magic values reduces this risk. * Simple The code for some of the partitioning schemes is full of workarounds for different implementations. Added complexity, and more variations increase the likelyhood of bugs. * All partition information stored in one partition table Linked lists make re-arranging partitions, and backing up the partition table more difficult. * Support for more than 4 partitions This is a common requirement now. * Support for partitions > 2TB This will become a standard requirement in a few years. * No mention of CHS CHS is so last year. Modern systems don't even need it to boot. We could allow all of the CHS-related code to be configured out of the kernel, which would be useful on some embedded systems. The Ultrix partition code comes fairly close to what I'm thinking of, but not close enough :-). John. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 10:40 ` John Bradford @ 2003-11-30 11:24 ` Sven Luther 2003-11-30 13:48 ` John Bradford 2003-11-30 23:51 ` Andrew Clausen 1 sibling, 1 reply; 49+ messages in thread From: Sven Luther @ 2003-11-30 11:24 UTC (permalink / raw) To: John Bradford Cc: Arjan van de Ven, Andrew Clausen, Apurva Mehta, Andries Brouwer, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 10:40:25AM +0000, John Bradford wrote: > * All partition information stored in one partition table > > Linked lists make re-arranging partitions, and backing up the > partition table more difficult. I don't agree here. You just follow the linked list and make the backup, which is one more reason for having the save/restore mechanism in the per partition table code, which knows how to read/write the partition table anyway. Also, mostly the linked list is found in a chunk of the disk which you can easily backup with dd. The amiga scheme has both information about the number of sectors which can be used in the linked list, as well as the last used sector. Also, with a linked list, you can maintain two or more partition tables on disk, thus making an on-disk backup easy. When you write a new partition table, you write it on other sectors than the first one, and then update the root pointer. You can then later go back to the old partition table by just restoring the root pointer or something such. Also, it allow you flexibility with the amount of partitions you can use, as you could have potentially have any number of partitions you like (upto 2^30 or such). Friendly, Sven Luther ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 11:24 ` Sven Luther @ 2003-11-30 13:48 ` John Bradford 2003-11-30 17:22 ` Sven Luther 0 siblings, 1 reply; 49+ messages in thread From: John Bradford @ 2003-11-30 13:48 UTC (permalink / raw) To: Sven Luther Cc: Arjan van de Ven, Andrew Clausen, Apurva Mehta, Andries Brouwer, Linux Kernel Mailing List, bug-parted Quote from Sven Luther <sven.luther@wanadoo.fr>: > On Sun, Nov 30, 2003 at 10:40:25AM +0000, John Bradford wrote: > > * All partition information stored in one partition table > > > > Linked lists make re-arranging partitions, and backing up the > > partition table more difficult. > > I don't agree here. You just follow the linked list and make the backup, > which is one more reason for having the save/restore mechanism in the > per partition table code, which knows how to read/write the partition > table anyway. Also, mostly the linked list is found in a chunk of the > disk which you can easily backup with dd. The amiga scheme has both > information about the number of sectors which can be used in the linked > list, as well as the last used sector. I must admit, I haven't looked at every single partitioning scheme we support in detail. Also, my method of working may not be typical, in that I don't generally partition all of the space on a disk, just because it's there. This came up on LKML a few months ago, in a discussion about re-sizing filesystems in which I noted that the common case of wanting to shrink a partition containing a filesytem with free space on it, just to allow experimentation with a new filesystem, can be completely avoided in many cases, simply by partitioning only the space you expect to need from the begining. Using the standard x86 partitioning system with large numbers of extended partitions to do all this is not convenient. I think that maybe I notice it more than most users because I generally don't have the hassle of resizing partitions before I do anything anyway. Working with extended partitions might not seem like much extra effort, but it is certainly less convenient and more cumbersome than using primary partitions alone. > Also, with a linked list, you can maintain two or more partition tables > on disk, thus making an on-disk backup easy. When you write a new > partition table, you write it on other sectors than the first one, and > then update the root pointer. You can then later go back to the old > partition table by just restoring the root pointer or something such. I can see that linked-list partition tables have uses, but I think that their disadvantages outweigh their advantages here - if some partitioning data is stored at non-fixed locations on the disk, overwriting a partition can destroy partitioning data for several other partitions, whereas a dedicated area for partition data isn't vulnerable to this. > Also, it allow you flexibility with the amount of partitions you can > use, as you could have potentially have any number of partitions you > like (upto 2^30 or such). Again, I can see that large numbers of partitions might have uses, but in my experience 4 is a real limitation, whereas 8 or 16 wouldn't be. Where, say > 128 partitions are needed, linked-lists are probably a win, but my requirements are for a simple, reliable partitioning scheme which supports large partitions, and allows us to completely remove CHS code from the kernel. I don't think we currently support one. John. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 13:48 ` John Bradford @ 2003-11-30 17:22 ` Sven Luther 0 siblings, 0 replies; 49+ messages in thread From: Sven Luther @ 2003-11-30 17:22 UTC (permalink / raw) To: John Bradford Cc: Sven Luther, Arjan van de Ven, Andrew Clausen, Apurva Mehta, Andries Brouwer, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 01:48:56PM +0000, John Bradford wrote: > Quote from Sven Luther <sven.luther@wanadoo.fr>: > > On Sun, Nov 30, 2003 at 10:40:25AM +0000, John Bradford wrote: > > > * All partition information stored in one partition table > > > > > > Linked lists make re-arranging partitions, and backing up the > > > partition table more difficult. > > > > I don't agree here. You just follow the linked list and make the backup, > > which is one more reason for having the save/restore mechanism in the > > per partition table code, which knows how to read/write the partition > > table anyway. Also, mostly the linked list is found in a chunk of the > > disk which you can easily backup with dd. The amiga scheme has both > > information about the number of sectors which can be used in the linked > > list, as well as the last used sector. > > I must admit, I haven't looked at every single partitioning scheme we > support in detail. > > Also, my method of working may not be typical, in that I don't > generally partition all of the space on a disk, just because it's > there. This came up on LKML a few months ago, in a discussion about > re-sizing filesystems in which I noted that the common case of wanting > to shrink a partition containing a filesytem with free space on it, > just to allow experimentation with a new filesystem, can be completely > avoided in many cases, simply by partitioning only the space you > expect to need from the begining. Sure, but you don't always know about this at the begining. > > Also, with a linked list, you can maintain two or more partition tables > > on disk, thus making an on-disk backup easy. When you write a new > > partition table, you write it on other sectors than the first one, and > > then update the root pointer. You can then later go back to the old > > partition table by just restoring the root pointer or something such. > > I can see that linked-list partition tables have uses, but I think > that their disadvantages outweigh their advantages here - if some > partitioning data is stored at non-fixed locations on the disk, > overwriting a partition can destroy partitioning data for several > other partitions, whereas a dedicated area for partition data isn't > vulnerable to this. Well, i don't know about macos, or other linked partition tables, but in the amiga case, you just use a chunk of the disk at the begining to store the partition entries in (each partition correspond to a 512 byte sector). The RDB (the root of the partition tree) contains information about what sector are allocated to the partition table, and what can be used for other stuff. In the libparted case, i just made the partition table not available to put partitions in it, and there can not be possible overwriting, either by parted or by kernel access, since both respect the reserved space. Furthermore the RDB can be found in any of the 16 first sectors of the disk, and i put it in sector 2 by default, so as to not loose it when someone stupidly writes an MBR on top of it (like i did when playing with beta debian-installer and evil autopartkit and a messed up console). Historicaly there were also other stuff stored in the linked list on amigaos, like a badblock list, as well as filesystem drivers. > > Also, it allow you flexibility with the amount of partitions you can > > use, as you could have potentially have any number of partitions you > > like (upto 2^30 or such). > > Again, I can see that large numbers of partitions might have uses, but > in my experience 4 is a real limitation, whereas 8 or 16 wouldn't be. I routinely have more than 8 partitions in any case. With the large disks we have today, i guess it would be quite easy to have more than 16 of them too, altough i don't remember having them (i had an hda15 though). > Where, say > 128 partitions are needed, linked-lists are probably a > win, but my requirements are for a simple, reliable partitioning > scheme which supports large partitions, and allows us to completely > remove CHS code from the kernel. I don't think we currently support > one. What has linked lists to do with CHS ? These are fully orthogonal issues. And consider the simplest of linked list, the one were the next block is the block immediately after the current one. You would have a root block with details about the disk, information about the area reserved and such, and then a simple 0xffffffff (or whatever) terminated array or something. You could even keep the linked list scheme for flexibility, but make it linear. Ideally, you would have two lists (or more) for backup, and the root block would contain the extent of sectors reserved for this usage (128Ko on larger disks maybe ?) as well as the highest used block of this, so you can easily back it up with dd or something. Alternatively you could have replications of this table at regular intervals of the disks or something. Friendly, Sven Luther ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 10:40 ` John Bradford 2003-11-30 11:24 ` Sven Luther @ 2003-11-30 23:51 ` Andrew Clausen 1 sibling, 0 replies; 49+ messages in thread From: Andrew Clausen @ 2003-11-30 23:51 UTC (permalink / raw) To: John Bradford Cc: Arjan van de Ven, Andries Brouwer, Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 10:40:25AM +0000, John Bradford wrote: > > EFI GPT has some severe downsides (like requiring the last sector on > > disk, which in linux may not be accessible if the total number of > > sectors is not a multiple of 2, and making dd of one disk to another > > impossible if the second one is bigger) > > EFI GPT is also a far more elaborate scheme than is necessary for a > lot of installations. Is this a problem? > My 'requirements' are: > > * Good magic > > We have seen support for not very widely used partitioning schemes > broken in the past when other schemes are checked for ahead of them. > A simple scheme with well defined magic values reduces this risk. I think magic doesn't belong in partition tables. I like probing. Having the same data stored in two places makes things hairy if you don't know how to resolve inconsistencies. > * Simple > > The code for some of the partitioning schemes is full of workarounds > for different implementations. Added complexity, and more variations > increase the likelyhood of bugs. If you're not interested in work-arounds, why not use LVM? > * All partition information stored in one partition table > > Linked lists make re-arranging partitions, and backing up the > partition table more difficult. I don't think it's very difficult, but I agree that tables are nice and simple. Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 8:57 ` Arjan van de Ven 2003-11-30 7:38 ` Szakacsits Szabolcs 2003-11-30 10:40 ` John Bradford @ 2003-11-30 22:54 ` Andrew Clausen 2 siblings, 0 replies; 49+ messages in thread From: Andrew Clausen @ 2003-11-30 22:54 UTC (permalink / raw) To: Arjan van de Ven Cc: Apurva Mehta, Andries Brouwer, John Bradford, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 09:57:56AM +0100, Arjan van de Ven wrote: > > Intel's EFI GPT partition table format seems quite acceptable. > > EFI GPT has some severe downsides (like requiring the last sector on > disk, which in linux may not be accessible if the total number of > sectors is not a multiple of 2, Yeah, this does suck. That ioctl hack isn't pretty. > and making dd of one disk to another impossible if the second one is > bigger) You just lose some of the fault tolerance, until you rerun a partition tool (or even boot a kernel) that re-does the end of it, adjusting for the new disk size. The whole point of having an extra copy of the table is to be fault tolerant, not to introduce another point of failure! Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 12:34 ` Andries Brouwer 2003-11-29 13:50 ` John Bradford @ 2003-11-29 22:27 ` Andrew Clausen 2003-11-30 0:34 ` Andries Brouwer 1 sibling, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-11-29 22:27 UTC (permalink / raw) To: Andries Brouwer Cc: Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 01:34:51PM +0100, Andries Brouwer wrote: > On Sat, Nov 29, 2003 at 07:16:31AM +0200, Szakacsits Szabolcs wrote: > > > http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot > > > > Some users, having problems, did mention the usage of 2.6 kernel. If the > > geometry changed during the fdisk, etc process then it could result also > > booting problem? > > Let me continue to stress: geometry does not exist. Let me continue to stress: geometry DOES exist. It is an abstract construct that is stored in your BIOS that some configurations use and need for booting. > Consequently, it cannot change. The geometry can be changed in many BIOSes. > fdisk does not set any geometry, it writes a partition table. But the way it writes the partition table is affected by what it believes the geometry to be. If its beliefs don't match the BIOS, there can be trouble. However, since fdisk isn't typically used to resize Windows partitions, you don't see problems so much. > Start and size of each partition are given twice: in absolute sector > units (LBA) and in CHS units. The former uses 32 bits, and with 512-byte > sectors this works up to 2TB. People are starting to hit that boundary now. > The latter uses 24 bits, which works up to 8GB. Modern systems no longer > use it (but the details are complicated). You mean "modern software". I'm not sure how true this is. Have you got any evidence? (i.e. have you got any evidence that, say, that 99.x% of Windows XP installations use LBA to bootstrap?) > Usually booting goes like this: the BIOS reads sector 0 (the MBR) > from the first disk, and starts the code found there. What happens > afterwards is up to that code. If that code uses CHS units to find > a partition, and if the program that wrote the table has different > ideas about those units than the BIOS, booting may fail. Exactly. Moreover, booting can fail while reading the file system. I reverse engineered several of the Microsoft boot loaders (Windows 95/9x/ME/2000/NT). The boot sector understands FAT, and depending on the configuration, may use CHS to load in info. I wrote about this in the doc/FAT file in the Parted tarball. Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 22:27 ` Andrew Clausen @ 2003-11-30 0:34 ` Andries Brouwer 2003-11-30 11:10 ` Szakacsits Szabolcs 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 0:34 UTC (permalink / raw) To: Andrew Clausen Cc: Szakacsits Szabolcs, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 09:27:22AM +1100, Andrew Clausen wrote: > > > Some users, having problems, did mention the usage of 2.6 kernel. If the > > > geometry changed during the fdisk, etc process then it could result also > > > booting problem? > > > > Let me continue to stress: geometry does not exist. > > Consequently, it cannot change. > > Let me continue to stress: geometry DOES exist. Ha, Andrew - you know these things, I know these things - please do not confuse matters. My first letter had as essential content: the Linux 2.6 kernel does not make geometry information available to user space. Thus, if user space asks the kernel and prints an error message in case the answer is unexpected, then such user space is broken under 2.6. There is nothing to gain from asking the kernel. That was a letter for you - parted should be fixed, otherwise there will be a long sequence of users that worry that things might be wrong. My second letter was for Szaka and affirmed that fdisk cannot change this non-existent geometry. You still believe in fairies, I mean, in disk geometry, that is OK, I don't mind, but still, whatever it is you believe in, fdisk cannot change it. > It is an abstract construct that is stored in your BIOS that some > configurations use and need for booting. I am happy with that description. "Disk geometry is: some numbers that your BIOS invents". Of course, details are always more complicated. What the BIOS invents may be dependent on user settings in its setup. There are also numbers that certain operating systems or boot managers invent. Equal to or different from what your BIOS has thought of. > (i.e. have you got any evidence that, say, that 99.x% of Windows XP > installations use LBA to bootstrap?) Just ask yourself this question: does Windows XP require a bootable partition to start below the 1024 cylinder mark? Windows NT4 has such a restriction. Not Windows 2000 or XP. > > Usually booting goes like this: the BIOS reads sector 0 (the MBR) > > from the first disk, and starts the code found there. What happens > > afterwards is up to that code. If that code uses CHS units to find > > a partition, and if the program that wrote the table has different > > ideas about those units than the BIOS, booting may fail. > > Exactly. Good. We agree. Andries ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 0:34 ` Andries Brouwer @ 2003-11-30 11:10 ` Szakacsits Szabolcs 2003-11-30 13:26 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-11-30 11:10 UTC (permalink / raw) To: Andries Brouwer Cc: Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, 30 Nov 2003, Andries Brouwer wrote: > Just ask yourself this question: does Windows XP require a bootable > partition to start below the 1024 cylinder mark? > Windows NT4 has such a restriction. Not Windows 2000 or XP. Wrong: http://support.microsoft.com/default.aspx?scid=kb;en-us;282191 > > > Usually booting goes like this: the BIOS reads sector 0 (the MBR) > > > from the first disk, and starts the code found there. What happens > > > afterwards is up to that code. If that code uses CHS units to find > > > a partition, and if the program that wrote the table has different > > > ideas about those units than the BIOS, booting may fail. > > Exactly. > Good. We agree. I'm glad also. So what actually [cs]fdisk do with the CHS entries in the partition table? Ignore them? Might they convert a given partition start to different CHS units if the partition entry was deleted then recreated at the same cylinder? AFAIS, parted tries hard not to break these [IMHO correctly], right Andrew? Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 11:10 ` Szakacsits Szabolcs @ 2003-11-30 13:26 ` Andries Brouwer 2003-11-30 12:34 ` Szakacsits Szabolcs 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 13:26 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 01:10:36PM +0200, Szakacsits Szabolcs wrote: > > On Sun, 30 Nov 2003, Andries Brouwer wrote: > > > Just ask yourself this question: does Windows XP require a bootable > > partition to start below the 1024 cylinder mark? > > Windows NT4 has such a restriction. Not Windows 2000 or XP. > > Wrong: > http://support.microsoft.com/default.aspx?scid=kb;en-us;282191 "Wrong" - what a pessimism. That URL just confirms what I wrote: Windows XP has no such restriction. If you explicitly ask Windows XP to use oldfashioned means, then of course that is your own choice. > > > > Usually booting goes like this: the BIOS reads sector 0 (the MBR) > > > > from the first disk, and starts the code found there. What happens > > > > afterwards is up to that code. If that code uses CHS units to find > > > > a partition, and if the program that wrote the table has different > > > > ideas about those units than the BIOS, booting may fail. > > > Exactly. > > Good. We agree. > > I'm glad also. So what actually [cs]fdisk do with the CHS entries in the > partition table? Ignore them? Might they convert a given partition start to > different CHS units if the partition entry was deleted then recreated at > the same cylinder? Ha, now we are getting down to business. *fdisk evolves in time, so the answer is very version dependent. Let me answer for today's fdisk. Disk geometry is determined as follows (see fdisk.c:get_geometry()) heads = user_heads ? user_heads : pt_heads ? pt_heads : kern_heads ? kern_heads : 255; sectors = user_sectors ? user_sectors : pt_sectors ? pt_sectors : kern_sectors ? kern_sectors : 63; that is, if the user has specified a geometry on the command line, then that is what we use; otherwise, if there is a partition table already and we are able to guess a geometry from that, use that; otherwise, if the kernel has some idea, use that; finally use */255/63 when no information is available. Andries ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 13:26 ` Andries Brouwer @ 2003-11-30 12:34 ` Szakacsits Szabolcs 2003-11-30 15:46 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-11-30 12:34 UTC (permalink / raw) To: Andries Brouwer Cc: Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, 30 Nov 2003, Andries Brouwer wrote: > > > > Wrong: > > http://support.microsoft.com/default.aspx?scid=kb;en-us;282191 > > "Wrong" - what a pessimism. Optimism ends up unbootable systems. > Windows XP has no such restriction. If you explicitly ask Windows XP > to use oldfashioned means, then of course that is your own choice. It's not like that. People get boxes whatever way they were imaged, etc. Most don't know anything about the internals. And when they want to make it dualboot with Linux, they might find they can't boot anymore. Do you also really believe this oldfashioned means is the only way to end up in problems because of partitioning tools change CHS units? > if there is a partition table already and we are able to guess a geometry > from that, use that; otherwise [...] OK, thanks, the problem is here. Maybe a warning could be added when the geometry can't be guessed (if the warning isn't there already)? Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 12:34 ` Szakacsits Szabolcs @ 2003-11-30 15:46 ` Andries Brouwer 0 siblings, 0 replies; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 15:46 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andrew Clausen, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 02:34:23PM +0200, Szakacsits Szabolcs wrote: > > if there is a partition table already and we are able to guess a geometry > > from that, use that; otherwise [...] > > OK, thanks, the problem is here. Maybe a warning could be added The docs and the programs are full of warnings already. Too many in fact. People worry and get nervous, needlessly. In a very small percentage of cases there really are problems, but again these warnings "there might be problems" are not very helpful. The number of cylinders for this disk is set to 70780. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Does this help anybody? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 5:16 ` Szakacsits Szabolcs 2003-11-29 9:18 ` Sven Luther 2003-11-29 12:34 ` Andries Brouwer @ 2003-11-29 22:33 ` Andrew Clausen 2003-11-30 9:16 ` Szakacsits Szabolcs 2 siblings, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-11-29 22:33 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sat, Nov 29, 2003 at 07:16:31AM +0200, Szakacsits Szabolcs wrote: > > Yes there is. "Correct" is defined by the BIOS. It is important > > for boot loaders (in particular Windows). > > I suspected the same ... What Windows you mean? DOS (9x/ME/etc) or NT based > (NT4/2000/XP/2003)? All? Good question. From 98 up, Windows supports both LBA and CHS. I'm not sure about XP/2003. The real question is: what is the default install? How many users have each? > Also, can Parted save/restore the full and exact partition table a > scriptable way? I mean something like this: > > sfdisk -d /dev/hda > hda.pt # save > sfdisk /dev/hda < hda.pt # restore > > sfdisk can't recover geometry so apparently no one-liner, widely available, > partition table backup/recovery is possible at present on Linux :-o > dd if=/dev/hda of=hda.mbr bs=512 count=1 won't save the logical partitions. Parted can't do it. :/ Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-29 22:33 ` Andrew Clausen @ 2003-11-30 9:16 ` Szakacsits Szabolcs 2003-12-03 11:05 ` Andrew Clausen 0 siblings, 1 reply; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-11-30 9:16 UTC (permalink / raw) To: Andrew Clausen Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, 30 Nov 2003, Andrew Clausen wrote: > > Good question. From 98 up, Windows supports both LBA and CHS. I'm not > sure about XP/2003. I don't think it changed. CHS support is needed for backward compatibility during boot. This is why it would be important not to screw it, if it's indeed matter in the partition table. Some reading how NT gets/uses drive geometry, http://support.microsoft.com/?kbid=98080 > The real question is: what is the default install? How many users have > each? Google Zeitgeist says for september at http://www.google.com/press/zeitgeist/sep03_pie.gif XP 38% 98 29% 2000 20% NT 3% 95 1% XP is growing 1-2% each month at the expense of Win9x (see http://www.google.com/press/zeitgeist//{...,jun,jul,aug}03_pie.gif) The majority of NT based uses NTFS. NTFS has its own $Boot file fixed at sector 0, that is it's the boot sector. I don't know how much it's different from the one booting from FAT but I guess not much (except of understanding NTFS instead of FAT during boot, etc). Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 9:16 ` Szakacsits Szabolcs @ 2003-12-03 11:05 ` Andrew Clausen 2003-12-03 11:28 ` Szakacsits Szabolcs 0 siblings, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-12-03 11:05 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Sun, Nov 30, 2003 at 11:16:31AM +0200, Szakacsits Szabolcs wrote: > > The real question is: what is the default install? How many users have > > each? > > Google Zeitgeist says for september at > http://www.google.com/press/zeitgeist/sep03_pie.gif > > XP 38% > 98 29% > 2000 20% > NT 3% > 95 1% Sorry. This wasn't my question - I should have been more specific. The real question is: "what is the default install option - LBA or CHS - on modern(ish) Windows systems?" What proportion of XP users boot via CHS? Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 11:05 ` Andrew Clausen @ 2003-12-03 11:28 ` Szakacsits Szabolcs 2003-12-03 11:54 ` Andrew Clausen 0 siblings, 1 reply; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-12-03 11:28 UTC (permalink / raw) To: Andrew Clausen Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Wed, 3 Dec 2003, Andrew Clausen wrote: > The real question is: "what is the default install option - LBA or CHS > - on modern(ish) Windows systems?" Autodetect unless it's explicitely set. > What proportion of XP users boot via CHS? Depends on BIOS, boot manager, configuration, etc. Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 11:28 ` Szakacsits Szabolcs @ 2003-12-03 11:54 ` Andrew Clausen 2003-12-03 13:07 ` Szakacsits Szabolcs 0 siblings, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-12-03 11:54 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Wed, Dec 03, 2003 at 12:28:20PM +0100, Szakacsits Szabolcs wrote: > > The real question is: "what is the default install option - LBA or CHS > > - on modern(ish) Windows systems?" > > Autodetect unless it's explicitely set. Can you elaborate? Autodetect what? Autodetect if the BIOS supports LBA? (BTW, "LBA mode" is purely setting CHS = x/255/63, right? It's not like anything is getting enabled/disabled?) > > What proportion of XP users boot via CHS? > > Depends on BIOS, boot manager, configuration, etc. Sure. But can we estimate anyway? Do a "random" survey? * does more than 1% of the Windows market use a boot manager other than Windows'/lilo/grub? (Guess: No) * what proportion of Windows users do any configuration themselves? What about the OEM installers? (Aren't these a high proportion?) (Guess: 90% OEM; 1% of users do boot config) * do OEM installers generally use LBA? (Guess: no idea) Maybe the students/academics here should poke around their university campuses. I'm not sure how we could unobtrusively check! Some BIOS POST screens show useful info. Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 11:54 ` Andrew Clausen @ 2003-12-03 13:07 ` Szakacsits Szabolcs 2003-12-03 23:27 ` Andrew Clausen 0 siblings, 1 reply; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-12-03 13:07 UTC (permalink / raw) To: Andrew Clausen Cc: Andries Brouwer, Apurva Mehta, Linux Kernel Mailing List, bug-parted On Wed, 3 Dec 2003, Andrew Clausen wrote: > > Can you elaborate? Autodetect what? Autodetect if the BIOS supports LBA? Autodetect to boot from the boot controller's miniport driver or using BIOS. It should have been mentioned in one of the Microsoft articles I referred. Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 13:07 ` Szakacsits Szabolcs @ 2003-12-03 23:27 ` Andrew Clausen 2003-12-03 21:55 ` Szakacsits Szabolcs 2003-12-03 23:47 ` bill davidsen 0 siblings, 2 replies; 49+ messages in thread From: Andrew Clausen @ 2003-12-03 23:27 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Apurva Mehta, Andries Brouwer, Linux Kernel Mailing List, bug-parted On Wed, Dec 03, 2003 at 02:07:06PM +0100, Szakacsits Szabolcs wrote: > > Can you elaborate? Autodetect what? Autodetect if the BIOS supports LBA? > > Autodetect to boot from the boot controller's miniport driver or using > BIOS. It should have been mentioned in one of the Microsoft articles I > referred. I'm totally confused. What's a miniport driver? What is a boot controller? Do these have anything to do with LBA? Also, you say "autodetect"... you mean it is making a decision to use some method (not that I understand this). How does it make the decision? The article doesn't mention "Linear", "LBA", "boot controller" or "miniport driver" at all. (I was looking at http://support.microsoft.com/?kbid=98080 - is this the right one?) The question I believe I asked was: how does the Windows installation software decide whether to use LBA or CHS? Is this an answer to this question? Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 23:27 ` Andrew Clausen @ 2003-12-03 21:55 ` Szakacsits Szabolcs 2003-12-03 23:47 ` bill davidsen 1 sibling, 0 replies; 49+ messages in thread From: Szakacsits Szabolcs @ 2003-12-03 21:55 UTC (permalink / raw) To: Andrew Clausen Cc: Apurva Mehta, Andries Brouwer, Linux Kernel Mailing List, bug-parted On Thu, 4 Dec 2003, Andrew Clausen wrote: > The article doesn't mention "Linear", "LBA", "boot controller" or > "miniport driver" at all. (I was looking at > http://support.microsoft.com/?kbid=98080 - is this the right one?) No, the other one. Perhaps you didn't get it because you also didn't answer my question. But isn't this off-topic on the kernel list? Szaka ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 23:27 ` Andrew Clausen 2003-12-03 21:55 ` Szakacsits Szabolcs @ 2003-12-03 23:47 ` bill davidsen 1 sibling, 0 replies; 49+ messages in thread From: bill davidsen @ 2003-12-03 23:47 UTC (permalink / raw) To: linux-kernel In article <20031203232726.GC466@gnu.org>, Andrew Clausen <clausen@gnu.org> wrote: | On Wed, Dec 03, 2003 at 02:07:06PM +0100, Szakacsits Szabolcs wrote: | > > Can you elaborate? Autodetect what? Autodetect if the BIOS supports LBA? | > | > Autodetect to boot from the boot controller's miniport driver or using | > BIOS. It should have been mentioned in one of the Microsoft articles I | > referred. | | I'm totally confused. | | What's a miniport driver? What is a boot controller? Do these have | anything to do with LBA? | | Also, you say "autodetect"... you mean it is making a decision to use | some method (not that I understand this). How does it make the decision? | | The article doesn't mention "Linear", "LBA", "boot controller" or | "miniport driver" at all. (I was looking at | http://support.microsoft.com/?kbid=98080 - is this the right one?) | | | The question I believe I asked was: how does the Windows installation | software decide whether to use LBA or CHS? Is this an answer to | this question? Some (most?) BIOS implementations let you set this as an option, something like STANDARD, LARGE and LBA choices. Most today set LBA unless you force it. I would expect the Windows installer to use what the BIOS provides, but I'm happy to say I haven't done a winstall in several years. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 49+ messages in thread
[parent not found: <200311300220.hAU2K0dr019280@sunrise.pg.gda.pl>]
* Re: Disk Geometries reported incorrectly on 2.6.0-testX [not found] <200311300220.hAU2K0dr019280@sunrise.pg.gda.pl> @ 2003-11-30 2:22 ` Andrzej Krzysztofowicz 2003-11-30 13:13 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Andrzej Krzysztofowicz @ 2003-11-30 2:22 UTC (permalink / raw) To: kernel list; +Cc: aebr > The BIOS reads the MBR and jumps to the code loaded from there. > There is no need for any partition table, or, if there is a table, > for any particular format. It is all up to the code that is found > in the MBR. I found some PC BIOS-es refuse to read the MBR if no active partition is found in the partition table... -- ======================================================================= Andrzej M. Krzysztofowicz ankry@mif.pg.gda.pl phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Gdansk University of Technology ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 2:22 ` Andrzej Krzysztofowicz @ 2003-11-30 13:13 ` Andries Brouwer 2003-11-30 13:58 ` John Bradford 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 13:13 UTC (permalink / raw) To: Andrzej Krzysztofowicz; +Cc: kernel list On Sun, Nov 30, 2003 at 03:22:52AM +0100, Andrzej Krzysztofowicz wrote: > > The BIOS reads the MBR and jumps to the code loaded from there. > > There is no need for any partition table, or, if there is a table, > > for any particular format. It is all up to the code that is found > > in the MBR. > > I found some PC BIOS-es refuse to read the MBR if no active partition is > found in the partition table... Yes. We are getting a bit away from disk geometries, but it is true that there are many broken BIOSes that in some way depend on partition table format or MBR format. I recall the report that one BIOS tuned IDE modes by reading the MBR and seeing whether it ended with 0xaa55. If not it tried a lower speed. So on a disk without this MBR signature, the I/O would be slow. BSD used to use an entirely different partition table scheme. And it was not uncommon to run a whole-disk BSD system, without any partitioning. Increasingly often that caused problems with broken BIOSes that wanted to interpret partition table contents. The categories of problems that come to mind are: - BIOS has a virus detection option and checks the MBR - BIOS inspects the partition table to find the hibernation partition - BIOS inspects the partition table to find the service partition - BIOS inspects the partition table to guess what geometry it should report I recall that certain Thinkpads would not boot FreeBSD even with a DOS-type partition table because the BIOS did not like the a5 partition ID. So, yes, you are right, practice is much more complicated than theory. Andries ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 13:13 ` Andries Brouwer @ 2003-11-30 13:58 ` John Bradford 0 siblings, 0 replies; 49+ messages in thread From: John Bradford @ 2003-11-30 13:58 UTC (permalink / raw) To: Andries Brouwer, Andrzej Krzysztofowicz; +Cc: kernel list Quote from Andries Brouwer <aebr@win.tue.nl>: > On Sun, Nov 30, 2003 at 03:22:52AM +0100, Andrzej Krzysztofowicz wrote: > > > > The BIOS reads the MBR and jumps to the code loaded from there. > > > There is no need for any partition table, or, if there is a table, > > > for any particular format. It is all up to the code that is found > > > in the MBR. > > > > I found some PC BIOS-es refuse to read the MBR if no active partition is > > found in the partition table... > > Yes. We are getting a bit away from disk geometries, but it is true > that there are many broken BIOSes that in some way depend on partition > table format or MBR format. OK, there is broken hardware, but there are also people with non-broken hardware who want to make better use of it :-). I am not recommending that everybody moves away from the standard partition table format, I just want a better partitioning scheme for new machines I build, (for which I would avoid using known broken hardware). > I recall the report that one BIOS tuned IDE modes by reading the MBR > and seeing whether it ended with 0xaa55. If not it tried a lower speed. > So on a disk without this MBR signature, the I/O would be slow. > > BSD used to use an entirely different partition table scheme. > And it was not uncommon to run a whole-disk BSD system, without > any partitioning. Hmmm, yes, you can use a BSD disk label on a whole disk, as opposed to putting a BSD disk label on one partition of a disk. I have never tried to read such a disk on a Linux machine, though - do we support that correctly? > Increasingly often that caused problems with broken BIOSes > that wanted to interpret partition table contents. > > The categories of problems that come to mind are: > - BIOS has a virus detection option and checks the MBR > - BIOS inspects the partition table to find the hibernation partition > - BIOS inspects the partition table to find the service partition > - BIOS inspects the partition table to guess what geometry it should report > > I recall that certain Thinkpads would not boot FreeBSD even with a DOS-type > partition table because the BIOS did not like the a5 partition ID. > > So, yes, you are right, practice is much more complicated than theory. For building new, dedicated Linux machines, though, how much of that do we have to concern ourselves with? John. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX
@ 2003-11-30 7:08 Norman Diamond
0 siblings, 0 replies; 49+ messages in thread
From: Norman Diamond @ 2003-11-30 7:08 UTC (permalink / raw)
To: Andrzej Krzysztofowicz, linux-kernel
Andrzej Krzysztofowicz replied to someone:
> > The BIOS reads the MBR and jumps to the code loaded from there.
>
> I found some PC BIOS-es refuse to read the MBR if no active partition is
> found in the partition table...
They read the MBR but refuse the execute the code contained in it. Reading
the MBR is the only way that they get to find out that the partition table
includes zero or two (or more) active partitions and decide not to boot.
SuSE 8.1 had this problem. If you installed grub to a /boot partition but
intended to continue using your existing active partition, the installer
activated the /boot partition. On the next boot, the BIOS detected two
active partitions and refused to boot from the hard disk.
Booting a floppy still works on most machines. The BIOS still reads the MBR
and presents the partition table in a block of information that is visible
to the program that gets booted from the floppy disk. In my experience, the
only machines that refused to do this (becoming 100% unbootable) were the
old NEC 98 architecture.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX @ 2003-11-30 7:08 Norman Diamond 2003-11-30 12:49 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Norman Diamond @ 2003-11-30 7:08 UTC (permalink / raw) To: Andries Brouwer, Andrew Clausen, linux-kernel Andries Brouwer replied to Andrew Clausen: > I am happy with that description. > "Disk geometry is: some numbers that your BIOS invents". I'm happy with that too. Now, since the Linux kernel has no fantasies about disk geometry, it is fine to refuse to provide such non-existent fantasies to user space. However, it remains necessary to provide the BIOS's fantasies to user space. Sometimes user space does something (via the kernel) that will later be interpreted by the BIOS. User space has to be able to do it in the manner that the BIOS wants. > > (i.e. have you got any evidence that, say, that 99.x% of Windows XP > > installations use LBA to bootstrap?) > > Just ask yourself this question: does Windows XP require a bootable > partition to start below the 1024 cylinder mark? > Windows NT4 has such a restriction. Not Windows 2000 or XP. The answer is still yes. Not on sufficiently modern BIOSes but yes in the way that the booter uses the BIOS to load the kernel. I think that a computer dating from 1998 is not terribly old to expect Linux to run, especially when Linux does run and Windows XP does run. I have to keep the following partitions under the 8 GB mark: C: (NTLDR, NTDETECT.COM, BOOT.INI, BOOTSECT.LNX, etc.) D: (WINNT\whatever the names are for kernel, drivers, etc.) /boot (grub files and vmlinuz-whatever versions) Windows NT4 SP4 partly overcame the 8GB mark, but of course SP4 was so badly broken that it is fortunate that the relevant ATAPI.SYS file is downloadable separately. This ATAPI.SYS (when renamed to C:\NTBOOTDD.SYS) can load a kernel for NT4, 2000, or XP even past the 8GB mark, but this file itself and NTLDR and BOOT.INI etc. must remain below the 8GB mark. To do this you have to keep all of C: below the 8GB mark. If you install Windows 2000 or XP on such a machine then you have to take a separate download of this specific version of ATAPI.SYS again, and you have to manually hack BOOT.INI partway through the installation sequence. If you don't do things right then Windows 2000 or XP becomes unbootable, sometimes during the installation process (if lucky), sometimes years after the install (when a file needed during booting gets updated and moved). Anyway, regardless of which OS you're running, the OS isn't running until it's running. The MBR depends on BIOS functions (e.g. the infamous INT13) to read in the boot loader and the boot loader depends on BIOS functions to read in the kernel. Yes Dr. Brouwer, I know you know this. The question is why you think that commands such as parted don't have to know this? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 7:08 Norman Diamond @ 2003-11-30 12:49 ` Andries Brouwer 2003-12-03 11:06 ` Andrew Clausen 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-11-30 12:49 UTC (permalink / raw) To: Norman Diamond; +Cc: Andrew Clausen, linux-kernel On Sun, Nov 30, 2003 at 04:08:22PM +0900, Norman Diamond wrote: > Andries Brouwer replied to Andrew Clausen: > > > I am happy with that description. > > "Disk geometry is: some numbers that your BIOS invents". > > I'm happy with that too. Now, since the Linux kernel has no fantasies about > disk geometry, it is fine to refuse to provide such non-existent fantasies > to user space. However, it remains necessary to provide the BIOS's > fantasies to user space. Sometimes user space does something (via the > kernel) that will later be interpreted by the BIOS. User space has to be > able to do it in the manner that the BIOS wants. The point is just that the Linux kernel has no idea about these BIOS fantasies. It may have a more or less elaborate system of guesses, but it has no knowledge. In practice things work better if the kernel never tries to tell anything to user space, and user space derives the desired BIOS fantasies from the partition table. > Anyway, regardless of which OS you're running, the OS isn't running until > it's running. The MBR depends on BIOS functions (e.g. the infamous INT13) > to read in the boot loader and the boot loader depends on BIOS functions to > read in the kernel. Yes Dr. Brouwer, I know you know this. The question is > why you think that commands such as parted don't have to know this? You invent a title for me that I never used. You invent an opinion for me that I never had. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-11-30 12:49 ` Andries Brouwer @ 2003-12-03 11:06 ` Andrew Clausen 2003-12-03 14:42 ` Andries Brouwer 0 siblings, 1 reply; 49+ messages in thread From: Andrew Clausen @ 2003-12-03 11:06 UTC (permalink / raw) To: Andries Brouwer; +Cc: Norman Diamond, linux-kernel On Sun, Nov 30, 2003 at 01:49:16PM +0100, Andries Brouwer wrote: > The point is just that the Linux kernel has no idea about these BIOS > fantasies. Can't you look inside BIOS memory, etc.? Even call interrupts to query this stuff? Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 11:06 ` Andrew Clausen @ 2003-12-03 14:42 ` Andries Brouwer 2003-12-03 23:11 ` Andrew Clausen 0 siblings, 1 reply; 49+ messages in thread From: Andries Brouwer @ 2003-12-03 14:42 UTC (permalink / raw) To: Andrew Clausen; +Cc: Norman Diamond, linux-kernel On Wed, Dec 03, 2003 at 10:06:06PM +1100, Andrew Clausen wrote: > > The point is just that the Linux kernel has no idea about these BIOS > > fantasies. > > Can't you look inside BIOS memory, etc.? > Even call interrupts to query this stuff? Of course. And the details differ from BIOS to BIOS. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Disk Geometries reported incorrectly on 2.6.0-testX 2003-12-03 14:42 ` Andries Brouwer @ 2003-12-03 23:11 ` Andrew Clausen 0 siblings, 0 replies; 49+ messages in thread From: Andrew Clausen @ 2003-12-03 23:11 UTC (permalink / raw) To: Andries Brouwer; +Cc: Norman Diamond, linux-kernel On Wed, Dec 03, 2003 at 03:42:54PM +0100, Andries Brouwer wrote: > > > The point is just that the Linux kernel has no idea about these BIOS > > > fantasies. > > > > Can't you look inside BIOS memory, etc.? > > Even call interrupts to query this stuff? > > Of course. And the details differ from BIOS to BIOS. I know. But can't you figure it out for the 5 most popular BIOSes, or whatever? Seems like a job for the kernel. Cheers, Andrew ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2003-12-03 23:58 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-28 4:58 Disk Geometries reported incorrectly on 2.6.0-testX Apurva Mehta 2003-11-28 14:24 ` Andries Brouwer 2003-11-29 2:22 ` Andrew Clausen 2003-11-29 5:16 ` Szakacsits Szabolcs 2003-11-29 9:18 ` Sven Luther 2003-11-29 12:41 ` Andries Brouwer 2003-11-30 11:44 ` Szakacsits Szabolcs 2003-11-30 15:19 ` Andries Brouwer 2003-11-29 12:34 ` Andries Brouwer 2003-11-29 13:50 ` John Bradford 2003-11-29 14:04 ` Stefan Smietanowski 2003-11-29 17:01 ` Sven Luther 2003-11-29 22:14 ` Andries Brouwer 2003-11-29 22:44 ` Sven Luther 2003-11-30 0:39 ` Andries Brouwer 2003-11-30 9:35 ` Sergey Vlasov 2003-11-29 22:31 ` Andrew Clausen 2003-11-30 8:57 ` Arjan van de Ven 2003-11-30 7:38 ` Szakacsits Szabolcs 2003-11-30 10:40 ` John Bradford 2003-11-30 11:24 ` Sven Luther 2003-11-30 13:48 ` John Bradford 2003-11-30 17:22 ` Sven Luther 2003-11-30 23:51 ` Andrew Clausen 2003-11-30 22:54 ` Andrew Clausen 2003-11-29 22:27 ` Andrew Clausen 2003-11-30 0:34 ` Andries Brouwer 2003-11-30 11:10 ` Szakacsits Szabolcs 2003-11-30 13:26 ` Andries Brouwer 2003-11-30 12:34 ` Szakacsits Szabolcs 2003-11-30 15:46 ` Andries Brouwer 2003-11-29 22:33 ` Andrew Clausen 2003-11-30 9:16 ` Szakacsits Szabolcs 2003-12-03 11:05 ` Andrew Clausen 2003-12-03 11:28 ` Szakacsits Szabolcs 2003-12-03 11:54 ` Andrew Clausen 2003-12-03 13:07 ` Szakacsits Szabolcs 2003-12-03 23:27 ` Andrew Clausen 2003-12-03 21:55 ` Szakacsits Szabolcs 2003-12-03 23:47 ` bill davidsen [not found] <200311300220.hAU2K0dr019280@sunrise.pg.gda.pl> 2003-11-30 2:22 ` Andrzej Krzysztofowicz 2003-11-30 13:13 ` Andries Brouwer 2003-11-30 13:58 ` John Bradford 2003-11-30 7:08 Norman Diamond 2003-11-30 7:08 Norman Diamond 2003-11-30 12:49 ` Andries Brouwer 2003-12-03 11:06 ` Andrew Clausen 2003-12-03 14:42 ` Andries Brouwer 2003-12-03 23:11 ` Andrew Clausen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).