# 9.0_RELEASE upgrade with RAID1



## Lido (Jan 13, 2012)

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:








Any help would be appreciated. thanks.


----------



## wblock@ (Jan 14, 2012)

Device names or numbers may have changed, like ad4 becoming ada0.  Try ufs:/dev/ada0s1a first.


----------



## _martin (Jan 14, 2012)

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.


----------



## Lido (Jan 14, 2012)

wblock@ said:
			
		

> Device names or numbers may have changed, like ad4 becoming ada0.  Try ufs:/dev/ada0s1a first.



That fails with error 19.


----------



## Lido (Jan 14, 2012)

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:
	
	



```
List of GEOM managed disk devices:

   mirror/gm0 cd0 ada1 ada0
```


----------



## _martin (Jan 14, 2012)

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

ufs:/dev/mirror/gm0


----------



## Lido (Jan 14, 2012)

matoatlantis said:
			
		

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



That gives an error 22. I followed the instructions here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html

The top of the screen gives some info:


----------



## bluetick (Jan 14, 2012)

```
/dev/mirror/gm0s1a
```


----------



## Lido (Jan 14, 2012)

bluetick said:
			
		

> ```
> /dev/mirror/gm0s1a
> ```



Error 19 when I try (as GEOM appears to before it fails):
	
	



```
ufs:/dev/mirror/gm0s1a
```


----------



## bluetick (Jan 14, 2012)

Have you tried this? 


```
ufs:/mirror/gm0s1a
```


----------



## Lido (Jan 14, 2012)

bluetick said:
			
		

> Have you tried this?
> 
> 
> ```
> ...



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@ (Jan 14, 2012)

Boot mfsBSD and look at the devices available.


----------



## Lido (Jan 14, 2012)

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.


----------



## wblock@ (Jan 14, 2012)

Look for /dev/ad* and /dev/mirror/*.  dmesg(8) output can also be useful.


----------



## ericmacmini (Jan 14, 2012)

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 
	
	



```
OK set kern.geom.part.check_integrity=0
```
. After that boot the system with 
	
	



```
OK boot
```
.

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

Find more in the Upgrade documentation.


----------



## dougs (Jan 14, 2012)

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


----------



## ericmacmini (Jan 14, 2012)

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


```
gpart bootcode [-b bootcode] [-p partcode -i index] [-f flags] geom
```


----------



## wblock@ (Jan 14, 2012)

But what is broken in the MBR and what broke it?


----------



## ericmacmini (Jan 14, 2012)

For some reason the partition table seems to be incompatible with R9.0

I tried, the code below without succes:


```
sudo /sbin/gpart bootcode -b /boot/pmbr mirror/gm0
gpart: table 'mirror/gm0' is corrupt: Operation not permitted
```


----------



## wblock@ (Jan 14, 2012)

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.


----------



## ericmacmini (Jan 14, 2012)

Below the output of gpart show


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


----------



## wblock@ (Jan 14, 2012)

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.


----------



## ericmacmini (Jan 15, 2012)

Okay, but what exactly do you mean with enter a PR?

Is it a repartitioning? Do I have to switch off the gmirror first?


----------



## vand777 (Jan 15, 2012)

ericmacmini said:
			
		

> Okay, but what exactly do you mean with enter a PR?


Problem report (PR) if I understood correctly.


----------



## wblock@ (Jan 15, 2012)

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.


----------



## robertclemens (Jan 15, 2012)

I have been prepping my servers for a FreeBSD 8.2R -> 9.0R upgrade. So far the upgrade process has been very easy and straight-forward.

This thread caused me some pause on my gmirror server. It has two mirrors using MBR.

Has this problem been confirmed from someone else regarding an issue with gmirror and the upgrade? Can we also confirm he was using MBR and not GPT?

If my memory serves me right, GPT may not be used for entire-disk mirroring but only individually on each partition, correct (end of disk metadata storage)? Whereas MBR you could do entire-disk or partition mirroring.


```
[root@postfix /usr/ports/security/maia]# gpart status
         Name  Status  Components
 mirror/gm0s1      OK  mirror/gm0
mirror/gm0s1a      OK  mirror/gm0s1
  mirror/gm1a      OK  mirror/gm1
