10.0-BETA1 r256845 won't boot multi user

P

ph0enix

I updated my 10.0-BETA1 VM to r256845 and the system won't boot now. The kernel panics when it's about to load the CD-ROM driver as far as I can tell. I restored the VM from a backup that was 10.0-ALPHA5 and tried updating to the latest revision again this morning but it's having the same issue. I'm using the GENERIC kernel.

The following procedure was used to upgrade from BETA1:

Code: 
svnlite update /usr/src
cd /usr/src
make buildworld
make kernel kernconf="GENERIC"
make installkernel kernconf="GENERIC"
make installworld
shutdown -r

10.0-BETA1 worked great. I should probably mention that this is a Hyper-V VM running on Windows Server 2012. The system boots fine into single user mode. Is there a way to see what's causing the kernel to panic in multi-user mode exactly?

Thanks! :D

EDIT: Forgot to mention that SVN is pulling from the /stable/10 branch
 
You seem to have forgotten the mergemaster(8) step. That may change some default options that are set. Although I don't know what exactly changed.
 
Thanks, @SirDice! I just ran mergemaster -U and told it to update a bunch of files that I thought needed updating. The system booted fine after that. You're right! I used to skip mergemasteron previous versions of FreeBSD but I guess it the step has become more important now.

One thing I don't understand is why mergemaster wants to update /etc/group and /etc/master.passwd. That doesn't make sense to me.
 
Last edited by a moderator:
ph0enix said:
One thing I don't understand is why mergemaster wants to update /etc/group and /etc/master.passwd. That doesn't make sense to me.
Click to expand...

There are cases when those files have to be updated on OS upgrade because a new system user account has been added, the most recent example is the unbound user account on stable/10. Often the differences are only on revision control tags at the beginning of the files, those can be ignored.
 
kpa said:
Often the differences are only on revision control tags at the beginning of the files, those can be ignored.
Click to expand...
If you add the -F option to mergemaster it will update it automatically. But only if the only thing that changed was the revision control line.
 
mergemaster -Ui is effectively equivalent to mergemaster -FUi. In other words, -F is not needed, but don't ask me to explain it.
 
I have r256847:

Code: 
# uname -a
FreeBSD dotwall 10.0-BETA1 FreeBSD 10.0-BETA1 #1 r256847: Mon Oct 21 22:31:23 EEST 2013     root@machine:/usr/obj/usr/src/sys/GENERIC  i386

It works well under VirtualBox. So maybe it is something specific to your guest virtual machine or with x86 architecture (I am running i386)?

One thing, I only compiled kernel, the world is a little bit older (still BETA1 and not ALPHA).
 
wblock@ said:
mergemaster -Ui is effectively equivalent to mergemaster -FUi. In other words, -F is not needed, but don't ask me to explain it.
Click to expand...

-F If the files differ only by VCS Id ($FreeBSD) install the new file.
-U Attempt to auto upgrade files that have not been user modi-fied. This option can be dangerous when there are critical changes in the new versions that affect your running system.
Click to expand...
tl;dr: -F ignores the version header of the file (you can change this version in any way you'd like and it'll happily replace). -U will only replace files which haven't been modified at all.
 
wblock@ said:
mergemaster -Ui is effectively equivalent to mergemaster -FUi. In other words, -F is not needed, but don't ask me to explain it.
Click to expand...

Thanks! My issue was resolved after @SirDice's first response :)
 
Last edited by a moderator:
Never thought that by not using mergemaster a kernel and world update could cause a kernel panic. Maybe this happens just because it's beta.
 
You must log in or register to reply here.
Back
Top