# can't mount Dangerously Dedicated USB stick



## oneev (Feb 1, 2021)

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.


```
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)



```
# 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


----------



## SirDice (Feb 1, 2021)

It's probably `mount /dev/md1s1a /mnt`.

Please stop using fdisk(8), use gpart(8) instead.


----------



## olli@ (Feb 1, 2021)

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.


----------



## oneev (Feb 1, 2021)

The gpart is empty, hens the fdisk

```
# gpart show /dev/md1
gpart: No such geom: /dev/md1.
```
And here the listing of the md image and actual stick

```
# 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)


----------



## Mjölnir (Feb 1, 2021)

Before mounting, do `fsck /dev/da1`.
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.
Parameters of dd(1)?
You can also verify that another imagefile copied with recoverdisk(1) is identical to your image.img


----------



## olli@ (Feb 1, 2021)

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.


----------



## SirDice (Feb 1, 2021)

oneev said:


> The gpart is empty, hence the fdisk


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`),


----------



## oneev (Feb 1, 2021)

I recreated the md device.
But mount reacts as if the device does not exist. Same result with the stick itself

```
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:

```
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)

```
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


----------



## SirDice (Feb 1, 2021)

Just for testing I created a bogus image file and it just mounts as expected:

```
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.


----------



## Mjölnir (Feb 1, 2021)

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.


----------



## oneev (Feb 1, 2021)

This could be the decisive lead.


```
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

```
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?


----------



## oneev (Feb 1, 2021)

Here my naive test:


```
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?


----------



## olli@ (Feb 1, 2021)

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:
 

```
# 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:
 

```
/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.


----------



## oneev (Feb 2, 2021)

Indeed something is not right with the information returned by file -s

This is the usb stick for info

```
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?


----------



## SirDice (Feb 2, 2021)

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.


----------



## oneev (Feb 2, 2021)

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.


----------



## SirDice (Feb 2, 2021)

oneev said:


> I tried with magicrescue,


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.


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.


----------



## Mjölnir (Feb 2, 2021)

RTFM gpart(8) tells:

BOOTSTRAPPING
[...]A BSD disklabel is usually created inside an MBR partition (slice) with type freebsd (see the PARTITION TYPES section).  I*t 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?


----------



## PMc (Feb 3, 2021)

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). I*t 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?


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.


----------



## olli@ (Feb 3, 2021)

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.


----------



## Mjölnir (Feb 3, 2021)

So what should the OP do?


----------



## oneev (Feb 3, 2021)

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.


----------



## olli@ (Feb 3, 2021)

Mjölnir said:


> So what should the OP do?


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:

```
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:

```
$ 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.


----------



## Mjölnir (Feb 3, 2021)

