# Dangerously dedicated support flushed?!



## aragon (Nov 26, 2009)

FreeBSD 8.0 Release Notes said:
			
		

> â€œdangerously dedicatedâ€ mode for the UFS file system is no longer supported.
> 
> Important: Such disks will need to be reformatted to work with this release.


I'm _really_ curious to know the motivation behind this.  I guess it is logical to assume that this means FreeBSD 6 and 7 boxes in the field have no chance of being upgraded to 8 if their boot disks are setup dedicated?

Surely this violates POLA?  Surely there was a less disruptive alternative?  Why the change?  Am I the only one cringing?


----------



## Beastie (Nov 27, 2009)

Yeah it came as a surprise to me too, but not for the same reason. I actually thought it had already been removed in 7.x. Apparently, I was imagining things, ahem. Or maybe I read about its removal in a future release somewhere. Or maybe it's prescience, hahaha.

Why are you upset? Did you use it?


----------



## aragon (Nov 27, 2009)

Beastie said:
			
		

> Why are you upset? Did you use it?


I did, yes.  Every single FreeBSD server I've setup was done so with a dedicated disk structure.


----------



## Arne (Nov 27, 2009)

Beastie said:
			
		

> Why are you upset? Did you use it?



There were many valid reasons to use it in the past and I'm not sure how many of them are still valid today (Disk encryption, huge concatenated disks with geom&friends, etc.)

Not to mention that there are some old guys around which have a strong feeling that a bsd disk label at the beginning of a disk is more "normal" than this strange fdisk partition table.

But of course, not everyone started his BSD experience working with a VAX.

So, what exactly is the problem with 8.0 and dangerously dedicated disks so that we can think about the next steps we have to do?

Regards
.//. Arne


----------



## jb_fvwm2 (Nov 27, 2009)

