turning off COMPAT_386BSD_MBRPART in disklabel
PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in disklabel(8), even though it was turned off by default in the kernel early in 4.99.x. The PR also notes that it's not harmless to leave it on. I'm inclined to turn it off in disklabel(8) right now. There's no particular reason to have it there if the kernel doesn't support it, and since fixing up a really old disk doesn't require disklabel(8), only fdisk(8) there doesn't seem to be any upgrade/compatibility argument to have it in -6. (I think at least until -6 is branched it would be prudent to leave the code there but disabled, though.) Does anyone object to this? I almost committed the change unilaterally but decided that was pushing things a little. -- David A. Holland dholl...@netbsd.org
Re: turning off COMPAT_386BSD_MBRPART in disklabel
> PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in > disklabel(8), even though it was turned off by default in the kernel > early in 4.99.x. The PR also notes that it's not harmless to leave it > on. > > I'm inclined to turn it off in disklabel(8) right now. There's no > particular reason to have it there if the kernel doesn't support it, > and since fixing up a really old disk doesn't require disklabel(8), > only fdisk(8) there doesn't seem to be any upgrade/compatibility > argument to have it in -6. I wonder if it's worth to add a sysctl knob that returns whether the running kernel has options COMPAT_386BSD_MBRPART or not and make disklabel(8) refer it. --- Izumi Tsutsui
Re: turning off COMPAT_386BSD_MBRPART in disklabel
dholland-t...@netbsd.org said: > PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in > disklabel(8), even though it was turned off by default in the kernel > early in 4.99.x. The PR also notes that it's not harmless to leave it > on. The PR rather leads to the conclusion that the support for old Partition IDs in disklabel(8) is suboptimal. Originally, the code did only consider a partition with the old ID if no new one was found. This apparently got broken when extended partition support was added years later. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Mon, Jan 31, 2011 at 05:40:20PM +0100, Matthias Drochner wrote: > > PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in > > disklabel(8), even though it was turned off by default in the kernel > > early in 4.99.x. The PR also notes that it's not harmless to leave it > > on. > > The PR rather leads to the conclusion that the support for > old Partition IDs in disklabel(8) is suboptimal. > Originally, the code did only consider a partition with the > old ID if no new one was found. This apparently got broken > when extended partition support was added years later. Yeah, that's a valid point. I guess the question then is whether fixing that will prevent any problematic cases from arising... and whether at this point it's worth worrying about. I suspect very few commodity drives old enough to have been fdisk'd with the old partition ID are still operable, and I suspect that anyone who's got one that hasn't been updated already is qualified to run fdisk... and there are very few cases where anyone would need to run disklabel but not be able to run fdisk first. So I'd really be inclined at this point to just disable the feature. ...also, it's not entirely clear to me what the code is supposed to be doing if there are multiple NetBSD partitions; it looks as if what it *will* do is use the label from the one it sees last and write the same label to all of them. blah, using both fdisk partitions and traditional labels on the same disk has always been a pile of fail. -- David A. Holland dholl...@netbsd.org
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Thu, Feb 03, 2011 at 02:56:35AM +, David Holland wrote: > > ...also, it's not entirely clear to me what the code is supposed to be > doing if there are multiple NetBSD partitions; it looks as if what it > *will* do is use the label from the one it sees last and write the > same label to all of them. That is what I intended it to do. Nothing else makes sense (well, it could use the first!). The disklabel describes the partition layout of the disk (not the type 169 mbr partition), it has to be saved on the disk. Saving it is ALL the partitions (and, IIRC, anywhere else it manages to find a copy!) avoids confusion and allows the pbr boot code to find it. Because the kernel is told about the label, if you try to have different labels in different places on the disk then you are likely to lose badly. Not helped by the fs code not remembering the base sector for mounted partitions and looking at the current label for every transfer! David -- David Laight: da...@l8s.co.uk
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Thu, Feb 03, 2011 at 02:56:35AM +, David Holland wrote: > On Mon, Jan 31, 2011 at 05:40:20PM +0100, Matthias Drochner wrote: > > > PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in > > > disklabel(8), even though it was turned off by default in the kernel > > > early in 4.99.x. The PR also notes that it's not harmless to leave it > > > on. > > > > The PR rather leads to the conclusion that the support for > > old Partition IDs in disklabel(8) is suboptimal. > > Originally, the code did only consider a partition with the > > old ID if no new one was found. This apparently got broken > > when extended partition support was added years later. > > Yeah, that's a valid point. I guess the question then is whether > fixing that will prevent any problematic cases from arising... and > whether at this point it's worth worrying about. Possibly the code should be willing to locate and process such a label. Possibly even write it back. But it probably shouldn't 'corrupt' it - ie leave it as a valid label (doesn't it contain sector number relative to the ptn iteself? so can't describe any other parts of the disk?) David -- David Laight: da...@l8s.co.uk
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Thu, Feb 03, 2011 at 08:01:34AM +, David Laight wrote: > > The disklabel describes the partition layout of the disk (not the type > 169 mbr partition), it has to be saved on the disk. > > Saving it is ALL the partitions (and, IIRC, anywhere else it manages to find > a copy!) avoids confusion and allows the pbr boot code to find it. But this is potentially very dangerous, in combination with COMPAT_386BSD_MBRPART, because FreeBSD considers labels to be per-"slice" (per fdisk-partition) and uses the 0x165 partition type. So if we are not very careful, we can hopelessly wreck FreeBSD installations in other MBR partitions.
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Thu, Feb 03, 2011 at 05:59:15AM -0500, Thor Lancelot Simon wrote: > On Thu, Feb 03, 2011 at 08:01:34AM +, David Laight wrote: > > > > The disklabel describes the partition layout of the disk (not the type > > 169 mbr partition), it has to be saved on the disk. > > > > Saving it is ALL the partitions (and, IIRC, anywhere else it manages to find > > a copy!) avoids confusion and allows the pbr boot code to find it. > > But this is potentially very dangerous, in combination with > COMPAT_386BSD_MBRPART, because FreeBSD considers labels to be per-"slice" > (per fdisk-partition) and uses the 0x165 partition type. So if we are not > very careful, we can hopelessly wreck FreeBSD installations in other > MBR partitions. I'm not advocating (above) writing the NetBSD format label to a type 165 mbr partition. Quite clearly anything written to such a partition probably ought to have relative sector numbers. It might be an interesting exercise to detect a relative disklabel in a type 169 partition - and convert it to absolute OTOH that isn't needed now. David -- David Laight: da...@l8s.co.uk
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Thu, Feb 03, 2011 at 08:04:26AM +, David Laight wrote: > > > The PR rather leads to the conclusion that the support for > > > old Partition IDs in disklabel(8) is suboptimal. > > > Originally, the code did only consider a partition with the > > > old ID if no new one was found. This apparently got broken > > > when extended partition support was added years later. > > > > Yeah, that's a valid point. I guess the question then is whether > > fixing that will prevent any problematic cases from arising... and > > whether at this point it's worth worrying about. > > Possibly the code should be willing to locate and process such a label. > Possibly even write it back. > But it probably shouldn't 'corrupt' it - ie leave it as a valid label > (doesn't it contain sector number relative to the ptn iteself? > so can't describe any other parts of the disk?) Are *our* ancient disklabels partition-relative? It's so long ago that I'm not sure... but the code in currently in disklabel(8) doesn't appear to know anything at all about partition-relative labels. Given the rest of the discussion here, the fact that fixing disklabel(8) properly isn't completely trivial, and tls's recent experience, I think the feature should just be turned off in disklabel... but, just in case, not removed entirely until we branch netbsd-6. Does anyone object to this course of action? -- David A. Holland dholl...@netbsd.org
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Mon, Feb 07, 2011 at 05:07:51AM +, David Holland wrote: > > Are *our* ancient disklabels partition-relative? It's so long ago that > I'm not sure... but the code in currently in disklabel(8) doesn't appear > to know anything at all about partition-relative labels. They are not. This was a major point of divergence between FreeBSD and NetBSD. > Given the rest of the discussion here, the fact that fixing > disklabel(8) properly isn't completely trivial, and tls's recent > experience, I think the feature should just be turned off in > disklabel... but, just in case, not removed entirely until we branch > netbsd-6. For the record, I am pretty sure it was sysinst, not disklabel, which hosed my disk. Sysinst compiles equivalent code in directly, no? As it stands now, installing NetBSD on a disk that has previously had FreeBSD installed in the physically-first MBR partition will destroy that FreeBSD installation. Not good. Thor
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Mon, Feb 07, 2011 at 01:48:57AM -0500, Thor Lancelot Simon wrote: > > For the record, I am pretty sure it was sysinst, not disklabel, which > hosed my disk. Sysinst compiles equivalent code in directly, no? x86/amd64 sysinst uses it own code for fdisk and installboot. I can't quite remember whether it runs disklabel - but it will request it writes a label from a temporary file... David -- David Laight: da...@l8s.co.uk
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Mon, Feb 07, 2011 at 06:35:49PM +, David Laight wrote:
> x86/amd64 sysinst uses it own code for fdisk and installboot.
> I can't quite remember whether it runs disklabel - but it will request
> it writes a label from a temporary file...
What David says:
int
write_disklabel (void)
{
#ifdef DISKLABEL_CMD
/* disklabel the disk */
return run_program(RUN_DISPLAY, "%s -f /tmp/disktab %s '%s'",
DISKLABEL_CMD, diskdev, bsddiskname);
#else
return 0;
#endif
}
Martin
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Mon, Feb 07, 2011 at 01:48:57AM -0500, Thor Lancelot Simon wrote: > For the record, I am pretty sure it was sysinst, not disklabel, which > hosed my disk. Sysinst compiles equivalent code in directly, no? There are only two uses of MBR_PTYPE_386BSD in src/distrib. One is a perfectly innocuous list of partition type IDs. The other is in src/distrib/utils/sysinst/arch/i386/md.c, which changes the partition ID of a MBR_PTYPE_386BSD partition to MBR_PTYPE_NETBSD if no MBR_PTYPE_NETBSD partitions are seen. This is, however, only reached if someone's explicitly attempting to upgrade an existing installation, so it's probably harmless -- I think you got hosed by disklabel. This code should probably be removed from sysinst too, but maybe after -6 is branched. -- David A. Holland dholl...@netbsd.org
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Sat, Feb 12, 2011 at 10:07:48PM +, David Holland wrote: > On Mon, Feb 07, 2011 at 01:48:57AM -0500, Thor Lancelot Simon wrote: > > For the record, I am pretty sure it was sysinst, not disklabel, which > > hosed my disk. Sysinst compiles equivalent code in directly, no? > > There are only two uses of MBR_PTYPE_386BSD in src/distrib. One is a > perfectly innocuous list of partition type IDs. The other is in > src/distrib/utils/sysinst/arch/i386/md.c, which changes the partition > ID of a MBR_PTYPE_386BSD partition to MBR_PTYPE_NETBSD if no > MBR_PTYPE_NETBSD partitions are seen. > > This is, however, only reached if someone's explicitly attempting to > upgrade an existing installation, so it's probably harmless -- I think > you got hosed by disklabel. Sysinst also asks all the disk setup questions and asks you to confirm before writing to the disk at all. So you'd have to try quite hard to get it to kill the partitioning. (Unless it was the kernel 'write out the label' code that killed it.) David -- David Laight: da...@l8s.co.uk
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Sun, Feb 13, 2011 at 02:04:31PM +, David Laight wrote: > > Sysinst also asks all the disk setup questions and asks you to confirm > before writing to the disk at all. So you'd have to try quite hard > to get it to kill the partitioning. Not in the failure case I observed (I can now reproduce this, but since it looks like the code in disklabel is going to Go, I haven't bothered to analyze it further). I told it partitioning that was non-overlapping with the FreeBSD partition, but it wrote that (NetBSD) partitioning out to disk over *both* disklabels, the FreeBSD one that happened to be at the head of the disk (inside the FreeBSD MBR partition!) and the NetBSD one in the proper place. If the kernel write-out-label code can do something similar, that ought to get the axe, too. Thor
Re: turning off COMPAT_386BSD_MBRPART in disklabel
On Sun, Feb 13, 2011 at 01:06:36PM -0500, Thor Lancelot Simon wrote: > Not in the failure case I observed (I can now reproduce this, but since > it looks like the code in disklabel is going to Go, It has Gone :-) (The remaining question is whether to request pullup to -5; I think I will unless someone is strongly opposed.) > If the kernel write-out-label code can do something similar, that ought > to get the axe, too. It was disabled by default four years ago. -- David A. Holland dholl...@netbsd.org