```


```
[root@postfix /usr/ports/security/maia]# gpart show
=>       63  625142322  mirror/gm0  MBR  (298G)
         63  625137282           1  freebsd  [active]  (298G)
  625137345       5040              - free -  (2.5M)

=>        0  625137282  mirror/gm0s1  BSD  (298G)
          0    8388608             1  freebsd-ufs  (4.0G)
    8388608    8388608             2  freebsd-swap  (4.0G)
   16777216   16777216             4  freebsd-ufs  (8.0G)
   33554432    4194304             5  freebsd-ufs  (2.0G)
   37748736   41943040             6  freebsd-ufs  (20G)
   79691776  545445506             7  freebsd-ufs  (260G)

=>        0  976773167  mirror/gm1  BSD  (466G)
          0         16              - free -  (8.0K)
         16  976773151           1  freebsd-ufs  (466G)
```

If someone has done a successful upgrade with [gmirror] across the OS drives, I would appreciate some assurance. Thanks!


----------



## wblock@ (Jan 15, 2012)

robertclemens said:
			
		

> If my memory serves me right, GPT may not be used for entire-disk mirroring but only individually on each partition, correct (end of disk metadata storage)? Whereas MBR you could do entire-disk or partition mirroring.



Yes.


----------



## ericmacmini (Jan 16, 2012)

I posted a Problem Report yesterday.

I don't think that the upgrade process corrupted the MBR partition scheme which I had in R8.3. Since FreeBSD R9.0 defaults to GPT, it's more likely that the problem lies in backwards compatibility.


----------



## Lido (Jan 16, 2012)

ericmacmini said:
			
		

> I posted a Problem Report yesterday.
> 
> I don't think that the upgrade process corrupted the MBR partition scheme which I had in R8.3. Since FreeBSD R9.0 defaults to GPT, it's more likely that the problem lies in backwards compatibility.



Can you post a link to the PR you filed so people can see what needs to be done or do you think a solution will come through freebsd-update?


----------



## robertclemens (Jan 16, 2012)

The PR is kern/164143


----------



## Lido (Jan 18, 2012)

Anyone have any idea what to do here? I'm a longtime newbie and was hoping to have this installation last a while. Would it be best to just reinstall or is this something that will get resolved? If I do reinstall, can I set up a raid 1 or will I end up with the same issue? Thanks.


----------



## archen (Jan 18, 2012)

If you like the simplicity of gmirror the way it used to be done, I think the right thing to do would be stick with the 8.x series for now. It's still considered current and will be maintained for a while.


----------



## Lido (Jan 18, 2012)

Would it be possible/simple to rollback the *freebsd-update -upgrade -9.0_RELEASE* I just did?


----------



## wblock@ (Jan 19, 2012)

archen said:
			
		

> If you like the simplicity of gmirror the way it used to be done, I think the right thing to do would be stick with the 8.x series for now. It's still considered current and will be maintained for a while.



gmirror(8) didn't change, it'll still work the same.  Something changed elsewhere.  Backing up the data and recreating the mirror might (should) solve the problem.


----------



## tovo (Jan 19, 2012)

Hi Lido,
I've experienced exactly the same problem after an upgrade. I followed this old thread and it solved my problem.
To summarize, when you are on the boot menu, you need to choose to boot in single user and after run an FSCK on your filesystem.
Hope it helps


----------



## von_Gaden (Jan 21, 2012)

Well, I also went through this non-booting integrity check fail. The kern.geom.part.check_integrity=0 saved my life either.
The story is similar to others - I upgraded my source tree to FreeBSD 9.0-RELEAEE and I found the unpleasant surprise.
I have whole-device mirror with MBR partition (this is an old install). I noticed following messages during boot:


```
Jan 21 14:24:11 leo kernel: GEOM_MIRROR: Device mirror/gm0 launched (2/2).
Jan 21 14:24:11 leo kernel: GEOM_PART: integrity check failed (mirror/gm0, MBR)
Jan 21 14:24:11 leo kernel: GEOM: mirror/gm0s1: geometry does not match label (16h,63s != 255h,63s).
```

The partition was created a long time ago with sysinstall and there are NO other partitions - this is a dedicated FreeBSD server.
I remember I saw this warning for long time but since it worked OK I never doubted about it.

I hope this post will help to find an universal, long-term solution.


----------



## gkontos (Jan 21, 2012)

I see that a lot of people here are facing some problems with this issue. 

Filling a PR is a good idea because that way it will get the attention of the developers.


----------



## von_Gaden (Jan 22, 2012)

There is already a PR: 
http://www.freebsd.org/cgi/query-pr.cgi?pr=164143&cat=
The difference in my case is that I didn't try to rewrite bootcode.


----------



## copypaiste (Jan 22, 2012)

There's a big red warning about using GPT scheme and geom mirroring in Handbook http://www.freebsd.org/doc/handbook/geom-mirror.html
I've found a workaround by Michael W. Lukas (couldn't find the working link though) - create separate geom mirror device for each slice.  

Awful bug. I hope it will be fixed soon.


----------



## gkontos (Jan 22, 2012)

von_Gaden said:
			
		

> There is already a PR:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=164143&cat=
> The difference in my case is that I didn't try to rewrite bootcode.



My apologies! I hadn't seen it :\


----------



## ericmacmini (Jan 22, 2012)

This morning I backed up all relevant data, since I am considering to gmirror individual partitions instead of the whole disk. 
I have following steps in mind, at step 3 I have a question. Of course, other tips/remarks are very welcome also.

1. create a new GPT scheme on my second disk (ada1):


```
# gpart create -s gpt ada1
# gpart add -t freebsd-boot -l boot-secondary -s 64 ada1
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada1
# gpart add {my other necessary partitions}
```

2. dump / restore all data from ada0 to the newly GPT schemed disk ada1.

3. Reboot the system on disk ada1.
[Question:] How can force the /boot/loader.conf to boot from disk ada1 ?

4. Create an identical layout on the primary ada0 disk.

5. dump / restore all data from ada1 back to the newly GPT schemed primary disk ada0 .

6. Reboot the system on disk ada0 .

7. Setting up the gmirror for individual partitions.


----------



## wblock@ (Jan 22, 2012)

ericmacmini said:
			
		

> This morning I backed up all relevant data, since I am considering to gmirror individual partitions instead of the whole disk.
> I have following steps in mind, at step 3 I have a question. Of course, other tips/remarks are very welcome also.
> 
> 1. create a new GPT scheme on my second disk (ada1):



Give the new partitions GPT labels that are different from ada0.



> 3. Reboot the system on disk ada1.
> [Question:] How can force the /boot/loader.conf to boot from disk ada1 ?



Probably easiest to use the boot menu to select that drive.  Or just swap cables.  (Mount and edit the /etc/fstab on the new drive to refer to the new GPT labels before booting.  Or do what I usually do, forget it and have to manually enter the path to the boot device.)



> 5. dump / restore all data from ada1 back to the newly GPT schemed primary disk ada0 .



In theory, it's fine.  In practice, make a full backup first.  If you back up ada0 to files on some other media, they can be restored to ada1, so the backup doesn't have to run twice.


----------



## von_Gaden (Jan 23, 2012)

I agree that there might be a problem with GPT partition scheme and GMIRROR on whole drive. I use GPT and per-partition mirror and journal on my newer installs. In my case and as I can see in some other mentioned here we don't use GPT scheme, but MBR.
Is there any way to see what is the fail in the integrity check? This might explain the problem.


----------



## ericmacmini (Jan 23, 2012)

Unfortunately I am not a C-language expert. I already looked up the source code for the command gpart show. 

The CORRUPT error message is generated by the following C-function in the source code:


```
gpart_show_geom(struct ggeom *gp, const char *element, int show_providers)
.....
	printf("=>%*jd  %*jd  %*s  %s  (%s)%s\n",
	    wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1),
	    wname, gp->lg_name,
	    scheme, fmtsize(pp->lg_mediasize),
	    s ? " [CORRUPT]": "");
