updated 9-STABLE with boot issues?

jbeez · #1 May 31st, 2012, 04:45

Looks like some added functionality has made my system start to recognize some old mirror that was set up on the system some time ago on the last motherboard it was on.

Upon booting the new kernel I'm getting things like

Code:

ROOT MOUNT WAITING FOR GRAID-NVIDIA

It eventually fails, it mentions something about

Code:

GEOM_RAID NVIDIA-1 VOLUME STRIPE

and it dumps me out to a mount prompt.

I can boot up my old kernel, but since I just did a buildworld, buildkernel and install kernel then rebooted, some of my things aren't working now because of version incompatibilities like zfs, so all my main storage is inaccessible at the moment.

So I just have my rootfs on a single SATA disk, I'm not doing any RAIDs or anything special for most of my system. the zfs is just storing data like multimedia, etc. The only system thing it's storing is the /home partition, everything else is on my ufs formatted SATA drive with labels, for example,

Code:

Filesystem              Size    Used   Avail Capacity  Mounted on
/dev/label/rootfs         2G    676M    1.1G    37%    /

Wondering how I can find this hidden Nvidia metadata and wipe it out or disable this nvidia raid? My ~~freebsd~~ FreeBSD 9 box is running on an Nvidia board with an intel chipset now, there shouldn't be anything Nvidia showing up anywhere.

Any help would be greatly appreciated!

Thanks,
-Jerry

jbeez · #2 May 31st, 2012, 05:24

Also apparently renaming /boot/kernel.old/ directory to just kernel allows the zfs modules to load properly, I don't know why they won't load when I manually specify to boot kernel.old so I'm back in business I guess 100% but unable to proceede with any upgrades until I hammer this out :|

I took some pics with my phone during bootup,
https://www.dropbox.com/s/ptkue1ecgb...530_235129.jpg
https://www.dropbox.com/s/hik0vqlewt...0_235159_1.jpg
https://www.dropbox.com/s/8llupgzhot...0_235201_1.jpg

**wblock@** · #3 May 31st, 2012, 05:28

mav@ described this a couple of days ago. graid(8) can deal with the RAID metadata even if the disk is not on that controller any more.
# graid list
to show the RAID, then delete -f name to erase the metadata. The danger is that it will wipe out some other data on that disk.

jbeez · #4 May 31st, 2012, 06:13

Been reading all of those man pages, graid/glist/glabel. Looks like I had to graid load -v then graid list -a to have it show up,

Code:

Geom name: NVIDIA-1
Metadata: NVIDIA
Consumers:
1. Name: ada0
   Mediasize: 320072933376 (298G)
   Sectorsize: 512
   Mode: r0w0e0
   ReadErrors: 0
   Subdisks: (null)
   State: NONE

So since you mentioned a data loss issue, if I copy all the contents of this disk to another disk temporarily then erase the metadata and then copy the contents back, would that be safe? Perhaps a full tar backup of my ada0 partitions to my zfs array or will it possibly erase something like partition tables, lower level information that I can't just back up with a tar command?

Thanks,
-J

kpa · #5 May 31st, 2012, 11:26

Full backup but use dump(8)/restore(8)

http://www.wonkity.com/~wblock/docs/...m_restore_8_em

**wblock@** · #6 May 31st, 2012, 15:00

Quote:

Originally Posted by jbeez

So since you mentioned a data loss issue, if I copy all the contents of this disk to another disk temporarily then erase the metadata and then copy the contents back, would that be safe? Perhaps a full tar backup of my ada0 partitions to my zfs array or will it possibly erase something like partition tables, lower level information that I can't just back up with a tar command?

Yes, a full backup is the only way to be sure. dump(8)/restore(8) like kpa said to back up the filesystems. That won't back up the partition table, see gpart(8) backup for that.

With that, even if graid(8) destroy wipes something out, you can repartition and restore. Or just erase the beginning and end of the disk with dd(1) to manually erase the metadata.

If the NVidia motherboard is still available, the BIOS menus might be able to destroy the RAID without wiping other data.

jbeez · #7 May 31st, 2012, 15:46

Hello,

Thank you all for the replies.

