# Error 19 after updating from FreeBSD 9.0 to FreeBSD 9.1



## Jimmy (Jun 24, 2013)

Hi there,

After performing a [cmd=]freebsd-update -r 9.1-RELEASE[/cmd] followed by a `freebsd-update install` and a custom kernel build which is presently identical to generic followed by a further `freebsd-update install` on reboot I'm brought to the 'mountboot' prompt as the system is unable to boot.

When I list available devices I can see an ada0, previously I was booting from ad4s1a. The disk was originally created several versions ago, possibly on 7.x. If I escape to the bootloader on boot I can boot from the old kernel back into 9.0-RELEASE without issue but I am unable to boot on the new version through issuing the following at the mountboot prompt:

```
mountboot> ufs:/dev/ada0s1a
```

The above fails with error 19 and returns to the mountboot prompt, but if I actually issue:

```
mountboot> ufs:ada0s1a
```
The system panics with a stack trace output.

The hardware is a JetWay J7F2 with a C7 _CPU_ and a "VIA VT6420 SATA RAID Controller" however I am not using RAID.

Would appreciate any advice. Thank you.


----------



## kpa (Jun 24, 2013)

Can you boot from a 9.1 install media, _CD_ or _USB_ stick? If you can go into the shell/live system and post the output of `gpart show`.


----------



## SirDice (Jun 24, 2013)

Jimmy said:
			
		

> When I list available devices I can see an ada0, previously I was booting from ad4s1a.


You should have already ran into this when upgrading to 9.0; http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#AEN1308



> In 9.0-RELEASE, the FreeBSD ATA/SATA disk subsystem has been replaced with a new cam(4)-based implementation. cam(4) stands for Common Access Method, which is an implementation of an API set originally for SCSI-2 and standardized as "SCSI-2 Common Access Method Transport and SCSI Interface Module". FreeBSD has used the cam(4) subsystem to handle SCSI devices since 3.X.



Do you happen to use the same kernel configuration file you used for older (before 9.0) versions? Try copying GENERIC and create a new kernel configuration. By using an older config you may not have all the new options and devices.


----------



## Jimmy (Jun 24, 2013)

I did google that link earlier but _I'm_ not sure that the information contained within helps. Here are my disk layouts:


```
[root@diesel /home/diesel/jim]# gpart show
=>        63  1953525105  ad4  MBR  (931G)
          63  1953520002    1  freebsd  [active]  (931G)
  1953520065        5103       - free -  (2.5M)

=>         0  1953520002  ad4s1  BSD  (931G)
           0     1048576      1  freebsd-ufs  (512M)
     1048576     8054112      2  freebsd-swap  (3.9G)
     9102688     6123520      4  freebsd-ufs  (2.9G)
    15226208     1048576      5  freebsd-ufs  (512M)
    16274784  1937245218      6  freebsd-ufs  (923G)

=>       63  976773105  ad6  MBR  (465G)
         63  976768002    1  freebsd  [active]  (465G)
  976768065       5103       - free -  (2.5M)

=>        0  976768002  ad6s1  BSD  (465G)
          0  976768002      4  freebsd-ufs  (465G)
```
`uname -a` from unaffected 9.0-RELEASE on kernel.old:

```
[root@diesel /home/diesel/jim]# uname -a
FreeBSD diesel.steppingstones 9.0-RELEASE-p4 FreeBSD 9.0-RELEASE-p4 #11: Sat Nov 10 10:33:09 GMT 2012     [email]jim@diesel.steppi[/email]ngstones:/usr/obj/usr/src/sys/DIESEL  i386
```
My new kernel is a copy of GENERIC. But I think you're right and I may have reused an old kernel configuration file when I built the kernel for 9.0-RELEASE.


----------



## Jimmy (Jun 24, 2013)

Ok I think it's caused by geom_raid. After reading your link on the changes to ATA, I inadvertently added

```
geom_raid_load="YES"
```
to my loader.conf. I then rebooted and was unable to boot with kernel.old and was taken to the mount root prompt which normally greets me with the new 9.1 kernel.

I then entered the loader again, performed a `disable-module geom_raid` followed by a `boot kernel.old`, this allowed me to boot again.

If I perform a regular boot, I see statements regarding GEOM_RAID. In mountroot> I can see my list of GEOM managed disk devices as:

```
raid/rg0 ada1 ada0
```

If I enter the loader, I cannot `disable-module geom_raid` again and then attempt a regular boot presumably because it is no longer present in the loader.conf? Unsure.

