can't mount Dangerously Dedicated USB stick

O

oneev

Hello fellow FreeBSD users,
I try to mount a USB stick to recover a geli key.
This stick has a full install and I used to boot on it and run FreeBSD (version 7 or 8).
When I created it I did not use slices and make it dedicated (I forgot why).
The server hardware is broken and I can't boot on an other machine (tried uefi and legacy boot).

So now I try to mount it.
For safety I work on an image disk, but the results are exactly the same if I run those commands on the stick itself.
I can see that the image is indeed UTF2.

Code: 
mdconfig -a -t vnode -f image.img  -u 1

# file -s /dev/md1
/dev/md1: Unix Fast File system [v2] (little-endian) last mounted on , last written at Sat Apr 23 02:30:15 2011, clean flag 0, readonly flag 0, number of blocks 3915772, number of data blocks 3791411, number of cylinder groups 0, block size 0, fragment size 0, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 0, TIME optimization

# mount /dev/md1 /mnt
mount: /dev/md1: No such file or directory

As it's dedicated, there are no slices, only /dev/md1 (or /dev/da1)


Code: 
# fdisk /dev/md1
******* Working on device /dev/md1 *******
parameters extracted from in-core disklabel are:
cylinders=974 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=974 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 15647247 (7640 Meg), flag 80 (active)
    beg: cyl 0/ head 1/ sector 1;
    end: cyl 973/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>


# diskinfo /dev/md1
/dev/md1    512    8019509248    15663104    0    0

Any help on how I could mount the USB stick would be greatly appreciated.
Regards,
Colin
 
It would be useful to see the result of ls -l /dev/md1*.
By the way, also make sure that the mount point /mnt actually exists.
 
The gpart is empty, hens the fdisk
Code: 
# gpart show /dev/md1
gpart: No such geom: /dev/md1.
And here the listing of the md image and actual stick
Code: 
# ls -l /dev/md1*
crw-rw----  1 root  operator  0x9e Feb  1 10:57 /dev/md1
# ls -l /dev/da1*
crw-rw----  1 root  operator  0xc2 Jan 31 18:43 /dev/da1

There are no BSD slices, it's a dedicated formatting
(mount point md exist)
 
  1. Before mounting, do fsck /dev/da1.
  2. nd thought I have is that there are now (one?) sysctl(8) knobs who prevent access to the 1st blocks of a device, where usually the partition table resides. I think it's kern.geom.part.check_integrity? So when you dd(1) the device to that file image.img, dd(1) might have missed some blocks.
  3. Parameters of dd(1)?
  4. You can also verify that another imagefile copied with recoverdisk(1) is identical to your image.img
 
  • Thanks
Reactions: a6h
When a mount command fails, it might also be useful to look at /var/log/messages. Sometimes the kernel’s file system module produces messages that indicate what the problem is, e.g. if there’s something wrong with the UFS superblock.
 
oneev said:
The gpart is empty, hence the fdisk
Click to expand...
That's important because that means there really isn't a partition table there. If you look at the fdisk(8) output it "claims" there is a partition/slice on it when there is none.

Try adding the read-only flag (even if the filesystem is dirty you should still be able to mount it read-only) and forcing the filesystem: mount -t ufs -o ro /dev/md1 /mnt
Also double check if the md1 device is still valid, remove and recreate it just to be sure ( mdconfig -d -u 1, mdconfig -a -f image.img),
 
I recreated the md device.
But mount reacts as if the device does not exist. Same result with the stick itself
Code: 
root@NomadBSD:/data # mdconfig -d -u 1
root@NomadBSD:/data # mdconfig -a -f lttleowl.img
md1
root@NomadBSD:/data # mount -t ufs -o ro /dev/md1 /mnt
mount: /dev/md1: No such file or directory
root@NomadBSD:/data # mount -t ufs -o ro /dev/da1 /mnt
mount: /dev/da1: No such file or directory

