Weird experience after portupgrade

I'm using FreeBSD 8.2 RC2 on a Dell E520 desktop.
Everything is running fine.
Then I ran this command which took over 24 hours to complete.
Code:
# portupgrade -af
When it did complete, I rebooted but the boot stopped when a number of lines dealing with the mouse and keyboard (ukbd0, ums0) were displayed with the final line being
Code:
ugen5.2; <vendor 0x046d> at usbud5
I use a Logitech MK250 wireless keyboard and mouse.
At this point I did a hard power off when the following lines appeared on the screen
Code:
eval: cannot create /var/db/mixer0-state  : no such file or directory
eval: cannot create /var/db/mixer1-state  : no such file or directory
But the reboot went fine and I got to the GUI without any problem.
However, all was not well on the Desktop as
i) the mouse pointer persisted showing the watch rather than an arrow
ii) compiz-fusion didn't launch
iii) worst of all, I was unable to type anything on a terminal or text editor as it seems I could never get focus on these windows.
Nevertheless, nearly everything else worked on the Desktop.
As I thought the problem may be due to a corrupted nVidia 3D driver (gfx card is nVidia GeForce 7300 LE), I downloaded the driver NVIDIA-FreeBSD-x86-260.19.36 from the nVidia site.
Then I switched to a tty and tried to install the nVidia driver as root.
However, it errored out with the message
Code:
Failed to unload NVIDIA module: Is nvidia.ko in use?
Thinking that the install might have failed because I hadn't correctly shutdown X, I ran the command
Code:
pkill -15 Xorg
The screen went black for a few seconds and the greeting screen reappeared.
I logged in and got to the Desktop where EVERYTHING was normal -- compiz running in 3D, AWN dock launched, no problem writing to terminal or text editor windows. And it's still OK after several reboots.

Can anybody help me understand what might have happened here?
 
Did you read /usr/ports/UPDATING before starting portupgrade?
 
SirDice said:
Did you read /usr/ports/UPDATING before starting portupgrade?
Thank you for your reply.
Yes, I did read it, at least the latest entries.
However, even looking through it again afterwards, I see nothing of relevance to my weird upgrade experience.
Should I?
 
The description in post #1 sounds like a reboot in single user mode; USB messages often appear after the "press Enter for a shell" prompt, obscuring it. Then there were problems because it was doing a background fsck, then after it finished everything was fixed. Just guessing, though.
 
Thank you for the reply
wblock said:
The description in post #1 sounds like a reboot in single user mode; USB messages often appear after the "press Enter for a shell" prompt, obscuring it.
Ah, that's interesting because I actually "tried" to get into single-user mode after my failed first boot attempt. But, as I couldn't see the shell prompt, I hard rebooted. I didn't mention this as I didn't think it was relevant.
there were problems because it was doing a background fsck, then after it finished everything was fixed.
But what would have triggered the fsck?
Remember that the fix occurred only after I had changed from the malfunctioning GUI to a tty with the intention of installing the nVidia 3D driver. AFAIK, in this condition, all of the slices would still have been mounted and, therefore, unfixable by fsck.
Nevertheless, it's interesting that whatever happened is not known to experienced users such as yourself.
 
paulfxh said:
But what would have triggered the fsck?

Unexpected powerdown, usually. But what triggered that? Power supply problem, heat problem, RAM problem, cosmic ray in the wrong place...

Remember that the fix occurred only after I had changed from the malfunctioning GUI to a tty with the intention of installing the nVidia 3D driver. AFAIK, in this condition, all of the slices would still have been mounted and, therefore, unfixable by fsck.

Background fsck starts automatically one minute after boot unless it's been disabled, and runs on mounted filesystems, fixing what it can.
 
wblock said:
Background fsck starts automatically one minute after boot unless it's been disabled, and runs on mounted filesystems, fixing what it can.
Thanks. I was unaware of this. However, on checking in my /etc/rc.conf, there is no entry for fsck_y_enable. I suppose I should add it now that I know but how would fsck have started automatically in its absence?
 
Code:
[~]% grep fsck /etc/defaults/rc.conf

fsck_y_enable="NO"      # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags=""         # Additional flags for fsck -y
background_fsck="YES"   # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
 
rusty said:
Code:
[~]% grep fsck /etc/defaults/rc.conf

fsck_y_enable="NO"      # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags=""         # Additional flags for fsck -y
background_fsck="YES"   # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.

Thank you for this information. However, on my computer the file /etc/defaults/rc.conf contains no reference whatsoever to fsck and I have not edited it out. How did that get left out or should I have "known" to include it there myself?
 
Code:
$ wc -l /etc/defaults/rc.conf                                                                                            
     701 /etc/defaults/rc.conf

I usually don't ask guys this, but how long is yours?
 
DutchDaemon said:
Code:
$ wc -l /etc/defaults/rc.conf                                                                                            
     701 /etc/defaults/rc.conf

I usually don't ask guys this, but how long is yours?

Well, my /etc/defaults/rc.conf also has 701 lines. But, I've now found the fsck lines exactly as indicated in rusty's post. OK, I'd better explain how I messed up.

The first time I looked, I opened cat /etc/defaults/rc.conf in a terminal not knowing the file had 701 lines. As this is more than the terminal can hold, the terminal search function didn't find any fsck.

Lame excuse I know but .................

Anyway, looks like everything is OK on my system. Thanks to everybody for the advice and tips.
 
By "terminal search" you mean the scrollback buffer? The size of that buffer can be increased, but really, let the computer do the work with grep(1) or, better for this application, less(1). That would be
Code:
% less /etc/defaults/rc.conf
-i
/fsck
 
Before somebody jumps on me, you can also set those options on the command line, and even start the search:
% less -i +/fsck /etc/defaults/rc.conf
 
Back
Top