......
```

I suppose that the CORRUPT message is generated when variable s equals FALSE in the statement above. The variable s is last set with:


```
s = find_geomcfg(gp, "state");
	if (s != NULL && *s != 'C')
		s = NULL;
```

Maybe, somebody with much more C-Language skills can help us futher from here.

[QUESTION] Is there an easy way to only recompile gpart from the /src/ directory, or do you need to make buildworld completly?


----------



## butcher (Jan 23, 2012)

If you do not want to completely break your system, don't try hack the code 
First of you should understand where is the problem.

The problem is in your partition table. As you see it marked corrupted. 
When partition table marked as corrupted you can not modify it. It is protection mechanism. 
You can enable verbose boot mode and you will see why your partition table marked as corrupted.
There will be some lines that begins from "GEOM_PART: ".


----------



## von_Gaden (Jan 23, 2012)

So here is my verbose boot mode output:

```
Jan 23 22:09:38 leo kernel: GEOM_MIRROR: Device mirror/gm0 launched (2/2).
Jan 23 22:09:38 leo kernel: GEOM_PART: partition 1 has end offset beyond last LBA: 1250263727 > 1250263726
Jan 23 22:09:38 leo kernel: GEOM_PART: integrity check failed (mirror/gm0, MBR)
Jan 23 22:09:38 leo kernel: GEOM: mirror/gm0s1: geometry does not match label (16h,63s != 255h,63s).
```

Since my drives were partitioned with sysinstall (maybe in FreeBSD 6), then re-partitioned for FreeBSD 8 (there was again problem with partitions and the system couldn't boot) may I suggest there was an error in Sysinstall or fdisk?


----------



## wblock@ (Jan 23, 2012)

I have a sinking feeling that this is due to the instructions for gmirror(8) in the Handbook.  It has the user set up a drive, then overrides the safety and writes the gmirror meta-data into the last block of that partition.  When gmirror is asked for the partition size, it will come back as one less block (so the meta-data isn't overwritten).  But the partition was created first, so the partition is one block too large.  The cure to that would be to do it the right way, by creating the mirror first and then filesystems inside the mirror.


----------



## von_Gaden (Jan 23, 2012)

I must admit this mirror was "born" by following the exact instructions in the Handbook. The Handbook itself was one of the major reasons for me to choose FreeBSD for my production servers back in 2002.
My newer installations are based on gpt partition scheme and per-partition mirorring - if we have 2 HDDs (ad4, ad6) I use the following:


```
gpart create -s gpt ad4 (or ad6)
gpart add -s 64K -t freebsd-boot ad4 (or ad6)
gpart add -s 2G -t freebsd-ufs -l root1 ad4 (or root2 ad6)
gmirror label -vb load root ad4p2 ad6p2
newfs -L root /dev/mirror/root
```

Do you think that this implementation will be affected by the same issue? I have not enough time to try it myself but I'll do my best in next few days.

Warning for all newer users: This post is not a manual and the procedure described above misses some important details!


----------



## wblock@ (Jan 23, 2012)

von_Gaden said:
			
		

> Do you think that this implementation will be affected by the same issue? I have not enough time to try it myself but I'll do my best in next few days.



That should be fine.  The partition provides n blocks, the mirror reserves the last one for itself and provides n-1 blocks to the filesystem.

But please post back after trying it.  An "I actually did it" is worth a thousand oughtas.

There are other ways to do it, of course.  Use MBR partitioning, create the mirror out of those partitions.  And there can be more than one mirror.  My gmirror article shows how to create a mirror for each filesystem with GPT partitions.


----------



## butcher (Jan 24, 2012)

wblock@ said:
			
		

> But the partition was created first, so the partition is one block too large.  The cure to that would be to do it the right way, by creating the mirror first and then filesystems inside the mirror.



Yes. But not filesystem. The mirror should be created first, then partition table on top of mirror. E.g.

```
# gmirror label -v gm0 ad4 ad6
# gpart create -s mbr mirror/gm0
# gpart add -t freebsd mirror/gm0
....
```


----------



## butcher (Jan 24, 2012)

von_Gaden said:
			
		

> So here is my verbose boot mode output:
> 
> ```
> Jan 23 22:09:38 leo kernel: GEOM_MIRROR: Device mirror/gm0 launched (2/2).
> ...



