fsck trying to mount the FQDN at boot?
I did a flash archive install of Solaris 9 - 905 on a Sun v440 that is attached to a HP X12000 SAN. The original archive is of a v440 that is attached to a 3510. Everything went fine, but every time I boot the system I get the following:
checking ufs filesystems
fsck: dhcp192a.bedrock-dev-lab.example.net: No such file or directory
Dec 7 21:15:11 fsck: dhcp192a.bedrock-dev-lab.example.net: No such file or directory
/dev/rdsk/c3t50060E8004299610d1s6: is logging.
/dev/rdsk/c3t50060E8004299610d0s6: is logging.
/dev/rdsk/c1t0d0s5: is logging.
/dev/rdsk/c1t0d0s4: is logging.
wait: No child processes
WARNING - Unable to repair one or more filesystems.
Run fsck manually (fsck filesystem...).
Exit the shell when done to continue the boot process.
Typing control-d resumes boot and everything come online like it should. The vfstab looks fine, no control characters, no extra lines or fields. I'm not sure what the system is reading at this point of the boot to get this error.
Anyone have an idea?
TIA.
[1109 byte] By [
AltGrendel] at [2007-11-26 12:00:10]
# 1
Can you get similar output just by typing 'fsck -n' at a prompt?-- Darren
# 2
No, it's normal with no errors.
# 3
Okay, so where is it coming from?...
This is *slightly* dangerous if you screw up, but it can yield a lot more information.It is most likely that this is happening in run level 2. (can you confirm this? If you do a single-user boot, does it happen? After you exit single-user does it?)
Make a backup copy of /sbin/rc2 and edit the file. You'll see the section where it launches all the S* scripts. We want to insert some echos to verify which script is involved.
Find the following section and add the two echo lines: (note this is the S* section and not the K* section).
for f in /etc/rc2.d/S*; do
echo Starting $f
if [ -s $f ]; then
case $f in
*.sh).$f ;;
*)/sbin/sh $f start ;;
esac
fi
echo Completed $f
done
Now when you boot, you'll know which script is running. Find out the one responsible for the message, and we can poke at it next.
If you screw something up so that the machine can't boot, just do a single-user boot, move the backup copy of /sbin/rc2 back into place and you should be able to boot up.
If the messages occur before single-user, then you have to do this to /sbin/rcS.
--
Darren
# 4
Here's the output from that.
Starting /etc/rc2.d/S01MOUNTFSYS
Dec 8 18:17:53 spagent[96]: Starting spagent.
checking ufs filesystems
fsck: dhcp192a.bedrock-dev-lab.example.net: No such file or directory
Dec 8 18:17:59 fsck: dhcp192a.bedrock-dev-lab.example.net: No such file or directory
/dev/rdsk/c3t50060E8004299610d1s6: is logging.
/dev/rdsk/c3t50060E8004299610d0s6: is logging.
/dev/rdsk/c1t0d0s5: is logging.
/dev/rdsk/c1t0d0s4: is logging.
wait: No child processes
WARNING - Unable to repair one or more filesystems.
Run fsck manually (fsck filesystem...).
Exit the shell when done to continue the boot process.
Type control-d to proceed with normal startup,
(or give root password for system maintenance): resuming mountall
Completed /etc/rc2.d/S01MOUNTFSYS
# 5
I know you said there's nothing about this in the vfstab, but can you post the contents?
You might consider adding a 'set -x' to the top of the S01MOUNTFSYS file. I'm assuming it's all being done by the '/sbin/mountall -l' line, but I don't understand why the difference when it's run later by hand.
--
Darren
# 6
Here it is:
#device device mountFSfsckmountmount
#to mountto fsck pointtypepassat boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs1yes-
fd-/dev/fd fd-no-
/proc-/procproc-no-
/dev/dsk/c1t0d0s1--swap-no-
/dev/dsk/c1t0d0s0/dev/rdsk/c1t0d0s0/ufs1no-
/dev/dsk/c1t0d0s7/dev/rdsk/c1t0d0s7/varufs1no-
/dev/dsk/c1t0d0s4/dev/rdsk/c1t0d0s4/optufs2yes-
/dev/dsk/c1t0d0s5/dev/rdsk/c1t0d0s5/opt/oracleufs2yes-
/dev/md/dsk/d10 /dev/md/rdsk/d10/custufs2yes-
# /dev/dsk/c1t0d0s6/dev/rdsk/c1t0d0s6/oracle ufs2yes-
/dev/dsk/c3t50060E8004299610d0s6/dev/rdsk/c3t50060E8004299610d0s6/oracle/db01ufs2yes-
/dev/dsk/c3t50060E8004299610d1s6/dev/rdsk/c3t50060E8004299610d1s6/oracle/db02ufs2yes-
swap-/tmptmpfs-yes-
I think that I've got it down to the section of mountall that calls the fsckall programs. I'm not sure why that's an issue though.
# 7
Well, I'll be very interested in whatever you do finally track down. Also in why it affects startup but not commandline usage later. -- Darren
# 8
Update:
We've tracked this down to the fsck command. If I manually run fsck as the mountall script does I get the same error:
/usr/sbin/fsck -o p /dev/md/dsk/d8
fsck: dhcp192a.bedrock-dev-lab.example.net: No such file or directory
Dec 12 01:10:51 fsck: dhcp192a.bedrock-dev-lab.example.net: No such file or directory
wait: No child processes
However, if I use the version in /usr/lib/fs/ufs, it works fine:
/usr/lib/fs/ufs/fsck -o p /dev/md/rdsk/d8
/dev/md/rdsk/d8: is logging.
Any ideas why this might be?
# 9
Difficult to guess at the moment.
I would get a truss and see if anything popped out..
'truss -af -o /tmp/truss.out /usr/sbin/fsck -o p /dev/md/rdsk/d8', then examine the file and see if anything "strange" is there. Of course in a normal machine I would expect it to find that the filesystem is 'ufs', which causes it to run a copy of '/usr/lib/fs/ufs/fsck'. (Look for the string 'argv' in the truss output).
However, there are two things that pop out at me.
#1 I asked to see the full copy of your vfstab, but the one that you posted doesn't have a 'd8' line. Why is it running fsck on that device if it's not in the file?
What does 'grep d8 /etc/vfstab' show? If the fs type wasn't 'ufs', then it's going to run a different fsck.
#2 The 'fsck' device should md/rdsk, not md/dsk. Again, because there's no such line in the posted file, that can't be verified.
--
Darren
# 10
Also i noticed that in the example above, you ran
/usr/sbin/fsck on /dev/md/dsk/d8
but the lib/fs/fsck on /dev/md/rdsk/d8 .
Perhaps you have accidently deleted the /dev/md/dsk/d8 link and instead pointed it to your hostname?
Could you run
ls -l /dev/md/dsk/d8
as well?
.7/M.
# 11
Final Update:Looks like we were hitting this bug, http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6273536Applying the work around has allowed the system to come up without manual intervention.
# 12
Huh. It certainly shares some characteristics with your issue, but not all. I still wonder where it was picking up the FQDN from. I don't see anything in the bugs about misinterpreting the device.Glad the workaround is functioning for you, though.-- Darren
