Error 19 after updating from FreeBSD 9.0 to FreeBSD 9.1

J

Jimmy

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:
Code: 
mountboot> ufs:/dev/ada0s1a

The above fails with error 19 and returns to the mountboot prompt, but if I actually issue:
Code: 
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.
 
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.
 
Jimmy said:
When I list available devices I can see an ada0, previously I was booting from ad4s1a.
Click to expand...
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.
Click to expand...

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.
 
I did google that link earlier but I'm not sure that the information contained within helps. Here are my disk layouts:

Code: 
[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:
Code: 
[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.
 
Ok I think it's caused by geom_raid. After reading your link on the changes to ATA, I inadvertently added
Code: 
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:
Code: 
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?
 
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?
 
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.
 
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.
 
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.
Click to expand...

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?
 
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.
Click to expand...
What happens if you load it after the system booted?

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

Code: 
[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.
 
Ah ok, I think I've figured it out, the syntax is:

Code: 
[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.
 
Manufacturer testing, maybe. Unless you have a Promise controller, or these disks were bought used, that would be about the only possibility.
 
You must log in or register to reply here.
Back
Top