The one way how you may fix this problem:
1. Detach one component from your mirror.
2. Kill partition table and filesystems on it.
3. Create new mirror, then create partition table.
4. dump+restore the data from old mirror to the new one.
5. Reboot system from the new mirror, kill old mirror and attach second disk to new mirror.


----------



## von_Gaden (Jan 24, 2012)

I'd disagree since this is my exact current setup and I believe it causes my problem. My gmirror now is:

```
Name    Status  Components
mirror/gm0  COMPLETE  ada0 (ACTIVE)
                      ada1 (ACTIVE)
/dev/mirror/gm0s1a on / (ufs, local)
/dev/mirror/gm0s1d on /usr (ufs, local, soft-updates)
...
```


----------



## butcher (Jan 24, 2012)

Your mirror works fine, but your partition table is still marked as corrupt and you can not change it. 
Also, if you remove kern.geom.part.check_integrity line from your loader.conf, then your system will become unbootable.


----------



## von_Gaden (Jan 24, 2012)

I mean my mirror is on whole drive and partitions were created on top of it as it was described in the Handbook. I see now there is a different procedure but some time ago it was just like that: FreeBSD installed on first drive, second drive added to newly created mirror, mirror is partitioned, contents dumped from the first drive, reboot from mirror and then wipe out first drive and add it to the mirror. So the partitioned drive is mirror, not the providers as you mention above.
And yes, this is inappropriate now and without kern.geom.part.check_integrity it won't boot.


