On 5/1/23 14:03, David Rogers wrote:
Thanks for the help. -Dave On 5/1/23 13:14, Kenneth Westerback wrote:Plane delayed. :-)What may be happening is that the previous disklabel contained geometry not related to the current drive. "disklabel -d sd2 will display the geometry as the kernel sees it now. One of the recent changes was to always update the geometry info to reflect the current situation.To update the on-disk info and possibly update the disklabel format just disklabel -E and 'w'rite it.The geometry info is not really used and is gradually being excised from the disklabel..... KenOn Mon, May 1, 2023, 1:08 p.m. Kenneth Westerback <kwesterb...@gmail.com> wrote:I don't think that matters. Boarding a plane at the moment. More coherent/detailed answer in a few hours. .... Ken On Mon, May 1, 2023, 11:32 a.m. David Rogers <davrog...@gmail.com> wrote: PhineasJ. Whoopee, you're the greatest! I can access the drive now. I tried using "echo "/ *" | disklabel -wAT- sd2", but that didn't do much. I then tried manually editing the label, but disklabel couldn't write to the disk. Finally, I tried the surgical method: dd if=/dev/rsd2c of=disklabelcopy bs=512 count=1 skip=1 dd if=/dev/disklabelcopy of=/dev/rsd2c bs=512 count=1 seek=129 dd if=/dev/zero of=/dev/rsd2c bs=512 count=1 skip=1 And that did the trick. Now, it's still reporting: sectors/track: 255 tracks/cylinder: 511 sectors/cylinder: 130305 This differs from what it reported under 7.1. I don't see a way to edit that. Is this something that the OS autopopulates? Does it even matter? -Dave On 4/29/23 11:32, Kenneth Westerback wrote:OK! hexdump -C -x on the file shows the first 512 bytes are the MBR (last two bytes are the signature 55 aa): 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 00 00 00 1f a9 f2 16 00 00 00 00 |................| 000001c0 02 00 ee ff ff ff 01 00 00 00 ff ff ff ff 00 00 |................| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| And the next 512 bytes are a disklabel (first four bytes are the magic number 0x82564557): 00000200 57 45 56 82 04 00 00 00 53 43 53 49 20 64 69 73 |WEV.....SCSI dis| 00000210 6b 00 00 00 00 00 00 00 4d 79 20 42 6f 6f 6b 20 |k.......My Book | 00000220 31 32 33 35 20 20 20 20 00 02 00 00 3f 00 00 00 |1235 ....?...| 00000230 ff 00 00 00 fd 6b 07 00 c1 3e 00 00 00 b8 bf d1 |.....k...>......| 00000240 4f d8 16 83 db bc 37 bb 00 00 00 00 00 00 01 00 |O.....7.........| 00000250 00 00 00 00 00 b8 bf d1 00 00 00 00 00 00 00 00 |................| 00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000270 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 57 45 56 82 15 6e 10 00 00 20 00 00 |....WEV..n... ..| 00000290 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002b0 00 00 00 00 00 b8 bf d1 00 00 00 00 00 00 01 00 |................| 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000310 00 00 00 00 80 b7 bf d1 80 00 00 00 00 00 01 00 |................| 00000320 07 24 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |.$..............| 00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| And searching for another "WEV" in the text fails so there is no disklabel where 7.3 expects it (in the 2nd block of the OpenBSD partion). So things are as I expected. The trick now is to put a disklabel at the 7.3 expected spot as previously explained. The surgical way would be to copy the 2nd block into the 129'th block, i.e. the 2nd block in the OpenBSD partition. dd if=/dev/rsd2c of=disklabelcopy bs=512 count=1 skip=1 dd if=/dev/disklabelcopy of=/dev/rsd2c bs=512 count=1 seek=129 and if that works nuke the old one to reduce future confusion dd if=/dev/zero of=/dev/rsd2c bs=512 count=1 skip=1 Double check the dd man page. :-) You might be interested in my EuroBSDCon 2022 talk, "How OpenBSD transforms a bag of blocks into a set of useful filesystems", linked fromhttps://www.openbsd.org/events.html. Some of the reasons for the change in logic are touched upon. .... Ken David Rogers<davrog...@gmail.com> <mailto:davrog...@gmail.com> writes:I've attached the results of "dd if=/dev/sd2c of=myblocks bs=512 count=128". -Dave On 4/28/23 09:12, Kenneth Westerback wrote:Excellent. Note that if the 'echo' does not produce the desired result, the drive *should* still be perfectly ok and the other two options can be tried instead. Irregardless I am interested in getting the dd of the first 128, Well, let's say the first 256 just to safe, sectors. What I expect to see is that there is a disklabel immediately following the MBR. That would be the old one. I would also expect to see a new disklabel in the first couple of sectors in the OpenBSD partition. The truly paranoid would zero the old one once things are working again. :-) .... Ken David Rogers<davrog...@gmail.com> <mailto:davrog...@gmail.com> writes:I'll revert and back up the drive, then do the "echo "/ *" | disklabel -wAT- sd2" and let you know if it works. -Dave On 4/27/23 11:18, Kenneth Westerback wrote:OK, what is happening here is that 7.3 can't find the disklabel on the disk. And thus 'i' is not available. This was likely caused by recent (a.k.a. 7.2+) changes to how disklabel locations were determined. So discard that diff. ses(4) is not the issue. Given that 'i' is being used I suspect this is a drive that was converted to OpenBSD quite a while ago, and the conversion involved just changing the filesystem type on the 'i' partition that came with the drive and was likely NTFS or something. The easiest solution is to create a new disklabel and write it to disk. With 7.3 the command echo "/ *" | disklabel -wAT- sd2 should give you a disklabel that has a single 4.2BSD 'a' partition containing all the space like the 'i' partition did. You might end up with different fsize/bsize/cpg values but they should be superseded by the values within the filesystem. BACKUP BEFORE USE! :-) Alternatively you could 'disklabel -E sd2' and enter the exact same partition info (X for expert mode will allow you to set the fsize, etc.). If you want to be more surgical, you can dd the first 128 sectors off of the disk (dd if=/dev/rsd2c of=myblocks bs=512 count=128) and either send me the file or use hexdump to look for the disklabel in those first 128 blocks. Then it becomes a simple matter of dd'ing the sector containing the misplaced disklabel to where the kernel expects to find it these days. You are not the first to see this. Fortunately it seems to occur rarely and usually involve a drive like yours. .... Ken David Rogers<davrog...@gmail.com> <mailto:davrog...@gmail.com> writes:Okay. I've got the disklabel info here. First I'll give the 7.1, then the 7.3. Last I'll give the diff between 7.1 and 7.3: *****7.1: # /dev/rsd2c: type: SCSI disk: SCSI disk label: My Book 1235 duid: 4fd81683dbbc37bb flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 486397 total sectors: 7813969920 boundstart: 0 boundend: 7813969920 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] c: 7813969920 0 unused i: 7813969792 128 4.2BSD 8192 65536 1 *****7.3: # /dev/rsd2c: type: SCSI disk: SCSI disk label: My Book 1235 duid: 0000000000000000 flags: bytes/sector: 512 sectors/track: 255 tracks/cylinder: 511 sectors/cylinder: 130305 cylinders: 59966 total sectors: 7813969920 boundstart: 0 boundend: 7813969920 16 partitions: # size offset fstype [fsize bsize cpg] c: 7813969920 0 unused ******diff 7.1 7.3: 5c5 < duid: 4fd81683dbbc37bb ---duid: 00000000000000008,11c8,11 < sectors/track: 63 < tracks/cylinder: 255 < sectors/cylinder: 16065 < cylinders: 486397 ---sectors/track: 255 tracks/cylinder: 511 sectors/cylinder: 130305 cylinders: 5996615d14 < drivedata: 0 20d18 < i: 7813969792 128 4.2BSD 8192 65536 1 Weird, huh. -Dave On 4/25/23 13:11, Kenneth Westerback wrote:You can try entering '-c' at the boot> prompt, and then 'disable ses' at the UKC> prompt, followed by 'quit'. This should prevent the ses device from being recognized. If that works then I'll have to figure out why suddenly having lun 1 probed is a problem or why the scsi subsystem gets confused about sd2 when ses(4) can't read the enclosure data. Depending on how easy it is for you to try diffs for more debug info I can send you a few to try. A 7.1 dmesg might help as well as 7.1 disklabel -v output and fdisk -v output. .... Ken David Rogers<davrog...@gmail.com> <mailto:davrog...@gmail.com> writes:Synopsis: Beginning with 7.2, system won't mount Western Digital Mybookexternal HDCategory: system Environment:System : OpenBSD 7.3 Details : OpenBSD 7.3 (GENERIC.MP <http://GENERIC.MP>) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64Description:The problem is identical on both my laptops. This Email includes the system info for my cheap-but-surprisingly-robust Lenovo G50-80. Seriously, this thing was $120 ten years ago, yet has been my main machine since I ditched the Apple. I dind't think to run sendbug when the drive was attached. Let me know if you want that. Anyway, The problem occurs with a USB-attached Western Digital MyBook external hard drive that I use to backup my home directory before I upgrade OpenBSD. The drive was formatted with FFS several years ago under a previous version of OpenBSD. On v7.1, it mounted without issue on both laptops. Beginning with v7.2, that same drive could not longer be mounted. When I reverted back to 7.1, it could again be mounted. USB flash drives mount just fine. When the WD HD is plugged into a USB port, the system gives the expected message: umass() at uhub0 port 2 configuration 1 interfact o "Western Digital My Book 1235) rev 3.00/10.05 addr 3 umass(): using SCSI over Bulk-only scsibus6 at umass(): 2 targets, intiator 0 sd2 at scsibus6 targ 1 lun 0: <ED, My Book 1235,1005> sd2: 3815415MB, 512 btes/sector, 7813969920 sectors But then, a couple of seconds later, a new message is given: ses() at scsibus6 targ 1 lun 1: <WD, SES Device, 1005> ses(): unable to read enclosure configuration When attempting to mount the drive, the command fails, giving: mount_ffs: /dev/sd2i on /mnt: Device not configured.How-To-Repeat:Once booted, log in as root. Plug the powered external WD HD into a USB port. Then type: mount /dev/sd2i /mnt That's it. There's no secret sauce. It just fails.Fix:No known fix. -- .... Ken