I wonder if that change has anything to do with a 
scarcity of /dev (for usb-mounted disks etc) (in _8)
entries that have bsd (type 165) slices on them unless
geom_bsd.ko geom_label.ko and geom_mbr.ko (one or more
of them) are loaded... (at least here, locally, two
seperate instances.  I've put them in /boot/loader.conf;
that process fixed one problem for someone in another
thread here...


----------



## SirDice (Nov 27, 2009)

aragon said:
			
		

> Surely this violates POLA?


POLA has nothing to do with it as it's completely irrelevant to users and their privileges.


----------



## graudeejs (Nov 27, 2009)

pardon, my ignorance, but what exactly was â€œdangerously dedicated UFS" ?


----------



## SirDice (Nov 27, 2009)

killasmurf86 said:
			
		

> pardon, my ignorance, but what exactly was â€œdangerously dedicated UFS" ?



A 'regular' slice starts at block 64, a dedicated at 0. If it starts at 0 tools like the old MS-DOS/Windows fdisk/partition editor will throw a fit and is quite likely to nuke your partition table in the process. When a slice starts at 64 Windows doesn't have a problem with it. It just marks it as an unknown partition.

With a dedicated disk there's no slices, so you will have partitions named ad0a, ad0b etc. instead of ad0s1a, ad0s1b etc.


----------



## graudeejs (Nov 27, 2009)

Ok, thanks


----------



## robbak (Nov 27, 2009)

SirDice said:
			
		

> POLA has nothing to do with it as it's completely irrelevant to users and their privileges.



I have no idea what the Principle Of Least Astonishment (POLA) has to do with users and their privileges. It certainly is relevant to the choice to stop supporting so called 'dangerously dedicated' mode. I've always been in favor of ditching that horrid fdisk kludge wherever possible.


----------



## mjb (Nov 27, 2009)

SirDice said:
			
		

> With a dedicated disk there's no slices, so you will have partitions named ad0a, ad0b etc. instead of ad0s1a, ad0s1b etc.



So am I safe with my unpartitioned+unlabelled mounts, as in:


```
# newfs /dev/da0
# mount /dev/da0 /blah

or

# gstripe label foo /dev/da0 /dev/da1
# newfs /dev/stripe/foo
# mount /dev/stripe/foo /bar
```

or do I need to start faffing around fdisk/bsdlabel'ing everything?


----------



## SirDice (Nov 27, 2009)

robbak said:
			
		

> I have no idea what the Principle Of Least Astonishment (POLA) has to do with users and their privileges. It certainly is relevant to the choice to stop supporting so called 'dangerously dedicated' mode. I've always been in favor of ditching that horrid fdisk kludge wherever possible.



http://en.wikipedia.org/wiki/Principle_of_least_privilege

More commenly known in the security field as POLA.


----------



## aragon (Nov 27, 2009)

SirDice said:
			
		

> POLA has nothing to do with it as it's completely irrelevant to users and their privileges.


You are mistaken.


----------



## SirDice (Nov 27, 2009)

aragon said:
			
		

> You are mistaken.


No, I'm not

It just means different things to different people. Since I have a security background POLA refers to Principle of Least Authority. I didn't even know the Principle of Least Astonishment :e


----------



## honk (Nov 28, 2009)

What has "dangerously dedicated mode" to do with a particular filesystem like UFS? How should I understand the Release Notes entry? Currently I have multiple setups like this:

1. gmirror with two disks
2. encrypted mirror using geli
3. bsdlabel partitions (no slices)

/dev/mirror/gm0
/dev/mirror/gm0.eli
/dev/mirror/gm0.elia
/dev/mirror/gm0.elib
/dev/mirror/gm0.elic
/dev/mirror/gm0.elid
/dev/mirror/gm0.elie

This does not work with 8.0? The disks are "dedicated" to FreeBSD and the purpose is _complete_ disk encryption.

cheers,
honk


----------



## jamie (Dec 2, 2009)

Errrm, they lie? :


```
23:58 (20) "rc.d" root@catflap# uname -a ; df -t ufs|grep -v '/dev/md'
FreeBSD catflap.bishopston.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun Nov 29 19:37:54 GMT 2009     [email]root@catflap.bishopston.net[/email]:/usr/obj/usr/src/sys/CATFLAP  i386
Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/ad0s1a    253678   203576    29808    87%    /
/dev/ad2d    10154158  7465492  1876334    80%    /misc
/dev/ad0s1d   2026030  1037190   826758    56%    /var
/dev/ad2e    15231278  1180712 12832064     8%    /var/log
/dev/ad0s1f    507630     2694   464326     1%    /var/tmp
/dev/ad0s1g  35539756 28938322  3758254    89%    /usr
/dev/ad0s1h  31254636 25576650  3177616    89%    /usr/users
/dev/ad2f    38143404 28302558  6789374    81%    /usr/jails
/dev/ad2a    10154158  7627238  1714588    82%    /usr/jails/clash.stockcupboard.com/tidybackup
/dev/ad0s1e   4058062   477148  3256270    13%    /usr/catflap/backups
```

Anyway, I hope this doesn't become true. For a start, I hate the fdisk hack, it's an extra layer that we don't need. All my machines are formatted without using fdisk/slices (the only reason ad0 above is like that is because it was installed by someone else)

If this does become reality, how are we to upgrade? Especially remote servers, where we don't have the luxury of loads of spare disks to offload stuff to.

*puzzled*


----------



## jb_fvwm2 (Dec 2, 2009)

Maybe the first post refers to initial install vs.
buildworld/installworld?  And maybe the the .ko I 
posted above enables upgrades to inadvertantly 
continue despite not being supported?  Guessing at 
each of them.


----------



## randi@ (Dec 2, 2009)

*die in a fire.*



			
				killasmurf86 said:
			
		

> pardon, my ignorance, but what exactly was â€œdangerously dedicated UFS" ?



OH MY GOD.

If I see one more person equate DD mode with UFS, I'm going to shoot someone. 

Do you know why I removed it? Because it was broken in 8. Simple as that. I could have kept the support in, but then you'd upgrade and all your crap would be broken and you'd be crying. Search the mailing list archives for a reason why this had to change. Specifically, juli and marcus gave some good explanations, I believe.

Sorry if I'm coming off grumpy, but apparently there are quite a few people that decided "I'm just going to ignore the warning sysinstall gave me about how this might be a bad idea. Dangerous sounds like fun!" and now they are ranting and raving. Production servers? Really? You thought this was a good idea?

STABSTABSTABSTABSTAB.


----------



## aragon (Dec 2, 2009)

randi said:
			
		

> Search the mailing list archives for a reason why this had to change.


Well I couldn't find it.  Care to enlighten us?



			
				randi said:
			
		

> apparently there are quite a few people that decided "I'm just going to ignore the warning sysinstall gave me about how this might be a bad idea. Dangerous sounds like fun!"


Ah yes, that sysinstall warning...


			
				src/usr.sbin/sysinstall/disks.c said:
			
		

> Do you want to do this with a true partition entry so as to remain cooperative with any future possible operating systems on the drive(s)? (See also the section about "dangerously dedicated" disks in the FreeBSD FAQ.)


Is this secretly trying to tell us that this is actually deprecated and "any future possible operating systems" includes FreeBSD itself too?  Let's just check that FAQ entry for clarification.  Ah, so it's called dangerous due to incompatibility with other operating systems.  Of course, it's just shining with the knowledge that this feature made by and for FreeBSD was not only dangerous for other operating systems, but endangered with deprecation and sudden extinction from FreeBSD support too.


----------



## chalbersma (Dec 2, 2009)

idk man I'd have heasitated at the idea of "dangerous"


----------



## jamie (Dec 2, 2009)

randi@ said:
			
		

> Dangerous sounds like fun!" and now they are ranting and raving. Production servers? Really? You thought this was a good idea?
> 
> STABSTABSTABSTABSTAB.



What? The only ever perceived 'danger' was that non-FreeBSD operating systems (including maybe boot cd's / floopies for diagnostics) would not recognise the disk as being in use, and may potentially mess up the boot block.

I never use any of these, and have always preferred to not use the 'DOS-hacks'.

Never was it implied that there was any stability risk other than this.

Yes, production servers! without the fdkisk/dos stuff - simply more pure, and one less level of spurious partitioning - a bit anal maybe, but not 'dangerous' - only 'dangerous' to the unenlightened who may not realise what they are doing when they pop in some dos-based floppy 'checkdisk' util on their home box.


----------



## honk (Dec 2, 2009)

randi@ said:
			
		

> If I see one more person equate DD mode with UFS, I'm going to shoot someone.



Should we shoot the Release Notes?



> 2.2.5 File Systems
> 
> â€œdangerously dedicatedâ€ mode *for the UFS file system* is no longer supported.
> 
> Important: Such disks will need to be reformatted to work with this release.



People only want to know what exactly is broken and unsupported now. Especially the people who (thought they) had valid reasons to uses DD mode, like Arne said or in my case where I boot from USB stick and have a completely encrypted disk like described above. Not everyone is using sysinstall. Just saying "search the mailing lists" doesn't help at the moment, as you find a lot of posts regarding this topic with questionable statements from users who just tried something and believe its good. Nobody want to have his data living in danger. So if there are already information's available based on competent knowledge, it would help if it could be posted here until Handbook, FAQ's etc. is up to date.

cheers,
honk


----------



## tvh (Dec 31, 2009)

For others, like me, with older disks created by the broken sysinstall dangerously dedicated mode, here is a link into the FreeBSD mail archives describing how to recover the partitions.

http://www.pubbs.net/freebsd/200912/39499/

Basically,

`dd if=/dev/zero of=/dev/ad# count=1 oseek=1`


----------



## Speedy (Dec 31, 2009)

> Do you know why I removed it? Because it was broken in 8. Simple as that.


I see. If something is broken one has choices. Fix it or toss it. "No longer supported" is loquacious indeed. What is next? Do we hear knell? I am one of those who has always used DD mode. With all the respect towards FOSS and all the hard work of developers, dropping features like this foretells dim future. 



> Yes, production servers! without the fdkisk/dos stuff - simply more pure, and one less level of spurious partitioning - a bit anal maybe, but not 'dangerous' - only 'dangerous' to the unenlightened who may not realise what they are doing when they pop in some dos-based floppy 'checkdisk' util on their home box.


++


----------



## aragon (Dec 31, 2009)

tvh said:
			
		

> For others, like me, with older disks created by the broken sysinstall dangerously dedicated mode, here is a link into the FreeBSD mail archives describing how to recover the partitions.


Thanks for the enlightenment.  If/when I pluck up the courage to test this on one of my remaining 7.x DD systems I'll report back on my experience.


----------



## tvh (Dec 31, 2009)

aragon said:
			
		

> Thanks for the enlightenment.  If/when I pluck up the courage to test this on one of my remaining 7.x DD systems I'll report back on my experience.



Making a backup copy of the sector that you are about to zero-out, prior to actually zeroing it out, should keep the experiment fairly safe.  I would've done that had I thought of it, but I was okay, anyways.    My excuse is that I could afford to be reckless, since I did have a backup copy if necessary.


----------



## zapher (Jan 4, 2010)

So as I understand it, FBSD 8 doesn't approve that I have both a MBR *AND* a disklabel? That would explain why it shows mirror/gm0a instead of mirror/gm0s1 as it prefers the disklabel partition scheme (which on my part is defunct).

So because that the MBR lies in sector 1, and I don't use the disklabel layout in sector 2 I could just # _dd if=/dev/zero of=/dev/mirror/gm0 oseek=1 count=1_ to have it write over sector (LBA) 2?

Or should I instead do this directly to one of my drives and have gmirror sync it over? 
# _dd if=/dev/zero of=/dev/ad6 oseek=1 count=1_

[copied here from http://forums.freebsd.org/showthread.php?t=9983 - mod]


----------



## zapher (Jan 4, 2010)

Awesome! Erasing my messed up disklabel (sector 2) solved it! Didn't even have to reboot.

*Total procedure:*
Make sure you have a backup in case you mess it up. This backs up both LBA (sector) 1 and 2 which holds the MBR and GPT/BSDlabel correspondingly.
`# dd if=/dev/daX of=boot.bak count=2`

Next, you want to skip the first LBA and write 512B of zeroes over the second LBA.
`# dd if=/dev/zero of=/dev/daX oseek=1 count=1`

Make sure daX is the *whole device*, not a slice or label (daXs1 etc).

Also, make sure you type in the dd-commands correct. Failing to do so can *destroy data*!

[copied here from http://forums.freebsd.org/showthread.php?t=9983 - mod]


----------



## zapher (Jan 4, 2010)

It all worked out well!

I made a copy of the first two sectors, when I wrote zeroes all over sector 2 since I was using my MBR. My slice popped back up in /dev/mirror and it named my partition gm0s1d (for some reason unknown to me) and I was able to mount the whole slice without a hickup!


----------



## robbob2112 (Jan 30, 2010)

Well, just went through the nosebleed process to get my system upgraded from a 'dangerously dedicated' 6.2 install to 8.0.

I understand why the 'dangerously dedicated was deleted and and onboard with it.. BUT it would have been really nice if the systinstall from the 8.0 image would have just warned me that there was a problem and maybe even given a meaningful error message verse rendering the existing install unbootable with an obscure message that took 20 minutes to track down.

Just my 2 cents.

Robert


----------



## aragon (Jan 30, 2010)

robbob2112 said:
			
		

> I understand why the 'dangerously dedicated was deleted


Care to share?  I still don't understand why it was flushed.


----------



## robbob2112 (Jan 30, 2010)

I think I misspoke... I don't "understand" on a technical level why it was deleted other than the previous comment from the developer that said it was "broke"... I should have said that  I can accept that it was deleted, but in the process they should have made sysinstall "do no harm" and print a meaningful error message on systems that were previously "dedicated".  

It would even be nice if they gave a menu option to fix the disk and wipe out sector 2 in the install verse just erroring out that it couldn't create the slices AFTER already altering sector 0 and making the old version of the OS unbootable in the process.

As a side note the previously listed "dd" command to fix it resulted in a "Operation not permitted" message under 6.2.  I ended up using DBAN to wipe the first few sectors with zeros to get the job done.

If I hadn't had multiple disks and physical access to the server I would have been a lot worse off and taken a lot longer to upgrade.


----------



## jjthomas (Feb 7, 2010)

I'm confused by all this.  The initial "danger" was to users of multiple operating systems.  FreeBSD proports to be a Server OS.  To me a Server runs 24x7.  Who in their right mind would want to dual boot a server?   (BTW I use FreeBSD as a desktop as well, and that is all that is installed on that computer)

I also don't think BSD as a newbie, throw in the disk and whaalaa a desktop appears OS, either.

But if is was broke and cannot be fixed, and a working solution is that we don't use it, then so be it.  

-JJ


----------



## zapher (Feb 8, 2010)

I believe this is the case:

Before FreeBSD 8, when both MBR and GUID/BSDLABEL exists, it would pick the one looking promising. With MBR being the big favorite.

On FreeBSD 8, when both MBR and GUID/BSDLABEL exists, it will prefer BSDLABEL over MBR. So if your BSDLABEL is defunct, it will not mount properly. What you need is to erase the sector holding the BSDLABEL info (sector 2) to allow proper mounting via the MBR-table.


----------



## gcooper@ (Mar 26, 2010)

Here starts the saga of dangerously dedicated being deprecated, gpart being default, and the rest of the marcel@ chronicles:

http://docs.freebsd.org/cgi/getmsg....chive/2008/freebsd-arch/20081130.freebsd-arch
http://svn.freebsd.org/viewvc/base?view=revision&revision=186240

In short, it was a change that was noticed, but wasn't properly screened (IMO) before it was committed. It happens from time to time, but I admit.. this one was a doosy.


----------



## snow (Oct 20, 2010)

Yesterday, I felt sick because of losing drive with BACKUPS. Thank you for collecting and writing this.


----------



## danbi (Oct 21, 2010)

So.. what is the current modern way of thinking, as of late 2010?

gpart, or mbr, or?


----------



## Beastie (Oct 21, 2010)

danbi said:
			
		

> So.. what is the current modern way of thinking, as of late 2010?
> 
> gpart, or mbr, or?


As with everything, it depends on your needs. If you only set up MBR-based systems and need compatibility with older BIOSes or a dual-boot desktop system with DOS/Windows, use fdisk and bsdlabel. fdisk has the advantage over gpart in that case that it automatically aligns BIOS partitions on cylinder boundaries whereas gpart does not waste a single sector and you have to do the alignment manually.
If you do not care about the above and need modern partitioning schemes, then use gpart.


----------



## jem (Oct 25, 2010)

I'm confused about the idea of flushing support for Dangerously Dedicated mode.

My current understanding is that dangerously dedicated mode is where you write a bsdlabel directly to disk at the top level, skipping the creation of a DOS-style MBR and partition table for maintaining compatibility with other OS's.

As far as I can see, there's nothing to stop you from still doing this by manually installing FreeBSD from a Fixit environment.  What's to prevent you from bsdlabelling /dev/ad0 instead of /dev/ad0s1?

Would it be more correct to say that support for DD mode is _flushed from sysinstall_, not from FreeBSD in general?


UPDATE

I did a bit of playing around with this, to try to answer my own question, I've found that it is still possible to set up a "dangerously" dedicated system.  Simply 'bsdlabel -B' the disk device, not a slice.  This writes /boot/boot to the first 16 blocks of the disk (and gives partition 'a' a 16 block offset).

After completing the manual installation my test VM boots fine with the following partitions:


```
/dev/ada0a      /
/dev/ada0b      swap
/dev/ada0d      /var
/dev/ada0e      /usr
```

This was tested with 8.1-RELEASE-amd64, using the ahci module.  /boot/loader.conf needed 
	
	



```
vfs.root.mountfrom="ufs:/dev/ada0a"
```


----------



## Beastie (Oct 25, 2010)

Of course there is nothing preventing you from doing that unless the developers add code to bsdlabel that specifically forbids it from writing a label to a raw device.
It happens to me all the time when I accidentally give bsdlabel the same device as I gave fdisk, forgetting to add the slice. Same thing for gpart.


----------

