Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Oct 2013 18:58:52 -0700
From:      Doug Hardie <bc979@lafn.org>
To:        dweimer@dweimer.net
Cc:        freebsd-questions@freebsd.org
Subject:   Re: 9.1 - 9.2 upgrade
Message-ID:  <2B420332-D26F-4926-A53A-787B110B0EFE@lafn.org>
In-Reply-To: <1bdf3856902efd917ab9d489c8b6e751@dweimer.net>
References:  <B5D4B829-3B73-4E5F-BA69-6DFA0F129975@lafn.org> <BCEB7B13-2084-4D4E-9F89-19F29EFBCC54@lafn.org> <62A8B684-0328-42F5-B9E4-D5DF80563D4D@lafn.org> <1bdf3856902efd917ab9d489c8b6e751@dweimer.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On 4 October 2013, at 09:22, dweimer <dweimer@dweimer.net> wrote:

> On 10/04/2013 1:36 am, Doug Hardie wrote:
>> On 3 October 2013, at 11:48, Doug Hardie <bc979@lafn.org> wrote:
>>> On 3 October 2013, at 10:49, Doug Hardie <bc979@lafn.org> wrote:
>>>> I just did an upgrade using freebsd-update to 9.2.  This system =
uses a custom kernel so I am rebuilding everything after the update =
completed.  However, I noticed that /usr/src/UPDATING has not been =
updated.  The first entry still says:  9.1-RELEASE.  Is this correct?
>>> Well, it just got worse - The last reboot now fails:  I am using a =
remote console and it shows:
>>> --> Press a key on the console to reboot <--
>>> Rebooting...
>>> Consoles: internal video/keyboard  serial port
>>> BIOS drive A: is disk0
>>> BIOS drive C: is disk1
>>> BIOS 639kB/2087360kB available memory
>>> FreeBSD/x86 bootstrap loader, Revision 1.1
>>> (doug@zool.lafn.org, Thu Oct  3 04:23:13 PDT 2013)
>>> 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 @ 0x7f481ed0 from =
/usr/src/sys/boot/i386/loader/../../common/module.c:1004
>>> --> Press a key on the console to reboot <--
>>> I can enter a string as it doesn't try to reboot again till the =
return is entered.  I've tried b disk1, but it still only tries disk0.  =
The system rebooted fine after the reboot after make kernel.  =
Mergemaster didn't seem to affect anything dealing with boot.  Don't =
know what make delete-old does but the descriptions lead me to not =
believe it could cause this.  This system is on the other side of LA =
from me so its a major trip timewise.  Any ideas how this can be =
recovered remotely?
>> Booting off the live CD didn't find anything obviously wrong.  I
>> replaced the kernel with the old one and still the same error.  I am
>> having the drive mailed to me and will work with it here.  However, =
it
>> appears a new install is going to be required.  The old sysinstall =
had
>> the capability to skip over the formatting of the disk by just
>> entering quit.  It would then just replace the system components and
>> leave everything else alone.  I don't see any obvious way to do the
>> same thing with bsdinstall.  Is there a way to do that.  I don't want
>> to have to completely rebuild the drive, but just replace the system.
>> _______________________________________________
>> freebsd-questions@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to =
"freebsd-questions-unsubscribe@freebsd.org"
>=20
> Just want to clarify the steps that started this
>=20
> if I read everything right:
>=20
> Step 1:  freebsd-update from 9.1 to 9.2
> Step 2:  compile from source ?  Was this world, or just the custom =
kernel??
> Step 3:  make delete-old
> Step 4:  mergemaster
> Step 5:  reboot
> oops, something went wrong..
>=20
> If my suspicions are correct, the source was still 9.1 patch 7,  but =
the system was running 9.2 from the binary update.  This may have caused =
the make delete-old to delete things it shouldn't have
>=20
> The very first thing I would do is bring the disk up in another system =
and make a backup copy of the data.
>=20
> I have never tried this process, I am basically just taking the steps =
I use for updating a zfs system using boot environments, and applying =
them in order to build a new kernel and world to an alternate directory, =
as a method of recovering the system.
>=20
> The next step I would take is to then mount the file systems in an =
alternate location, /mnt for example
>=20
> make MAKEOBJDIRPREFIX /mnt/usr/obj
> make DESTDIR /mnt
> cd /mnt/usr/src
> rm -r * .svn
> rm -r /usr/obj/*
> svn co https://svn0.us-west.freebsd.org/base/releng/9.2
> make buildwolrd
> make buildkernel
> make installkernel
> make installworld
> make -DBATCH_DELETE_OLD_FILES delete-old
> make -DBATCH_DELETE_OLD_FILES delete-old-libs
> mergemaster -Ui /mnt/usr/src -D /mnt
>=20
> With some luck the file system will now contain a boot-able FreeBSD =
install, that will still have all the settings in place, except it will =
be the generic kernel.  You should then just be able to build and =
install the custom kernel, from the booted system as you normally would.
>=20

The exact sequence was:

Step 1:  freebsd-update from 9.1 to 9.2
Step 2:  make buildworld
Step 3:  make build_kernel KERNCONF=3DLAFN
Step 4:  make install_kernel KERNCONF=3DLAFN
Step 5:  reboot
Step 6:  mergemaster -p
Step 7:  make installworld
Step 8:  mergemaster -i
Step 9:  make delete-old
Step 10:  reboot
oops, something went wrong..

After step 5, uname -a still showed 9.2 but now it listed the kernel I =
built rather than generic.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2B420332-D26F-4926-A53A-787B110B0EFE>