Is there a way for me to disable this automatic RAID functionality at boot time in the new kernel? I'd like to do that until I have a chance to meticulously back up the various bits of data and partitioning I have on this disk in a way that will make my restore smooth.

Thank you,
-Jerry

**dvl@** · #8 May 31st, 2012, 19:53

Is everyone upgrading to 9.x going to experience this problem?

**wblock@** · #9 May 31st, 2012, 23:43

Those with leftover BIOS RAID metadata that hasn't been wiped out by an MBR at the start of the disk or a GPT at the start and end of the disk. Should not be a lot of them, because most will still be part of a RAID that can be used.

So: destroy the RAID from the BIOS before reusing disks from it.

fegu · #10 November 5th, 2012, 11:42

I had a similar problem installing FreeBSD9.1-RC3 on a HP DL320 G3 which had previously contained Windows Server. The hardware raid is being recognized during boot, but not enough to actually be used. The boot process stops on "Root mount waiting for: GRAID" and then gives up after some time (see screenshot). The solution was to go into hardware raid config and remove the raid. Having support for some common hardware raids in FreeBSD would be great.

Nulani · #11 January 1st, 2013, 15:34

Quote:

Originally Posted by jbeez

Hello,

Thank you all for the replies.

Is there a way for me to disable this automatic RAID functionality at boot time in the new kernel? I'd like to do that until I have a chance to meticulously back up the various bits of data and partitioning I have on this disk in a way that will make my restore smooth.

Thank you,
-Jerry

I was wondering the same thing as I'm having the same issue after upgrading to 9.1-RELEASE. I can't seem to get rid of the metadata with:
# graid delete -f NAME
Once that it done, it isn't shown by
# graid list -a
anymore, but the problem persists and the metadata reappears upon reboot. There is no option to the destroy the array in the BIOS. (It's fake software RAID.) Presumably the metadata is somehow not actually deleted or recreated by the BIOS - the feature is disabled, so I can only assume it's a bug. If it is it doesn't appear to be fixed in later versions of the BIOS. The mainboard is the ASUS M2N-LR/SATA.

If there is a way to disable the automatic RAID functionality that would seem to be the best, if short term, solution, rather than removing the disk and hoping a fresh install would fix it.

Thanks in advance.

Edit: Solved by the post below. Many thanks to Terry Kennedy.

Terry_Kennedy · #12 January 1st, 2013, 17:38

Quote:

Originally Posted by Nulani

... but the problem persists and the metadata reappears upon reboot.

Back in "the old days" it was necessary to do:

Code:

sysctl kern.geom.debugflags=16

to let things do actual writes to disks the system thought were in use. Normally, the utilities would report an error rather than silently failing to update the data.

I also seem to recall cases where changes were overwritten by the prior data when the disks were unmounted (for example, during a system shutdown / reboot).

**wblock@** · #13 January 1st, 2013, 18:12

The debugflags setting overrides a safety, allowing writes to devices that are in use. If that is the problem (it almost never is), the user will see a message about the write not being allowed.

If it were me, I'd connect the disk through a different controller, one that will not recognize the metadata. An external USB adapter would work. Then erase the first and last megabyte of the disk with dd(1). It might be possible to turn off the RAID function in the BIOS and do the same thing.

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
[Solved] Updated packages reported as not updated	piggy	Installation and Maintenance of FreeBSD Ports or Packages	4	September 18th, 2011 15:05
[Solved] snd_hda issues with ICH9 and FreeBSD 8-STABLE	Shuny	Mobile Computing	10	July 4th, 2011 09:51
mfsBSD upgraded to stable with stable-8-v15.patch - BOOT FAILURE - PLEASE HELP!!!	EMax	Installing & Upgrading	5	August 27th, 2010 06:58
[Solved] Can 8.1RC be easily updated to 8.1 Stable	shepper	Installing & Upgrading	21	July 4th, 2010 00:34
[Solved] weird issues on 8 stable amd64	ikbendeman	General	2	March 10th, 2010 07:42

The Following User Says Thank You to dvl@ For This Useful Post:
jbeez (June 1st, 2012)

The Following User Says Thank You to Terry_Kennedy For This Useful Post:
Nulani (January 1st, 2013)