root@NomadBSD:/data # ls -l /dev/md1*
crw-rw----  1 root  operator  0x9e Feb  1 16:11 /dev/md1
root@NomadBSD:/data # ls -l /dev/da1*
crw-rw----  1 root  operator  0xc2 Jan 31 18:43 /dev/da1
root@NomadBSD:/data #
The USB stick is /dev/ad1:
Code: 
root@NomadBSD:/data # camcontrol devlist
<KingFast 20140326>                at scbus0 target 0 lun 0 (ada0,pass0)
<SAMSUNG HM100UI 2AM10001>         at scbus1 target 0 lun 0 (ada1,pass1)
<AHCI SGPIO Enclosure 2.00 0001>   at scbus2 target 0 lun 0 (ses0,pass2)
<SMI USB DISK 1100>                at scbus5 target 0 lun 0 (da0,pass3)
<Corsair Voyager 1100>             at scbus6 target 0 lun 0 (da1,pass4)

The log messages are unfortunately not so useful (only related ti wireless)
Code: 
Feb  1 15:36:29 NomadBSD kernel: Limiting closed port RST response from 304 to 200 packets/sec
Feb  1 15:36:48 NomadBSD kernel: ath0: ath_legacy_rx_tasklet: sc_inreset_cnt > 0; skipping
Feb  1 15:40:32 NomadBSD syslogd: last message repeated 1 times
Feb  1 15:44:09 NomadBSD syslogd: last message repeated 1 times
Feb  1 15:52:56 NomadBSD syslogd: last message repeated 1 times
Feb  1 16:04:17 NomadBSD syslogd: last message repeated 4 times
Feb  1 16:12:28 NomadBSD syslogd: last message repeated 2 times

What I don't understand is that I booted on this USB stick for years without problem. But I never mounted it
 
Just for testing I created a bogus image file and it just mounts as expected:
Code: 
root@molly:~/test # truncate -s 1G test.img
root@molly:~/test # mdconfig -a -f test.img
md1
root@molly:~/test # newfs /dev/md1
/dev/md1: 1024.0MB (2097152 sectors) block size 32768, fragment size 4096
        using 4 cylinder groups of 256.03MB, 8193 blks, 32896 inodes.
