9.0_RELEASE upgrade with RAID1

I just ran the freebsd-update to go from 8.2_RELEASE to 9.0_RELEASE, but didn't think about the fact that I'm running a raid 1 that was set up using the geomirror (sp?) system explained in the handbook. When I rebooted the machine, it went to the mountroot prompt and after a couple of minutes of searching the web for a solution, I went back to the machine to try to see if I could get the contents of fstab, this was on the screen:


freebsdproblem.jpg


Any help would be appreciated. thanks.
 
I'm in a process of upgrading myself and haven't tried 9.0 yet, but .. What kind of disks are those? As I read from release notes, by default, all ATA disks are seen via CAM (== different device special files /DSFs/).

Is that raid done by ataraid or gmirror? Cause I would guess that gmirror should be ok (geom would activate them)..

At mountprompt>, hit the ? to list all possibilities to boot from.
 
matoatlantis said:
I'm in a process of upgrading myself and haven't tried 9.0 yet, but .. What kind of disks are those? As I read from release notes, by default, all ATA disks are seen via CAM (== different device special files /DSFs/).

Is that raid done by ataraid or gmirror? Cause I would guess that gmirror should be ok (geom would activate them)..

At mountprompt>, hit the ? to list all possibilities to boot from.

Yes, gmirror is what I used. When I hit ?, I get:
Code:
List of GEOM managed disk devices:

   mirror/gm0 cd0 ada1 ada0
 
What was your setup prior to upgrade ? I mean FS layout. Try to mount root from gm0, i.e.:

ufs:/dev/mirror/gm0
 
bluetick said:
Have you tried this?

Code:
ufs:/mirror/gm0s1a

same thing, error 19. Which I'm guessing means that I don't have the device name right (i.e. it can't find anything by the names I've been trying). Thanks though.

mirror/gm0 gave error 22, so maybe that's a clue. I have no idea what to try. The suggestions for troubleshooting gmirror in the handbook didn't help.
 
wblock@ said:
Boot mfsBSD and look at the devices available.

Ok, downloading the 9.0 iso now. Could you let me know where I can look for that info once I boot? I thought that entering ? at rootmount> gave that list, but apparently not.
 
I had exactly the same problem.
During boot with option [2] from the boot menu I dropped the system to a loader(8) prompt.

At the prompt I entered
Code:
OK set kern.geom.part.check_integrity=0
. After that boot the system with
Code:
OK boot
.

Now, I managed at least to boot....

Find more in the Upgrade documentation.
 
Okay, I had the same issue and removing the integrity check did the trick.

The bigger issue is: what's the best way to fix this issue in the long term? Tear down the mirror and rebuild? Fix the MBR?

~Doug
 
I think the MBR needs to fixed. I posted a new thread for that question.

I don't want to destroy my MBR, but I suppose that we will end using the following command......

Code:
gpart bootcode [-b bootcode] [-p partcode -i index] [-f flags] geom
 
For some reason the partition table seems to be incompatible with R9.0

I tried, the code below without succes:

Code:
sudo /sbin/gpart bootcode -b /boot/pmbr mirror/gm0
gpart: table 'mirror/gm0' is corrupt: Operation not permitted
 
Too many variables. Please show the output of gpart show on the drive and describe how it was created. Note that it does not work to try to create GPT partitions on a gmirror device; they fight over the end of the disk.
 
Below the output of gpart show

Code:
=>       63  976773104  mirror/gm0  MBR  (465G) [CORRUPT]
         63  976773105           1  freebsd  [active]  (465G)

=>        0  976773105  mirror/gm0s1  BSD  (465G)
          0    2097152             1  freebsd-ufs  (1.0G)
    2097152    2097152             2  freebsd-swap  (1.0G)
    4194304   10485760             4  freebsd-ufs  (5.0G)
   14680064    4194304             5  freebsd-ufs  (2.0G)
   18874368  957898737             6  freebsd-ufs  (456G)

It was created in R8.2 , following instructions in the gmirror documentation.
 
The code that detects a partitioning scheme's data may have changed enough that formerly-good schemes are no longer detected. Please make a full backup, and enter a PR.
 
Sorry, I should have given the link that vand777 provided. The command line send-pr(1) does the same thing, but I find the web form easier to use.

Anyway, yes, PRs are important. Without one, or at least a post on one of the mailing lists like freebsd-questions, developers may not be aware of the problem.
 
Back
Top