----------



## ericmacmini (Jan 24, 2012)

I managed to remove my previous MBR scheme following the steps below. For details I would like to refer to this great tutorial provided by  Warren. Great job Warren! 

1.   I attached an external USB disk to my dedicated FreeBSD server. On the external disk I created a new partition scheme according the GPT layout using gpart and newfs.

2.   Kill most processes (httpd, mysld..) to avoid later locking file problems during boot from the external disk.

3.   Use dump and restore to copy all data to the external disk. 

4.   mount the root directory on the external disk to /mnt and edit the /mnt/etc/fstab file and /mnt/boot/loader.conf. 

5.   Re-boot your system from the external USB disk.

6.   Prepare the (orginal) harddisks for the gmirror following this great tutorial provided by Warren.

I am more relaxed since my output of gpart status looks much better now:


```
Name    Status  Components
ada0p1      OK  ada0
ada0p2      OK  ada0
ada0p3      OK  ada0
ada0p4      OK  ada0
ada0p5      OK  ada0
ada0p6      OK  ada0
ada1p1      OK  ada1
ada1p2      OK  ada1
ada1p3      OK  ada1
ada1p4      OK  ada1
ada1p5      OK  ada1
ada1p6      OK  ada1
```

Another positive thing is that my knowledge of FreeBSD, especially about booting and the filesystem, has grown a lot! Thanks to all extensive FreeBSD documentation and contributions. My believe in the FreeBSD only grew!


----------



## wblock@ (Jan 24, 2012)

von_Gaden said:
			
		

> I mean my mirror is on whole drive and partitions were created on top of it as it was described in the Handbook. I see now there is a different procedure but some time ago it was just like that: FreeBSD installed on first drive, second drive added to newly created mirror, mirror is partitioned, contents dumped from the first drive, reboot from mirror and then wipe out first drive and add it to the mirror. So the partitioned drive is mirror, not the providers as you mention above.
> And yes, this is inappropriate now and without kern.geom.part.check_integrity it won't boot.



If you use MBR partitioning and leave a little unpartitioned space at the end of the drive, the Handbook procedure should work (untested!).  That would leave a block free for gmirror metadata, and the boot process wouldn't complain about a partition being larger than it should be.

That will not work for GPT partitioning, which puts the backup partition table at the end of the disk (not logical device) and can't be put inside a mirror.  If you use GPT, create identical partitions on the two disks first.  The disks don't have to be the same size, but the partitions do.  Then mirror the partitions.  As mentioned elsewhere, there's a potential for disk head thrashing on resyncing the mirrors, so a single / filesystem like default bsdinstall setup might be an advantage.  Non-filesystem partitions like freebsd-boot or freebsd-swap could even go without mirroring.

Oh: thanks for the kind words, Eric!


----------



## von_Gaden (Jan 25, 2012)

As I promised I updated one of my newer servers with mirrored GPT partitions. Partition and mirror schemes are very similar to the amazing and useful gmirror article posted by wblock earlier in this thread. Two of the mirrors are also journaled.

As wblock@ guessed everything was fine and trouble-free! There are no integrity check fails or any other disturbing messages.

I think it will be safer to put 
	
	



