daily CVS update output
Updating src tree: P src/distrib/common/bootimage/Makefile.bootimage P src/distrib/sets/maketars P src/distrib/sets/regpkgset P src/distrib/sets/sets.subr P src/distrib/sets/lists/base32/ad.mips64eb P src/distrib/sets/lists/base32/ad.mips64el U src/distrib/sets/lists/base64/ad.mips64eb U src/distrib/sets/lists/base64/ad.mips64el U src/distrib/sets/lists/base64/mi P src/distrib/sets/lists/debug32/ad.mips64eb P src/distrib/sets/lists/debug32/ad.mips64el U src/distrib/sets/lists/debug64/ad.mips64eb U src/distrib/sets/lists/debug64/ad.mips64el U src/distrib/sets/lists/debug64/mi P src/distrib/sets/lists/tests/mi P src/external/mit/xorg/lib/libGL/Makefile P src/lib/libc/gen/usleep.3 P src/lib/libc/gen/usleep.c P src/sys/arch/i386/i386/i386_mainbus.c P src/sys/arch/x86/x86/cpu.c P src/sys/arch/x86/x86/intr.c P src/tests/kernel/Makefile U src/tests/kernel/t_signal_and_sp.c U src/tests/kernel/arch/aarch64/stack_pointer.h P src/usr.sbin/sysinst/Makefile.inc P src/usr.sbin/sysinst/defs.h P src/usr.sbin/sysinst/msg.mi.de P src/usr.sbin/sysinst/msg.mi.en P src/usr.sbin/sysinst/msg.mi.es P src/usr.sbin/sysinst/msg.mi.fr P src/usr.sbin/sysinst/msg.mi.pl P src/usr.sbin/sysinst/util.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 42039706 Apr 23 03:03 ls-lRA.gz
Re: disklabel change?
On Mon, Apr 22, 2024 at 03:00:40PM +0100, Patrick Welche wrote: > On Mon, Apr 22, 2024 at 01:11:56PM -, Michael van Elst wrote: > > pr...@welche.eu (Patrick Welche) writes: > > > > >In fact, the difference is between "-t" and "-rt": > > > > >I deem "-t" output to be correct (and matches what I had in /etc/diskpart) > > > > > > The in-kernel disklabel gets the RAW_PART from by the disk geometry > > and if RAW_PART == 3, it gets d_partitions[2] from the MBR partition > > table. > > > > That explains why 'disklabel -t' looks correct, it shows the in-kernel > > disklabel. > > > > It doesn't explain why the on-disk label has the entries swapped. > > When you edit the disklabel, the kernel writes to the disk. When > > that corrects the error, the bug is in the disklabel program, > > otherwise it's in the kernel. > > Given that the content of /etc/disktab agrees with the correct version, > I am pretty sure that 3 years ago I did a "disklabel -r -w sd0 perc" > > I suppose I could do it again and see if -rt becomes correct... oder? After all that: there was a typo in the disktab: :pc#4294703103:od#264192:\ :pd#4294967295:od#0:\ "od" in both lines... After fixing that, -t and -rt agree! Sorry for the noise - it was surprising though... Cheers, Patrick
Re: disklabel change?
On Mon, Apr 22, 2024 at 01:11:56PM -, Michael van Elst wrote: > pr...@welche.eu (Patrick Welche) writes: > > >In fact, the difference is between "-t" and "-rt": > > >I deem "-t" output to be correct (and matches what I had in /etc/diskpart) > > > The in-kernel disklabel gets the RAW_PART from by the disk geometry > and if RAW_PART == 3, it gets d_partitions[2] from the MBR partition > table. > > That explains why 'disklabel -t' looks correct, it shows the in-kernel > disklabel. > > It doesn't explain why the on-disk label has the entries swapped. > When you edit the disklabel, the kernel writes to the disk. When > that corrects the error, the bug is in the disklabel program, > otherwise it's in the kernel. Given that the content of /etc/disktab agrees with the correct version, I am pretty sure that 3 years ago I did a "disklabel -r -w sd0 perc" I suppose I could do it again and see if -rt becomes correct... oder? Cheers, Patrick
Re: disklabel change?
pr...@welche.eu (Patrick Welche) writes: >In fact, the difference is between "-t" and "-rt": >I deem "-t" output to be correct (and matches what I had in /etc/diskpart) The in-kernel disklabel gets the RAW_PART from by the disk geometry and if RAW_PART == 3, it gets d_partitions[2] from the MBR partition table. That explains why 'disklabel -t' looks correct, it shows the in-kernel disklabel. It doesn't explain why the on-disk label has the entries swapped. When you edit the disklabel, the kernel writes to the disk. When that corrects the error, the bug is in the disklabel program, otherwise it's in the kernel.
Re: disklabel change?
In fact, the difference is between "-t" and "-rt": $ disklabel -t sd0 perc|Automatically generated label:\ :dt=SCSI:se#512:ns#32:nt#64:sc#2048:nc#2143360:\ :su#4294967295:\ :pa#20971520:oa#264192:ta=4.2BSD:ba#0:fa#0:\ :pb#33554432:ob#21235712:tb=swap:\ :pc#4294703103:oc#264192:\ :pd#4294703103:od#0:\ :pe#4240177151:oe#54790144:te=4.2BSD:be#0:fe#0: $ disklabel -rt sd0 perc|Automatically generated label:\ :dt=SCSI:se#512:ns#32:nt#64:sc#2048:nc#2143360:\ :su#4294967295:\ :pa#20971520:oa#264192:ta=4.2BSD:ba#0:fa#0:\ :pb#33554432:ob#21235712:tb=swap:\ :pc#4294703103:oc#0:\ :pd#4294967295:od#264192:\ :pe#4240177151:oe#54790144:te=4.2BSD:be#0:fe#0: Given $ sysctl kern.rawpartition kern.rawpartition = 3 I deem "-t" output to be correct (and matches what I had in /etc/diskpart) Cheers, Patrick On Sun, Apr 21, 2024 at 07:02:46PM +0100, Patrick Welche wrote: > With a kernel & userland of 14 April 2024, on amd64, I just did: > > # disklabel -rt sd0 > perc|Automatically generated label:\ > :dt=SCSI:se#512:ns#32:nt#64:sc#2048:nc#2143360:\ > :su#4294967295:\ > :pa#20971520:oa#264192:ta=4.2BSD:ba#0:fa#0:\ > :pb#33554432:ob#21235712:tb=swap:\ > :pc#4294703103:oc#0:\ > :pd#4294967295:od#264192:\ > :pe#4240177151:oe#54790144:te=4.2BSD:be#0:fe#0: > > and was surprised to see that d no longer was the whole disk. My > recollection was that peecees were odd and i386/amd64 used d, whereas > everyone else used c. Has this changed for consistency? > > That computer's /etc/disktab contains > > perc|PERC H700:\ > :dt=SCSI:se#512:ns#32:nt#64:sc#2048:nc#2143360:\ > :su#4294967295:\ > :pa#20971520:oa#264192:ta=4.2BSD:ba#0:fa#0:\ > :pb#33554432:ob#21235712:tb=swap:\ > :pc#4294703103:od#264192:\ > :pd#4294967295:od#0:\ > :pe#4240177151:oe#54790144:te=4.2BSD:be#0:fe#0: > > which shows it was the other way around on 29 April 2021 when the > disklabel was written. > > > Cheers, > > Patrick