`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``


----------



## olli@ (Feb 3, 2021)

Mjölnir said:


> `recoverdisk ...`


Why do you suggest recoverdisk? Does the USB stick have read errors? If so, I think I have missed that information in this thread.


----------



## Mjölnir (Feb 3, 2021)

According to your explanation above, the UFS (either V1 or 2) filesystem starts at the beginning of the device, but reserves space for the boot blocks.  I.e. when copying the device, no blocks must be skipped; fsck(8) will know that it has to skip the 1st blocks because they are reserved for the boot blocks and are not used by the filesystem anyway.  FreeBSD 7 has UFS2 already, correct?  I guess that the OP did not skip any block on the initial copy (with dd(1)?).  That's why I suggest to copy with recoverdisk(1) instead; because it seems there might have been something going wrong when copying.  I recommended to check that the image is ok (verify img(dd) == img(recoverdisk)); but the OP did not reply...  I recommended to fsck(8) the device & the image before mounting, but the OP did not reply...


----------



## oneev (Feb 3, 2021)

I used recoverdisk a few times to create an image using different options. I ended up with the same image. I checked in all cases and the images are identical to the original one. So I am confident that my image is identical to the USB stick.

I did the procedure suggested by Mjölnir and I get the same message:


```
root@NomadBSD:/data # fsck /dev/md2
Can't open /dev/md2: No such file or directory
```

Unfortunately fsck does not let me access the device neither if I use the full image

```
root@NomadBSD:~ # fsck /dev/md1
Can't open /dev/md1: No such file or directory
```

(and same result with fsck /dev/da1)
Alas I get the same error with dumpfs


```
root@NomadBSD:~ # dumpfs /dev/md1
dumpfs: /dev/md1: No such file or directory
```

I get this searching for the offset 0x1055c:

```
root@NomadBSD:/data # dd if=lttleowl.img count=131 status=none | hd -s 0x1055c -n 4
0001055c  00 00 00 00                                       |....|
00010560
```
So it appears those those four bytes are not there. What other offsets should I try besides 0x1055c?


----------



## Mjölnir (Feb 4, 2021)

Please look for `ls -ltr /dev/md*`.  Please post the output of `freebsd-version` and `uname -a`.  Are you doing this inside a virtual machine?

mdconfig(8) automagically uses a fresh number for it's devices: /dev/md0, /dev/md1, ....  Please do exactly the command: `fsck /dev/`mdconfig  -f lttleowl.img``  When finished with all work, release the memory device: `mdconfig -lf lttleowl.img` shows all md devices backed by that file, `-lv` lists all.  `mdconfig -du N` releases md device #N.


----------



## oneev (Feb 4, 2021)

Here the commands:


```
root@NomadBSD:/data # ls -ltr /dev/md*
crw-rw----  1 root  operator   0xb Jan 31 18:43 /dev/mdctl
crw-rw----  1 root  operator  0xb6 Jan 31 18:43 /dev/md0
crw-rw----  1 root  operator  0xb9 Jan 31 18:43 /dev/md0.uzip
crw-rw----  1 root  operator  0xc3 Feb  2 19:47 /dev/md1
root@NomadBSD:/data # mdconfig -lv
md0    vnode     1981M    /uzip/usr.local.uzip   
md1    vnode     7648M    /data/lttleowl.img
root@NomadBSD:/data # freebsd-version
12.2-RELEASE-p2
root@NomadBSD:/data # uname -a
FreeBSD NomadBSD 12.2-RELEASE-p2 FreeBSD 12.2-RELEASE-p2 r369076 NOMADBSD  i386
```
I am using Nomad BSD on an other USB stick as I can't wipe the disk on this test PC. My goal is to install FreeBSD 8 for further tests. Could this make a difference? But I need to save the data on this disk before.

```
root@NomadBSD:/data # fsck /dev/`mdconfig -f lttleowl.img`
Can't open /dev/md2: No such file or directory
root@NomadBSD:/data # mdconfig -lf lttleowl.img
md1 md2 
root@NomadBSD:/data # mdconfig -lv
md0    vnode     1981M    /uzip/usr.local.uzip    
md1    vnode     7648M    /data/lttleowl.img    
md2    vnode     7648M    /data/lttleowl.img    
root@NomadBSD:/data # mdconfig -du 2
```


----------



## olli@ (Feb 4, 2021)

The error code ENOENT (“No such file or directory”) comes from the function `ffs_sbget` in /sys/ufs/ffs/ffs_subr.c, and it means that no usable known superblock was found. Mount, fsck and dumpfs _all_ use that function (via libufs(3)), so they all fail in the same way.
 
And this confirms that there is no superblock at the usual location, so this explains why you get “No such file or directory”:


oneev said:


> I get this searching for the offset 0x1055c:
> 
> ```
> root@NomadBSD:/data # dd if=lttleowl.img count=131 status=none | hd -s 0x1055c -n 4
> ...


 
The following shell command will search the whole image for the “magic” signature of UFS2 superblocks:

```
hd lttleowl.img | awk '$1 ~ /50$/ && /19 01 54 19/ {print (("0x" $1) - 1360) / 512}'
```
It might run for a while if the image is large. It might also produce long output, because the superblock is replicated in every cylinder group.
This is a sample output for a small UFS2 image (100 MB) that has four cylinder groups, so you have a total of five superblocks:

```
128
192
51456
102720
153984
```
Then run fsck_ufs(8) with the `-b` option and provide the block number of one of the superblock locations that you have found, for example:

```
fsck_ufs -b 128 /dev/md1
```
Good luck!


----------



## oneev (Feb 4, 2021)

Interesting. Here is what I get. It does take long time to run indeed. 

```
root@NomadBSD:/data # hd lttleowl.img | awk '$1 ~ /50$/ && /19 01 54 19/ {print (("0x" $1) - 1360) / 512}'
31
66
80
95
144
162
176
191
223
12095
317315
317316
317388
317535
376479
752735
1128991
1505247
1881503
2257759
2634015
```

