# panic, from 8.2-release to 9.0-release



## xwwu (Jan 13, 2012)

Dear friends:

I upgrade my server for 8.2-release to 9.0-release with freebsd-update. But after reboot, the system show me:


```
Can't open '/boot/menu.4th': no such file or directory

Consoles: internal vodeo/keyboard
BIOS drive C: is disk0
BIOS 635kB/1038976kB available memory

...

Can't work out which disk we are booting from
Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0

panic: free: guard1 fail @ 0x3f4b1df4 from /usr/src/sys/boot/i386/loader/../../common/mpdule.c:1016
```

Need your help urgently!

Regards!


----------



## tim-m89 (Jan 13, 2012)

Maybe this has something to with the ata cam switch over which I think may be default in 9. Prior to upgrade what was your fstab like? IE Where the drives listed like: ad10s1a, ada0s1a or by UFSID?


----------



## xwwu (Jan 13, 2012)

Thanks very much for your help.

The fstab is:


```
/dev/ad0s2b   none   swap  sw 0 0
/dev/ad0s2a   /      ufs   rw 1 1
/dev/ad0s2e   /tmp   ufs   rw 2 2
/dev/ad0s2f   /usr   ufs   rw 2 2
/dev/ados2d   /var   ufs   rw 2 2
```
It's is strange right now. There are 2 disks in /dev, ad0 and ada0. Even just only 1 disk in my server.

Waiting for your help.


----------



## SirDice (Jan 13, 2012)

```
20110424:
        The GENERIC kernels for all architectures now default to the new
        CAM-based ATA stack. It means that all legacy ATA drivers were
        removed and replaced by respective CAM drivers. If you are using
        ATA device names in /etc/fstab or other places, make sure to update
        them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
        where 'Y's are the sequential numbers starting from zero for each type
        in order of detection, unless configured otherwise with tunables,
        see cam(4)). There will be symbolic links created in /dev/ to map
        old adX devices to the respective adaY. They should provide basic
        compatibility for file systems mounting in most cases, but they do
        not support old user-level APIs and do not have respective providers
        in GEOM. Consider using updated management tools with new device names.

        It is possible to load devices ahci, ata, siis and mvs as modules,
        but option ATA_CAM should remain in kernel configuration to make ata
        module work as CAM driver supporting legacy ATA controllers. Device ata
        still can be used in modular fashion (atacore + ...). Modules atadisk
        and atapi* are not used and won't affect operation in ATA_CAM mode.
        Note that to use CAM-based ATA kernel should include CAM devices
        scbus, pass, da (or explicitly ada), cd and optionally others. All of
        them are parts of the cam module.

        ataraid(4) functionality is now supported by the RAID GEOM class.
        To use it you can load geom_raid kernel module and use graid(8) tool
        for management. Instead of /dev/arX device names, use /dev/raid/rX.

        No kernel config options or code have been removed, so if a problem
        arises, please report it and optionally revert to the old ATA stack.
        In order to do it you can remove from the kernel config:
            options        ATA_CAM
            device         ahci
            device         mvs
            device         siis
        , and instead add back:
            device         atadisk         # ATA disk drives
            device         ataraid         # ATA RAID drives
            device         atapicd         # ATAPI CDROM drives
            device         atapifd         # ATAPI floppy drives
            device         atapist         # ATAPI tape drives
```

But this shouldn't prevent the system from booting though. I had a custom kernel _without_ ATA_CAM and it booted fine. I then rebuild the custom kernel _with_ ATA_CAM and it booted fine too. After the last successful boot I modified fstab to reflect the changes.

In your case the boot process can't find /boot/menu.4th, which indeed doesn't exist. Did you change the boot menu at some point? Or any of the other .4th files?


----------



## xwwu (Jan 13, 2012)

Thanks, but /boot/menu.4th does exist.


----------



## tim-m89 (Jan 13, 2012)

xwwu said:
			
		

> Thanks, but /boot/menu.4th does exist.



On my system I have loader.4th which is referenced from loader.rc:


```
\ Loader.rc
\ $FreeBSD: src/sys/boot/i386/loader/loader.rc,v 1.4.14.1.2.1 2009/10/25 01:10:2
\
\ Includes additional commands
include /boot/loader.4th

\ Reads and processes loader.conf variables
start

\ Tests for password -- executes autoboot first if a password was defined
check-password

\ Load in the boot menu
include /boot/beastie.4th

\ Start the boot menu
beastie-start
```

Check your loader.rc file with any other way you access the filesystem.


----------



## SirDice (Jan 13, 2012)

If I remember correctly menu.4th is an old file from an older version of FreeBSD (even before 8.0).

Ok, I didn't remember correctly. The boot menu did have quite some changes over the years.

The menu.4th was added to HEAD and RELENG_9 so it should be there.

Did you run freebsd-update install twice?


----------



## xwwu (Jan 13, 2012)

SirDice said:
			
		

> If I remember correctly menu.4th is an old file from an older version of FreeBSD (even before 8.0).
> 
> Ok, I didn't remember correctly. The boot menu did have quite some changes over the years.
> 
> ...



Thanks, my loader.rc includes loader.4th also.
But I don't konw how to fixthis issue. It's urgent!
I just run install once and reboot as needed.


----------



## SirDice (Jan 13, 2012)

Tricky, as this prevents the system from booting. You could try booting a live CD and just copy that file. Hopefully the system will boot normally after that.


----------



## xwwu (Jan 13, 2012)

Thanks, I will try it.


----------



## xwwu (Jan 13, 2012)

It works! bootable already! If there are still some problems, I will ask you again. Thank you!


----------



## Sfynx (Jan 13, 2012)

Personally, I also tend to replace the master boot record (MBR) and partition bootcode just before rebooting the box after the kernel upgrade phase of freebsd-update... just to make sure they are in sync with the bootloader+kernel I just upgraded.


----------

