Dangerously dedicated support flushed?!

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.
 
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]
 
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]
 
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!
 
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
 
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.
 
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
 
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.
 
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.
 
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:

Code:
/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
Code:
vfs.root.mountfrom="ufs:/dev/ada0a"
 
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.
 
Back
Top