Unfortunately fsck has the same problem as before

```
root@NomadBSD:/data # fsck_ufs -b 31 /dev/md1
Alternate super block location: 31
Can't open /dev/md1: No such file or directory
```
I tried all values from above, including +- 1.

I tried to take a chunk of 100Mb of the USB I'm now booted on (/dev/da0)

```
root@NomadBSD:/data # dd if=/dev/da0 of=/mnt/da0.img bs=512 count=200000
200000+0 records in
200000+0 records out
102400000 bytes transferred in 154.870278 secs (661199 bytes/sec)
root@NomadBSD:/data # hd /mnt/da0.img | awk '$1 ~ /50$/ && /19 01 54 19/ {print (("0x" $1) - 1360) / 512}'
```
Doesn't return anything. I'm might be doing something wrong.


----------



## olli@ (Feb 4, 2021)

oneev said:


> […]
> Doesn't return anything. I'm might be doing something wrong.


Uhm. Very strange. I have to admit that I have no idea what might be wrong there.


----------



## Mjölnir (Feb 4, 2021)

oneev  Insert the stick and try fsck'ing the device in _readonly_ mode & debug messages: `fsck_ufs -dnR /dev/daN` (replace `N` with the # of the device, usually 0 if that's the only USB mass storage device).


----------



## oneev (Feb 4, 2021)

I get the following. I tried also a few other potential super block positions

```
root@NomadBSD:/data # fsck_ufs -dnR /dev/da1
Can't open /dev/da1: No such file or directory
root@NomadBSD:/data # fsck_ufs -b 31 -dnR /dev/da1
Alternate super block location: 31
Can't open /dev/da1: No such file or directory
root@NomadBSD:/data # fsck_ufs -b 66 -dnR /dev/da1
Alternate super block location: 66
Can't open /dev/da1: No such file or directory
root@NomadBSD:/data # fsck_ufs -b 317316 -dnR /dev/da1
Alternate super block location: 317316
Can't open /dev/da1: No such file or directory
root@NomadBSD:/data # fsck_ufs -b 30 -dnR /dev/da1
Alternate super block location: 30
Can't open /dev/da1: No such file or directory
root@NomadBSD:/data # fsck_ufs -b 32 -dnR /dev/da1
Alternate super block location: 32
Can't open /dev/da1: No such file or directory
root@NomadBSD:/data #
```


----------



## Crivens (Feb 4, 2021)

Check if the device is actually created. This looks like da1 is not created at all.


----------



## olli@ (Feb 4, 2021)

Crivens said:


> Check if the device is actually created. This looks like da1 is not created at all.


It is. As he explained above, he can run ls(1), file(1) and dd(1) on it.
The error message comes from the `ffs_sbget` function in /sys/ufs/ffs/ffs_subr.c which is used by mount, fsck and dumpfs.
See my post above for all the details.


----------



## Crivens (Feb 4, 2021)

Sorry, I skipped some of the thread.

One really stupid reason might be - is it actually the stick wanted or maybe it's the same make/color? 

And remember, you don't look behind bushes you didn't hide behind before yourself.


----------



## oneev (Feb 4, 2021)

Yes those bloopers happen. Not this time though. I'm positive.
It was happily running till last week. I don't know what caused all the corruption. I know one should not use a usb stick to run an operating system; however, to alleviate this problem I mounted /tmp and /var in memory and disabled swap. The installation was minimalist and ran only a few services. So I don't think the stick was damaged by read/write wear.
Last week the hardware crashed a multiple times and rebooted without issue (this board has a known bug that creates rare random crashes during prolonged IO). It always booted fine and I never had errors with fsck on the disks. I think I had soft updates activated on the stick.
But now something is wrong with the mainboard and it doesn't reach the bios and doesn't boot anymore.
Maybe the last crash created corruptions on the stick. Or the multiple crashes in a short time lead to the corruption.


----------



## Crivens (Feb 4, 2021)

I lost one stick to overheating. That might be it. Or not. :/


----------



## Mjölnir (Feb 4, 2021)

oneev said:


> [...] I know one should not use a usb stick to run an operating system; however, to alleviate this problem I mounted /tmp and /var in memory and disabled swap. The installation was minimalist and ran only a few services. So I don't think the stick was damaged by read/write wear. [...]