I see geom_raid is now included in GENERIC. I'm going to remove this to see if it fixes the problem, as when loaded it almost appears that it assumes that the disks are members of a raid array?


----------



## Jimmy (Jun 24, 2013)

Question, since I'm presently booting from kernel.old. When I compile and install my new kernel, what becomes the old kernel? The current broken kernel, or my working kernel.old?


----------



## wblock@ (Jun 25, 2013)

The last installed kernel becomes kernel.old.

Before you go any farther, make a full backup.  Then use graid(8) to remove the RAID metadata on your disk.


----------



## Jimmy (Jun 25, 2013)

Confirmed after removing geom_raid from the kernel I can boot again. That's not a very generic kernel, considering I'm running a very generic, non-RAID, non-specialised environment.

Thanks all for input.


----------



## Jimmy (Jun 25, 2013)

wblock@ said:
			
		

> The last installed kernel becomes kernel.old.
> 
> Before you go any farther, make a full backup.  Then use graid(8) to remove the RAID metadata on your disk.



If it really is just a case of removing metadata using `graid`, how could I do this? The `graid` features don't appear to be accessible with geom_raid disabled. And I cannot boot with geom_raid enabled.

I'm not sure how the meta data could have gotten there in the first place?


----------



## SirDice (Jun 25, 2013)

Jimmy said:
			
		

> If it really is just a case of removing metadata using `graid`, how could I do this? The `graid` features don't appear to be accessible with geom_raid disabled. And I cannot boot with geom_raid enabled.


What happens if you load it _after_ the system booted?

`# kldload geom_raid`


----------



## wblock@ (Jun 25, 2013)

`graid load` is another way to load the kernel module after boot.


----------



## Jimmy (Jun 25, 2013)

Thanks both, so I managed to load it with `kldload`, but can't seem to delete anything:


```
[root@diesel /home/diesel/jim]# graid list
Geom name: Promise
State: OPTIMAL
Metadata: Promise
Providers:
1. Name: raid/r0
   Mediasize: 1000204853760 (931G)
   Sectorsize: 512
   Stripesize: 65536
   Stripeoffset: 0
   Mode: r0w0e0
   Subdisks: ada0 (ACTIVE)
   Dirty: No
   State: OPTIMAL
   Strip: 65536
   Components: 1
   Transformation: CONCAT
   RAIDLevel: RAID0
   Label: PROMISE Array 1
Consumers:
1. Name: ada1
   Mediasize: 500107862016 (465G)
   Sectorsize: 512
   Mode: r0w0e0
   ReadErrors: 0
   Subdisks: (null)
   State: SPARE
2. Name: ada0
   Mediasize: 1000204886016 (931G)
   Sectorsize: 512
   Mode: r0w0e0
   ReadErrors: 0
   Subdisks: r0(PROMISE Array 1):0@2043831902208
   State: ACTIVE (ACTIVE)

[root@diesel /home/diesel/jim]# graid delete ada0
graid: Array 'ada0' not found.
[root@diesel /home/diesel/jim]# graid delete ada1
graid: Array 'ada1' not found.
[root@diesel /home/diesel/jim]# graid delete 1
graid: Array '1' not found.
[root@diesel /home/diesel/jim]# graid delete 2
graid: Array '2' not found.
[root@diesel /home/diesel/jim]# graid delete r0
graid: Array 'r0' not found.
[root@diesel /home/diesel/jim]# graid status
   Name   Status  Components
raid/r0  OPTIMAL  ada1 (SPARE)
                  ada0 (ACTIVE (ACTIVE))
```

Also tried `graid remove` with the same result.

I have a workaround by removing the geom_raid option, however it's unclear to me why having geom_raid loaded at boot time is causing the problem, and it would be nice to establish the reason, especially since this module is a feature of GENERIC.


----------



## Jimmy (Jun 25, 2013)

Ah ok, _I_ think I've figured it out, the syntax is:


```
[root@diesel /home/diesel/jim]# graid remove -v Promise ada0
Done.
[root@diesel /home/diesel/jim]# graid remove -v Promise ada1
Done.
```

`graid status` results in no further listings.

Very strange, I have no idea how the _RAID_ metadata ever got added. I have never tried to set[ ]up _RAID_ on these disks.

Thanks again.


----------



## wblock@ (Jun 25, 2013)

Manufacturer testing, maybe.  Unless you have a Promise controller, or these disks were bought used, that would be about the only possibility.


----------