super-block backups (for fsck_ffs -b #) at:
 192, 524544, 1048896, 1573248
root@molly:~/test # file -s /dev/md1
/dev/md1: Unix Fast File system [v2] (little-endian) last mounted on , last written at Mon Feb  1 17:03:26 2021, clean flag 1, readonly flag 0, number of blocks 262144, number of data blocks 253831, number of cylinder groups 4, block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
root@molly:~/test # mount /dev/md1 /mnt/
root@molly:~/test # ls -al /mnt/
total 33
drwxr-xr-x   3 root  wheel     512 Feb  1 17:03 .
drwxr-xr-x  22 root  wheel      28 Feb  1 10:32 ..
drwxrwxr-x   2 root  operator  512 Feb  1 17:03 .snap

You mentioned it was an older FreeBSD version? Something like 7 or 8? I don't expect any issues with that, I don't think anything major has changed with the filesystem in between those versions and 11, 12 or 13. If it was pre-5.0 then it could have been UFS1, UFS2 was introduced with 5.0 and has been the standard since.

Now that I think about it. This image won't be able to boot. Since there's no boot sector on there. Can you look at the first 1K of that file? Use hexdump(1). I suspect it has a bootsector and the actual filesystem might start a few blocks away from it. This was usually 40 blocks (that's 20 KBytes assuming the standard 512 Byte blocks). So chopping off the first few KBytes might align it with the actual filesystem. The output from fdisk(8) mentions 63, I can remember this was a typical starting point for slices. So try removing the first 40 blocks and if that doesn't work the next 23 blocks too.
 
Violà! Right, the boot blocks! Then it's dd -iseek=xx ...
Lesson learnt:
  • Do not use raw devices, except when there's a good reason (e.g. DB "files")
  • In this case, ithere had been no problem if the drive had been formated. And formating the device has clearly no disadvantage here.
 
This could be the decisive lead.

Code: 
root@NomadBSD:/data # hexdump -n 1000 -C lttleowl.img
00000000  a8 88 63 62 41 04 14 40  cb cb 89 88 11 11 50 50  |..cbA..@......PP|
00000010  f5 85 78 68 c0 c0 22 22  f7 ee be be 14 14 23 23  |..xh..""......##|
00000020  30 04 5c 4d 4c 4c 80 1c  8d 9d 0b 0a c0 d0 1a 12  |0.\MLL..........|
00000030  22 e9 6d 65 31 11 0f 02  20 39 8b 82 49 19 4e 4a  |".me1... 9..I.NJ|
00000040  c8 88 67 62 49 49 44 40  eb db 89 88 59 99 55 50  |..gbIID@....Y.UP|
00000050  f5 9b 28 28 f8 d9 2f 22  62 1a be b2 14 14 23 23  |..((../"b.....##|
00000060  00 00 40 40 4c 4c 80 80  dd 8f 0a 0a c6 46 32 7a  |..@@LL.......F2z|
00000070  22 22 65 65 11 11 02 02  20 20 82 82 01 01 4a 4a  |""ee....  ....JJ|
00000080  a8 88 63 62 41 41 40 40  cb cb 89 88 11 11 50 50  |..cbAA@@......PP|
00000090  f5 85 78 68 c0 c0 22 22  f6 ee be be 14 14 23 23  |..xh..""......##|
000000a0  30 04 5c 4d 4c 4c 80 80  9d 9f 0b 0a 40 d6 1a 12  |0.\MLL......@...|
000000b0  2a 2f 6d 65 31 17 0f 02  38 3d 8b 82 41 1f 4e 4a  |*/me1...8=..A.NJ|
000000c0  68 8a 67 62 41 1d 44 40  db df 89 88 51 1f 55 50  |h.gbA.D@....Q.UP|
000000d0  65 97 28 28 f0 db 2f 22  7a ff be b2 14 14 23 23  |e.((../"z.....##|
000000e0  00 00 40 40 4c 4c 80 80  dd 8f 0a 0a 44 44 12 32  |..@@LL......DD.2|
000000f0  22 22 65 65 11 11 02 02  20 20 82 82 01 01 4a 4a  |""ee....  ....JJ|
00000100  a8 88 63 62 41 41 40 40  cb cb 89 88 11 11 50 50  |..cbAA@@......PP|
00000110  f7 85 78 68 c0 c0 22 22  f6 ee be be 14 14 23 23  |..xh..""......##|
00000120  30 04 5c 4d 4c 4c 80 80  9d 8d 0b 0a d0 c4 1a 12  |0.\MLL..........|
00000130  22 26 6d 65 31 35 0f 02  30 24 8b 82 39 25 4e 0b  |"&me15..0$..9%N.|
00000140  c8 a8 67 62 49 65 44 04  db ef 89 88 59 15 55 50  |..gbIeD.....Y.UP|
00000150  d3 a5 28 17 e8 e0 2f 22  70 e6 be b2 14 14 23 23  |..(.../"p.....##|
00000160  00 00 40 40 4c 4c 80 80  dd 8f 0a 0a 40 d0 7a 3a  |..@@LL......@.z:|
00000170  22 22 65 65 11 11 02 02  20 20 82 82 01 01 4a 4a  |""ee....  ....JJ|
00000180  a8 88 63 62 41 41 40 40  cb cb 89 88 11 11 50 40  |..cbAA@@......P@|
00000190  f7 85 78 68 c0 c0 22 22  f7 ee be be 14 14 23 23  |..xh..""......##|
000001a0  30 04 5c 4d 4c 4c 80 80  cd cd 0b 0a d0 40 1a 12  |0.\MLL.......@..|
000001b0  2a 22 6d 65 71 73 0b 02  28 20 8b 82 71 63 4a 4a  |*"meqs..( ..qcJJ|
000001c0  68 6a 63 62 41 61 40 40  cb eb 89 88 11 53 51 50  |hjcbAa@@.....SQP|
000001d0  95 67 28 1a e0 e2 2b 22  ea 62 ba b2 1c 14 23 23  |.g(...+".b....##|
000001e0  00 00 40 40 4c 4c 80 80  dd 8f 0a 0a c0 c2 1a 1a  |..@@LL..........|
000001f0  22 22 65 65 11 11 02 02  20 20 82 06 01 01 4a 4a  |""ee....  ....JJ|
00000200  88 88 63 62 41 41 40 40  cb cb 89 88 11 11 50 50  |..cbAA@@......PP|
00000210  f7 85 78 68 c0 c0 22 22  fa ee be 3e 14 14 23 23  |..xh..""...>..##|
00000220  30 04 5c 4d 4c 4c 80 80  cd cf 0b 0a 08 46 1a 12  |0.\MLL.......F..|
00000230  22 27 6d 65 51 77 0b 02  20 25 8b 82 eb 67 4a 4a  |"'meQw.. %...gJJ|
00000240  88 6a 63 62 69 65 40 40  cb eb 89 88 19 59 51 50  |.jcbie@@.....YQP|
00000250  15 65 28 28 d8 e8 2b 22  62 6a ba b2 14 14 23 23  |.e((..+"bj....##|
00000260  00 00 40 40 4c 4c 80 80  dd 8f 0a 0a d4 c4 52 3a  |..@@LL........R:|
00000270  22 22 65 65 11 11 02 02  20 20 82 82 01 01 4a 4a  |""ee....  ....JJ|
00000280  00 03 14 14 04 01 14 00  24 cb 09 a0 46 54 25 25  |........$...FT%%|
00000290  59 16 5e 5f fb 33 01 05  79 19 74 15 e0 e0 08 08  |Y.^_.3..y.t.....|
000002a0  30 1d c8 c8 a0 24 2d 2d  38 2d 09 01 d0 f9 49 48  |0....$--8-....IH|
000002b0  41 61 89 88 36 2f e5 e5  48 68 51 51 0a 0b 09 00  |Aa..6/..HhQQ....|
000002c0  0a 67 1c 14 54 45 1d 14  6c 6d 28 20 c6 67 2d a0  |.g..TE..lm( .g-.|
000002d0  5a 5f 5b 52 bb 7f 05 05  19 79 05 04 e0 e0 08 08  |Z_[R.....y......|
000002e0  34 34 88 88 a0 a0 3d 3d  a0 08 01 00 99 d1 db 5a  |44....==.......Z|
000002f0  01 01 88 88 26 26 e5 e5  08 08 51 51 0a 0a 00 00  |....&&....QQ....|
00000300  04 03 14 14 04 04 14 14  2b e4 34 20 46 46 25 25  |........+.4 FF%%|
00000310  5b 5c 5a 5f 93 3b 24 05  7b 19 54 45 14 e0 08 00  |[\Z_.;$.{.TE....|
00000320  30 b5 c8 c8 a0 28 00 19  a8 89 09 01 b8 d0 4a 03  |0....(........J.|
00000330  c1 73 89 88 af 36 e5 e5  c8 6a 53 53 89 0a 0a 00  |.s...6...jSS....|
00000340  02 12 1c 12 c4 56 1d 14  e4 67 28 20 59 76 2d 24  |.....V...g( Yv-$|
00000350  17 53 5a 68 3a 7b 05 04  19 7b 05 a0 e0 e0 28 08  |.SZh:{...{....(.|
00000360  34 34 88 88 a0 a0 3d 99  a0 08 01 03 99 98 48 4b  |44....=.......HK|
00000370  01 01 88 88 26 26 e5 e5  08 08 51 08 0a 0a 00 40  |....&&....Q....@|
00000380  06 03 04 12 04 04 14 14  24 e4 34 20 46 56 21 25  |........$.4 FV!%|
00000390  5a 5f 5c 5e 39 38 05 05  7b 19 54 45 e0 e0 09 08  |Z_\^98..{.TE....|
000003a0  34 bd cc c8 a0 a0 35 35  2c 29 0b 0b b0 f8 5a 48  |4.....55,)....ZH|
000003b0  39 71 2d 88 26 74 e5 e5  48 68 51 51 0a 0a 09 00  |9q-.&t..HhQQ....|
000003c0  1a 1a 1c 14 44 ae 1d 14  6c 6c 28 20 76 76 2d 25  |....D...ll( vv-%|
000003d0  5a 5a 5b 52 bb 7b 05 05  19 79 05 04 e0 14 0b 29  |ZZ[R.{...y.....)|
000003e0  14 34 88 88 a0 84 14 2c                           |.4.....,|
000003e8

This is exactly the same output if I use
Code: 
hexdump -n 1000 -C /dev/da1

Supposing the trick is to skip the beginning of the file. Is it possible to do it with gnop?
Though I'm at a loss about the units. I suppose those are 40 block of 512 bytes?
How could I test it?
 
Here my naive test:

Code: 
root@NomadBSD:/data # dd if=/dev/da1 of=test.img bs=512 count=1000 iseek=63
1000+0 records in
1000+0 records out
512000 bytes transferred in 0.636805 secs (804014 bytes/sec)
root@NomadBSD:/data # mdconfig -a -f test.img
md2
root@NomadBSD:/data # mount /dev/md2 /mnt
mount: /dev/md2: Input/output error
Am I right to assume I could mount the image with only 512k of it?
And would you have a suggestion on how much to skip?
 
I can mount such “dangerously dedicated” USB sticks just fine. If you just need one file system on a stick, there is no reason to create partitions or anything. I assume there must be something else wrong with your USB stick or the image.
 
You wrote:
 
Code: 
# file -s /dev/md1
/dev/md1: Unix Fast File system [v2] (little-endian) last mounted on , last written at Sat Apr 23 02:30:15 2011, clean flag 0, readonly flag 0, number of blocks 3915772, number of data blocks 3791411, number of cylinder groups 0, block size 0, fragment size 0, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 0, TIME optimization
That looks suspicious. Many values are 0 (e.g. cylinder groups, block size and fragment size) – this is invalid. I guess this prevents the kernel from recognizing the file system. For a typical UFS, it should rather look like this:
 
Code: 
/dev/md0: Unix Fast File system [v2] (little-endian) last mounted on , last written at Mon Feb  1 18:34:36 2021, clean flag 1, readonly flag 0, number of blocks 25600, number of data blocks 24679, number of cylinder groups 4, block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
Typically, the UFS block size is 32k and the fragment size is 1/8 of that, i.e. 4k.
 
Also, the “clean” flag is not set in your file system, which probably means that the stick was forcibly removed without unmounting it first. You need to fsck(8) the file system before you can use it.
 
Indeed something is not right with the information returned by file -s

This is the usb stick for info
Code: 
root@NomadBSD:~ # diskinfo -v da1
da1
    512             # sectorsize
    8019509248      # mediasize in bytes (7.5G)
    15663104        # mediasize in sectors
    0               # stripesize
    0               # stripeoffset
    974             # Cylinders according to firmware.
    255             # Heads according to firmware.
    63              # Sectors according to firmware.
    Corsair Voyager    # Disk descr.
    AA00000000000613    # Disk ident.
    No              # TRIM/UNMAP support
    Unknown         # Rotation rate in RPM
    Not_Zoned       # Zone Mode

I'm at a loss and I don't know what else to try.
It there any way to access some data on this stick?
 
You could try some file recovery tools. But searching for a file that contains 64 random bytes (the key) is like searching for a needle in a haystack. I know, I once reinstalled one of my machines and forgot to backup the geli key for an external disk. Never found it and the data on the 2TB external disk was therefor lost forever. Encryption is cool, it can certainly protect your data, but you're totally screwed if you lose the key. I assume nobody ever thought of backing up those keys?

It might be a bit of a long shot but you could try booting a VM with the image of that stick. Maybe, just maybe, you can get it to boot if there's still enough data left on it. But you already tried booting the stick on other hardware, so I'm not sure a VM will change anything.
 
I tried with magicrescue, but I need to mount the key for this and it's suited for specific files like images or word documents, not for a geli key.

Next time I'll make sure to get a backup of the key or most probably only use a passphrase.
Thank you all for your support.
 
oneev said:
I tried with magicrescue,
Click to expand...
You could try sysutils/testdisk. You're still working on the image(s) you created from that stick. So test as much as possible on those images.

oneev said:
it's suited for specific files like images or word documents, not for a geli key.
Click to expand...
Yeah, most of these recovery tools look for that magic(5) number at the start of a file. A geli key doesn't have one, as it's just a bunch of random bytes.
 
RTFM gpart(8) tells:
  • BOOTSTRAPPING
    [...]A BSD disklabel is usually created inside an MBR partition (slice) with type freebsd (see the PARTITION TYPES section). It uses 8 KB size bootstrap code image /boot/boot, embedded into the partition table's metadata area. [...]
/boot/boot{0,1}: 1/2 kB each, /boot/boot2: 7,5 kB. You did dd ... -iseek=63 ... which is 32.5 kB. Am I wrong here?
 
Mjölnir said:
RTFM gpart(8) tells:
  • BOOTSTRAPPING
    [...]A BSD disklabel is usually created inside an MBR partition (slice) with type freebsd (see the PARTITION TYPES section). It uses 8 KB size bootstrap code image /boot/boot, embedded into the partition table's metadata area. [...]
/boot/boot{0,1}: 1/2 kB each, /boot/boot2: 7,5 kB. You did dd ... -iseek=63 ... which is 32.5 kB. Am I wrong here?
Click to expand...
That depends. 63 sectors is what fdisk reserves for the MBR partition-table (although it usually occupies only one sector), in order to have the next partition start on a new track (traditionally a track was 63 sectors max on ST506). So the 63 would be the case when we have an MSDOS-style MBR and fdisk (and partitions da0s1, da0s2, ...).

For BSD, traditionally a disklabel would then be placed inside a single MSDOS partition (so we get partitions da0s1a, da0s1b, ...), and the first of these partitions is typically 16 sectors off the MSDOS partition (aka slice). So here is where the 8k appear. (There is rumour that one would not need to keep these 16 sectors free, because UFS does not use them anyway. I don't know if that is true, but I'm quite certain I forgot to insert this offset occasionally and did not run into problems.)
The actual filesystem would then start 79 sectors off (or 80, if somebody tried to accomodate for 512e).

In contrast, the "dangerously dedicated" mode means to put the disklabel directly at the beginning of the disk and not use a MSDOS MBR+fdisk at all. Then you get a disk with partitions similar to SunOS (da0a, da0b, ...), and MSDOS will not understand that disk. And the first filesystem would usually begin at sector 16.

An finally, you could also throw a filesystem directly onto the whole disk - but then there can be only one filesystem.
 
Ok, for everybody who is interested in some technical stuff … ;)

Historically, UFS reserved 8 KB at the beginning for bootstrap code. This is why /boot/boot is 8 KB in size – basically it is a concatenation /boot/boot1 (0.5 KB, this is the MBR with 1st-stage boot code) and /boot/boot2 (7.5 KB, 2nd-stage boot code). The first sector of boot2 is used for the BSD label (partition table) if present. In other words, UFS reserves enough space at the beginning for everything needed to bootstrap FreeBSD in “dangerously dedicated” mode. However, this is only guaranteed to work for removable media (floppy disks, or other media in floppy emulation mode). Whether this works with fixed disks depends on the BIOS implementation.

UFS2 even went ahead and increased the reserved size to 64 KB, thus enabling more complex bootstrap code to be used. FreeBSD doesn’t make use of this, though. Modern UEFI-based systems have ample space in the ESP anyway, so it’s not necessary to cram boot code in a small number of sectors (see the uefi(8) manual page).

It is important to realize that the space that is reserved for bootstrap code counts as part of the actual file system. That is, block addresses of the file system are relative to the start of the partition (i.e. relative to the start of the whole storage medium if it is “dangerously dedicated”), not relative to the superblock. That’s why cutting off a number of blocks from the start will not help, and in fact will break things.

By the way, FreeBSD’s UFS2 driver checks for the superblock at offsets 0 KB, 8 KB, 64 KB and even 256 KB, so it works with all kinds of bootstrap sizes. You can read about all of this in the fs(5) manual page, and in the extensive comments contained in /usr/include/ufs/ffs/fs.h.

One final note: “Dangerously dedicated” means there is no fdisk slice table (there may be a BSD label a.k.a. BSD partition table, though). This mode should only be used on media that are not supposed to be bootable, and on removable media (bootable or not). Historically it was used for floppy disks because the standard PC BIOS did not expect floppies to contain fdisk slices. Conversely, when booting from a hard disk, the BIOS usually expects a valid fdisk slice table to be present, and this may fail for “dangerously dedicated” disks because they only contain a fake slice entry. FreeBSD’s boot1 code checks if it was booted from a removable medium (floppy disk, or floppy emulation) – in this case it simply loads the whole 8 KB (boot2) from the same medium and continues to boot from there. If it was booted from fixed media (internal hard disk or SSD), it searches for the first slice marked “active”. If there is none, it falls back to the first slice of type “FreeBSD”. If there is none either, it fails. The boot1 code contains a fake fdisk slice entry that basically covers the whole disk, so it can bootstrap itself, but this may not be sufficient for BIOS booting – it might work on one PC, but it might fail if the same disk is put in a different PC (been there, done that). Another reason why this is called “dangerous” is the fact that other operating systems won’t recognize the disk at all, assuming it is empty, and thus they might mangle the MBR, rendering FreeBSD unbootable.

Of course, on modern PCs that boot via UEFI, all of that is a non-issue. FreeBSD stopped supporting the creation of “dangerously dedicated” disk layouts at 8.0-release, i.e. you cannot do this with gpart(8). There are other ways to do it, though, but this isn’t officially supported, and I don’t think there are any valid reasons why you would want to do that. But, of course, you can still put a file system directly on a USB stick, without creating any kind of partitions first. Such a stick will work perfectly fine for data exchange.
 
I tried to generate dd images with iseek=1 from 1 to 20 to well… try all possibilities. To no avail. I understand better thanks to the interesting explanation by olli@.

I also tried testdisk without success so far.

It’s simply frustrating to explore the image with an hexeditor and find plenty of text data, but without the possibility to locate the precious 64 bytes file.

I am thankful for your help and any suggestion.
 
Mjölnir said:
So what should the OP do?
Click to expand...
Not sure … Somehow the file system seems to be broken, but I don’t know in what way.
 
oneev: Have you already tried to fsck the image? (Don’t try this on the original stick, always work with an image copy.)
If that doesn’t work: Can you run dumpfs(8) on the image? Beware, the output can be large. The most interesting information is in the first 20 lines or so (up to the first empty line that separates the information of the cylinder groups). If that works, please let us know those 20 lines.
 
Just an example how such an output looks like:
Code: 
magic   19540119 (UFS2) time    Fri Jan 29 11:27:49 2021
superblock location     65536   id      [ 5ee63c50 7101c23b ]
ncg     6       size    1310720 blocks  1305415
bsize   32768   shift   15      mask    0xffff8000
fsize   4096    shift   12      mask    0xfffff000
frag    8       shift   3       fsbtodb 3
minfree 8%      optim   time    symlinklen 120
maxbsize 32768  maxbpg  4096    maxcontig 4     contigsumsize 4
nbfree  156938  ndir    102     nifree  81098   nffree  186
bpg     27416   fpg     219328  ipg     13824   unrefs  0
nindir  4096    inopb   128     maxfilesize     2252349704110079
sbsize  4096    cgsize  32768   csaddr  904     cssize  4096
sblkno  24      cblkno  32      iblkno  40      dblkno  904
cgrotor 0       fmod    0       ronly   0       clean   0
metaspace 8768  avgfpdir 64     avgfilesize 16384
flags   soft-updates trim
check hashes    cylinder-groups
If that doesn’t work either, I would go back one step and start looking at the image with hd(1) (hexdump). The UFS1 superblock has the “magic“ signature 0x19540119 at offset 0x55c. With the usual reserved size of 64 K, that should be at 0x1055c:
Code: 
$ dd if=<your_image> count=131 status=none | hd -s 0x1055c -n 4
0001055c  19 01 54 19                                       |..T.|
If those four bytes are not there, I would try to look for the superblock at other offsets. If they’re there, I would start examining the contents of the superblock and look for invalid values, and maybe trying to modify them until fsck is able to pick the whole thing up. Of course, this is tedious and time-consuming, and requires some knowledge of the data structures. The aforementioned include file <ufs/ffs/fs.h> can help (some familiarity with C code is helpful here).

I also seem to remember that there are recovery tools that might help somewhat. For example, there’s a tool that can be used to locate superblocks (or alternative superblocks) on broken file systems. Unfortunately I don’t remember its name.
 
sysctl -n kern.cam.{a,}da.retry_count
sysctl kern.cam.{a,}da.retry_count=0
recoverdisk -w usb0.writelist.txt /dev/da0 usb0.img
Press CTRL+C
recoverdisk -r usb0.writelist.txt -w usb0.writelist.txt /dev/da0 usb0.img
sysctl kern.cam.{a,}da.retry_count=4 (restore previous value; replace 4 with what you had)
fsck /dev/`mdconfig -o readonly usb0.img`
 
You must log in or register to reply here.
Back
Top