Dangerously dedicated support flushed?!

[aragon]

“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]

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]

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]

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]

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]

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

[graudeejs]

pardon, my ignorance, but what exactly was “dangerously dedicated UFS" ?

[SirDice]

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]

Ok, thanks

[robbak]

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]

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]

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]

POLA has nothing to do with it as it's completely irrelevant to users and their privileges.
You are mistaken (http://www.freebsd.org/doc/en/books/handbook/freebsd-glossary.html#POLA-GLOSSARY).

[SirDice]

You are mistaken (http://www.freebsd.org/doc/en/books/handbook/freebsd-glossary.html#POLA-GLOSSARY).
No, I'm not (http://en.wikipedia.org/wiki/Pola)

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]

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]

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 root@catflap.bishopston.net:/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]

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@]

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]

Search the mailing list archives for a reason why this had to change.
Well I couldn't find it. Care to enlighten us?

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...
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 (http://www.freebsd.org/doc/en/books/faq/disks.html#DANGEROUSLY-DEDICATED) 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]

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

[jamie]

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]

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

Should we shoot the Release Notes (http://www.freebsd.org/releases/8.0R/relnotes-detailed.html#DISKS)?

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]

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]

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]

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]

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]

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]

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]

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]

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]

I understand why the 'dangerously dedicated was deleted
Care to share? I still don't understand why it was flushed.

[robbob2112]

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]

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]

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@]

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.cgi?fetch=164743+0+archive/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]

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

[danbi]

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

gpart, or mbr, or?

[Beastie]

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]

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]

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.