On 4 October 2013, at 09:22, dweimer <dwei...@dweimer.net> wrote: > On 10/04/2013 1:36 am, Doug Hardie wrote: >> On 3 October 2013, at 11:48, Doug Hardie <bc...@lafn.org> wrote: >>> On 3 October 2013, at 10:49, Doug Hardie <bc...@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 >>> (d...@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-unsubscr...@freebsd.org" > > Just want to clarify the steps that started this > > if I read everything right: > > 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.. > > 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 > > The very first thing I would do is bring the disk up in another system and > make a backup copy of the data. > > 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. > > The next step I would take is to then mount the file systems in an alternate > location, /mnt for example > > 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 > > 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. >
The exact sequence was: Step 1: freebsd-update from 9.1 to 9.2 Step 2: make buildworld Step 3: make build_kernel KERNCONF=LAFN Step 4: make install_kernel KERNCONF=LAFN 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. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"