```
kern.geom.part.check_integrity=0
```
 in /boot/loader.conf when updating to FreeBSD 9. Then examine the log and remove this setting if everything is OK. This is of essential importance when you are far away from the server.

I'm afraid that the only cure for "integrity check failed partitions" like my first MBR over mirrored devices may be only dump, re-partition and restore. This is really annoying and time-consuming on some thousand gigabytes of data. Luckily more than a terabyte on MBR and gmirror will be very rare case.


----------



## Lido (Jan 27, 2012)

So which is the post that determined that this thread is solved? 51, 55, 57? Thanks.


----------



## DutchDaemon (Jan 27, 2012)

#55. It's the OP's call.


----------



## Lido (Feb 2, 2012)

tovo said:
			
		

> Hi Lido,
> I've experienced exactly the same problem after an upgrade. I followed this old thread and it solved my problem.
> To summarize, when you are on the boot menu, you need to choose to boot in single user and after run an FSCK on your filesystem.
> Hope it helps



This doesn't seem to work. If you follow Eric's instructions on how to boot (except use *boot -s* to get to single user mode), you can run *fsck*, but it doesn't fix the issue the next time you boot.


----------



## Lido (Feb 11, 2012)

DutchDaemon said:
			
		

> #55. It's the OP's call.



Actually, I'm the OP and I'd call this not solved.


----------



## wblock@ (Feb 11, 2012)

Summarizing: The Handbook procedure used a quick hack to turn a non-mirrored drive into a mirrored drive without having to repartition; the last sector of the partition was reused for gmirror metadata without changing the partition size.  It's a hack because that sector could be overwritten by the filesystem on it (although it's unlikely).  Done properly, the mirror would have been created first, then the partition would be one sector smaller instead of "sharing" that sector.  The Handbook procedure let the user skip the inconvenience of repartitioning.

That method worked under FreeBSD 8 because the boot loader wasn't very particular about partition sizes.

In FreeBSD 9, the boot loader checks partition sizes, and stops when it finds the overlap.  The workaround, turning off the partition integrity check, is shown in the detailed release notes: http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#AEN1277

The real cure is to back up, then recreate the mirror and partitions from scratch.  Do not follow the "RAID 1 - Mirroring" Handbook procedure if you are using FreeBSD 9, but create a mirror, then MBR partitions on it, or create GPT partitions and mirror those.  Finally, restore.

There may be a way to shrink a partition by one sector and correct a UFS filesystem on it, but AFAIK that has not been documented.


----------



## DutchDaemon (Feb 11, 2012)

Lido said:
			
		

> Actually, I'm the OP and I'd call this not solved.



Right you are, totally overlooked 'page 1'!


----------



## Lido (Feb 22, 2012)

WBlock, in your tutorial, you leave a few partitions un-mirrored. In the Linux side, from what I remember the swap needed to be mirrored or the system would have trouble if the disk with the swap failed. Have you tested that with gmirror? I'm planning on using RAID1 mainly to keep the system up in the even a drive dies. Thanks.


----------



## FryShadow (Dec 13, 2012)

I just encounter this kind of problem upgrading from 8.3-R to 9.0-R. The issue is 9.0-R can't seem to find partition on gm0.

My step to solve and boot into the 9.0-R :
- Using 9.0-R CD as live-cd to edit the ad0 fstab
- from mirror/gm0 to /dev/ad0s1a
- Reboot [ press 2 on options list, load into loader ] and type
>boot kernel.old
- Remove the gmirror ( ad4 and ad6 is from kernel.old )
gmirror remove gm0 ad6
gmirror remove gm0 ad4
- Reboot and you can boot into your new 9.0-R

I try to build back the raid but need to test first from my other machine. 

Hope can help others with this kind of issue


----------



## wblock@ (Dec 13, 2012)

Partition conflicts could prevent the mirror from being recognized.  The gmirror(8) module must also be loaded or mirrors can't work.  Usually done in /boot/loader.conf:

```
geom_mirror_load="YES"
```

Incidentally, the Handbook mirroring section has been updated to show the correct way to create a mirror with either one or two new drives.


----------



## FryShadow (Dec 14, 2012)

Yes I've try to load the module but no luck, not so sure why.. -_-


----------

