[Solved] Dangerously dedicated support flushed?!

aragon · #1 November 27th, 2009, 00:15

Quote:

Originally Posted by FreeBSD 8.0 Release Notes

“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 · #2 November 27th, 2009, 01:02

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 · #3 November 27th, 2009, 01:57

Quote:

Originally Posted by Beastie

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 · #4 November 27th, 2009, 02:55

Quote:

Originally Posted by Beastie

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 · #5 November 27th, 2009, 04:29

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** · #6 November 27th, 2009, 09:02

Quote:

Originally Posted by aragon

Surely this violates POLA?

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

graudeejs · #7 November 27th, 2009, 10:41

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

**SirDice** · #8 November 27th, 2009, 10:56

Quote:

Originally Posted by killasmurf86

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 · #9 November 27th, 2009, 11:06

Ok, thanks

robbak · #10 November 27th, 2009, 12:41

Quote:

Originally Posted by SirDice

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 · #11 November 27th, 2009, 15:07

Quote:

Originally Posted by SirDice

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:

Code:

# 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** · #12 November 27th, 2009, 15:09

Quote:

Originally Posted by robbak

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/Princip...east_privilege

More commenly known in the security field as POLA.

aragon · #13 November 27th, 2009, 17:40

Quote:

Originally Posted by SirDice

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

You are mistaken.

**SirDice** · #14 November 27th, 2009, 18:51

Quote:

Originally Posted by aragon

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

honk · #15 November 28th, 2009, 02:51

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 · #16 December 2nd, 2009, 01:02

Errrm, they lie? :

Code:

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 · #17 December 2nd, 2009, 03:30

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@** · #18 December 2nd, 2009, 05:56

Quote:

Originally Posted by killasmurf86

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 · #19 December 2nd, 2009, 08:27

Quote:

Originally Posted by randi

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

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

Quote:

Originally Posted by randi

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

Quote:

Originally Posted by src/usr.sbin/sysinstall/disks.c

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 · #20 December 2nd, 2009, 09:14

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

jamie · #21 December 2nd, 2009, 14:42

Quote:

Originally Posted by randi@

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 · #22 December 2nd, 2009, 16:00

Quote:

Originally Posted by randi@

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

Should we shoot the Release Notes?

Quote:

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 · #23 December 31st, 2009, 04:16

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 · #24 December 31st, 2009, 07:04

Quote:

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.

Quote:

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 · #25 December 31st, 2009, 11:04

Quote:

Originally Posted by 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.

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.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
HOWTO: Convert Dangerously Dedicated Disks to FreeBSD 8.0 with 3ware 9650SE RAID	dgs	Howtos & FAQs (Moderated)	3	April 20th, 2010 17:13
DD (Dangerously Dedicated) mode not available	worldwins	Installing & Upgrading	5	March 25th, 2010 21:43
Quake2 Dedicated Server?	vask	Installation and Maintenance of FreeBSD Ports or Packages	1	February 22nd, 2010 09:14
Hosting Domains with dedicated IP addresses.	miatech	Web & Network Services	2	December 23rd, 2009 05:32
Two Dedicated IP addresses, how to route	esogs	Networking	6	August 13th, 2009 17:37

The Following User Says Thank You to SirDice For This Useful Post:
graudeejs (November 27th, 2009)

The Following User Says Thank You to tvh For This Useful Post:
aragon (December 31st, 2009)