Dangerously Dedicated

I have an old server running 7.x, and I am upgrading it. I know some of the drives are "dangerously dedicated", but I am not sure which ones. How can I check?
 
Dangerously dedicated means there are no MBR/BIOS partitions (i.e. BSD slices).
BSD labels are usually written within BSD slices, but in the case of a DD disk, the slices are replaced with BSD labels.

Check the output of % ls /dev/ad*. If the disk is DD, then you should see devices such as e.g. ad0a. Otherwise you should see e.g. ad0s1a.
 
I don't have a dangerously dedicated disk but try this commands too:

# gpart show
# gpart status
# gpart list |grep '^[1-9]'
 
To expand on that, if using gpart(8)'s show command on a whole disk shows BSD, it is "dangerously dedicated".
Code:
=>       0  39070080  ad0  [color="Red"]BSD[/color]  (18G)
         0   4194304    1  freebsd-ufs  (2.0G)
   4194304   1048576    2  freebsd-swap  (512M)
   5242880   2097152    4  freebsd-ufs  (1.0G)
   7340032    524288    5  freebsd-ufs  (256M)
   7864320  31205752    6  freebsd-ufs  (14G)
  39070072         8       - free -  (4.0k)

Another way to tell is that the partition letters come right after the drive device name. For example, in /etc/fstab, the entries would be like ad0a rather than ad0s1a.
 
Code:
# gpart show
# gpart status
# gpart list |grep '^[1-9]'
Those give no output. :-(

The main drive I am concerned about is /dev/ad12, ls lists: /dev/ad12 /dev/ad12c /dev/ad12d. So since there is no s1 at the end of it, it is dangerously dedicated?
 
Fozzy said:
The main drive I am concerned about is /dev/ad12, ls lists: /dev/ad12 /dev/ad12c /dev/ad12d. So since there is no s1 at the end of it, it is dangerously dedicated?
Yep, that's the one.
 
Back up, repartition and restore just in case. The dangerously dedicated disks should still work on 9.0 or 9.1 but better safe than sorry.
 
As far as I'm aware, the "dangerous" in dangerously dedicated only refers to the possibility of a Microsoft OS failing to recognise that the disk contains data and trampling all over it.

If the disk is used in a system exclusively running FreeBSD, then there should be nothing dangerous about a directly bsdlabelled disk.


However, some systems might have a quirky BIOS that checks for the existence of an active-flagged MBR partition before they consider a drive bootable. You might have problems booting from a bsdlabelled disk on such a system. I've not encountered this problem with any of the systems I've used.

(Strictly speaking, the BIOS shouldn't concern itself with checking for partitions. It should just load and run the code in sector 0 and let that code decide what to do.)
 
There is an MBR with a proper slice table and with an active slice on a dangerously dedicated disk. It's the first 512 bytes of the /boot/boot loader that gets written on the first 16 sectors instead of /boot/mbr. The slice table is a bogus one however containing only one slice that covers the rest of the disk.

How GEOM can tell apart a dangerously dedicated disk from a regular MBR partitioned one I haven't figured out yet...
 
I used to have a dangerously dedicated layout on my old server before I replaced the hardware. One thing to note is that going from a certain major version to another one I found that the device names changed. I can't remember which version it actually was, but on one of them the disk device driver code was changed and this caused a different device to appear in /dev. When the system booted it said it couldn't find the root disk and I had to manually point it to the correct place and then alter the /etc/fstab.

Since I bought new hardware I installed 9.1 as a fresh installation and instead used proper GPT partitioning and GPT labels to mount the drives which clearly is a much better way to do it.
 
kpa said:
There is an MBR with a proper slice table and with an active slice on a dangerously dedicated disk. It's the first 512 bytes of the /boot/boot loader that gets written on the first 16 sectors instead of /boot/mbr. The slice table is a bogus one however containing only one slice that covers the rest of the disk.

How GEOM can tell apart a dangerously dedicated disk from a regular MBR partitioned one I haven't figured out yet...

I decided to put this to the test, but got confusing results.

I created a md() device and used gpart() to create a BSD partition scheme on it:
Code:
root@beastie:/root # gpart show md0
=>     0  262144  md0  BSD  (128M)
       0  262144       - free -  (128M)

fdisk() also showed an MBR partition table with a single device-spanning partition:

Code:
root@beastie:/root # fdisk md0
******* Working on device /dev/md0 *******
...
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 256977 (125 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 15/ 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>

But, if I dump the first 512 bytes of the device, they're all zero:

root@beastie:/root # od -N 512 /dev/md0
0000000 000000 000000 000000 000000 000000 000000 000000 000000
*
0001000

Where is fdisk() getting the partition information from?!
 
Keep in mind that "dangerously dedicated" disks aren't supported anymore since 8.0. It'll still work but I'm not sure the tools allow you to create them anymore.
 
Oh, ok. Look at the last 66 bytes of the first 512 byte block of the disk, the slice table is located there.

Edit: It turns out that fdisk(8) shows a "default" layout even if there's no MBR partition table on the disk, confusing...

In case of BSD partition scheme the first 8192 bytes of the disk are significant. They contain the BSD label (partition information) and the /boot/boot code if the disk is bootable. There's a kind of a double layering in the /boot/boot boot block, the first 512 bytes of it are in fact a standard MBR with a proper slice table with a single slice that covers the whole disk and boot code that loads the rest of the 8192 bytes of the /boot/boot code.

If you create just a BSD labeled disk without bootblocks the first 8192 bytes will be mostly zeros except for the partition information. The MBR part will be also just zeros since nothing has been written to it yet.

I still haven't figured out how GEOM can tell apart a dangerously dedicated disk and a standard MBR+bsdlabel(8)'ed disk. Anyone got ideas?
 
Keep in mind that "dangerously dedicated" disks aren't supported anymore since 8.0. It'll still work but I'm not sure the tools allow you to create them anymore.

Apparently the tools still do allow you to create them, and apparently I rushed my last install.

Code:
:/etc # less fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0a      /               ufs     rw      1       1
/dev/ada0b      none            swap    sw      0       0
proc            /proc           procfs  rw      0       0

:/dev # ls ad*
ada0 ada0a ada0b ada1 ada1p1

11.1-RELEASE-p4

Might have been a couple too many dark rum's. :D Will have to re-do this machine again I spose. :oops:
 
Back
Top