Well, _in theory_ these precautionary measures should be sufficient, but unfortunately in practice many (most?) software is poorly written, in that it doen't respect the suggested path's (hier(7)).  Plus, either the maintainers are too busy or too lazy to fix the ports(7)' poor defaults -- that can be very time consuming -- or some ports don't even have a maintainer and thus are built with the poor & "wrong" default settings.  You can easily prove the effect by mounting the / root filesystem (by default including /usr & /usr/local) readonly.  Many/most ports(7) will not run as expected... i.e. many do heavily write to /usr/local.

This means your USB stick might very well be worn out after a few years, even when the OS was only run occasionally.  If you want to run an OS from an USB stick, you must mount it _read-only_, and only remount _read-write_ when updating the configuration files or packages/ports/OS.  You can produce a long list of bug reports by doing this...


----------



## Deleted member 66267 (Feb 5, 2021)

Don't blame me please I'm just trying to help.

Please try to mount your image on a live Linux system. Just grab the most popular one, currently MX Linux.

Linux has some magics I don't know it could mount almost all variant of UFS from any BSDs albeit just read-only.

This is the last resort I usually try and always success before I go for all ZFS.

You could find tutorials about how to mount disk image on Linux easily, they are plenty on the internet.

Hope it helps.


----------



## olli@ (Feb 5, 2021)

Given the information about the stick, I think it is likely that it is worn out.

The controllers of flash media implement so-called wear-leveling algorithms that aim to distribute the wear evenly across the flash cells, even if some blocks are overwritten much more often than others. Different brands of media have different quality of wear-leveling algorithms, but usually USB sticks are inferior to SSDs. Another problem is that – unlike SSDs – most USB sticks don’t support SMART, so you cannot look at the current wear status and expected remaining flash life.

I managed to wear out several high-quality USB sticks within just a few weeks by using them with an appliance that seems to have the bad habit of overwriting the same sector every few seconds. Finally I switched to using an external USB SSD (a Samsung T5), and it is now happily running for two years 24/7.

*Most importantly:* If you put valuable data on _any_ medium (flash stick, hard disk, SSD, whatever), be sure to have a backup copy somewhere.


----------



## oneev (Feb 11, 2021)

As suggested by _failure_ I tried mounting the stick from Linux.... and it WORKED!
I tried with an offset of 32256 (63 x 512).
Here the command I used:

```
mount -r -t ufs -o ufstype=ufs2,offset=32256 /dev/sdc /mnt
```
And it mounted fine.
I was able to get the precious 64 byte geli key and now I'm retrieving the data from the encrypted disks.

I then tried again on FreeBSD to use the same offset. However I don’t know how to set an offset to mount or mdconfig. So I created a new dd image with iseek=32256

And I could then mount the image:

```
root@NomadBSD:/mnt2 # dd if=image.dd of=test.img bs=512 iseek=63
15663041+0 records in
15663041+0 records out
8019476992 bytes transferred in 493.758550 secs (16241697 bytes/sec)
root@NomadBSD:/mnt2 # mdconfig -a -t vnode -f test.img -u 1
root@NomadBSD:/mnt2 # fsck_ufs /dev/md1
** /dev/md1

SAVE DATA TO FIND ALTERNATE SUPERBLOCKS? [yn] y

ADD CYLINDER GROUP CHECK-HASH PROTECTION? [yn] y

** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=212161  OWNER=root MODE=100640
SIZE=63 MTIME=Jan 28 01:00 2021 
CLEAR? [yn] y

UNREF FILE I=212162  OWNER=root MODE=100644
SIZE=3741214 MTIME=Jan 28 12:42 2021 
CLEAR? [yn] y

LINK COUNT FILE I=235541  OWNER=operator MODE=100400
SIZE=4096 MTIME=Jan 29 10:22 2021  COUNT 2 SHOULD BE 1
ADJUST? [yn] y

UNREF FILE  I=239044  OWNER=operator MODE=100400
SIZE=4096 MTIME=Jan 29 10:55 2021 
RECONNECT? [yn] y

SORRY. NO SPACE IN lost+found DIRECTORY
UNEXPECTED SOFT UPDATE INCONSISTENCY
CLEAR? [yn] y

UNREF FILE  I=240981  OWNER=operator MODE=100400
SIZE=0 MTIME=Jan 29 10:55 2021 
RECONNECT? [yn] y

SORRY. NO SPACE IN lost+found DIRECTORY
UNEXPECTED SOFT UPDATE INCONSISTENCY
CLEAR? [yn] y

LINK COUNT FILE I=247301  OWNER=operator MODE=100400
SIZE=4096 MTIME=Jan 29 09:44 2021  COUNT 2 SHOULD BE 1
ADJUST? [yn] y

LINK COUNT FILE I=247312  OWNER=operator MODE=100400
SIZE=4096 MTIME=Jan 29 09:55 2021  COUNT 2 SHOULD BE 1
ADJUST? [yn] y

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK

SALVAGE? [yn] y

346266 files, 2296025 used, 1495363 free (13883 frags, 185185 blocks, 0.4% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****
root@NomadBSD:/mnt2 #
```
No partition found. But I can mount it fine.


```
root@NomadBSD:/mnt2 # gpart show /dev/md1
gpart: No such geom: /dev/md1.
root@NomadBSD:/mnt2 # file -s /dev/md1
/dev/md1: Unix Fast File system [v2] (little-endian) last mounted on /, last written at Thu Feb 11 13:29:14 2021, clean flag 1, readonly flag 0, number of blocks 3915749, number of data blocks 3791388, number of cylinder groups 42, block size 16384, fragment size 2048, 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@NomadBSD:/mnt2 # mount /dev/md1 /mnt3
root@NomadBSD:/mnt3 # ls /mnt3
.cshrc        .snap         bin           dev           etc           libexec       mnt           proc          sbin          tmp
.profile      COPYRIGHT     boot          dhclient.core home          lost+found    net           rescue        sleepyowl     usr
.rnd          backup        compat        entropy       lib           media         private       root          sys           var
root@NomadBSD:/mnt3 # 
root@NomadBSD:/mnt3 # ll root/gelikey 
-rw-------  1 root  wheel  64 Apr 23  2011 root/gelikey
root@NomadBSD:/mnt3 #
```
To be honest I still don’t know what went wrong or is wrong. To me the filesystem on the key seems file, at leat the data seems fine. gpart doesn’t see a partition.

So I’m very happy to have rescued my geli key to read the disks.
Yes in the future I’ll be more careful to backup root and in particular the geli key. However, I’ll only use a passphrase in the future, as the key it too risky for me.


olli@ I also use a Samsung T5, it’s great, but overkill for the minimal setup I had.


----------



## oneev (Feb 11, 2021)

I'd like to thank you all for the support and suggestions.


----------



## olli@ (Feb 11, 2021)

Good to hear that you were able to recover your data.

Apparently, there must have been a partitioning scheme on that stick at some point in the past (MBR and/or disklabel) that had one UFS partition starting at sector 63. That is, the stick was _not_ “dangerously dedicated” to begin with. But somehow, that partition scheme was lost, so GEOM (gpart) wasn’t able to recognize it anymore. Maybe a foreign OS tried to “repair” the stick.


----------



## Deleted member 66267 (Feb 12, 2021)

oneev said:


> As suggested by _failure_ I tried mounting the stick from Linux.... and it WORKED!
> I tried with an offset of 32256 (63 x 512).
> Here the command I used:
> 
> ...


Glad that it worked for you.


----------



## Deleted member 66267 (Feb 12, 2021)

olli@ said:


> Apparently, there must have been a partitioning scheme on that stick at some point in the past (MBR and/or disklabel) that had one UFS partition starting at sector 63. That is, the stick was _not_ “dangerously dedicated” to begin with. But somehow, that partition scheme was lost, so GEOM (gpart) wasn’t able to recognize it anymore. Maybe a foreign OS tried to “repair” the stick.


Maybe just running newfs on the whole device is better as it doesn't have any partitioning scheme, just the FS alone? Is it possible at all? Or the disk must be partitioned? Please correct me if my idea is wrong.


----------



## olli@ (Feb 12, 2021)

failure said:


> Maybe just running newfs on the whole device is better as it doesn't have any partitioning scheme, just the FS alone? Is it possible at all? Or the disk must be partitioned? Please correct me if my idea is wrong.


You can run newfs on _any_ raw device. So, yes, of course you can do that without partitions. Then it is like a huge floppy disk (those weren’t partitioned either). I explained that in another reply above.

However, such a stick will probably not be recognized by certain other operating systems. This can lead to damage.


----------

