On Mon, 2011-12-05 at 18:08 +0530, Soham Chakraborty wrote: > [Snip previous problem identification] > > > This could be related to the network card initializing itself later > at the boot process while in the earlier steps, it has marked itself > as active. I have seen incidents like this. > > > Is it possible for you to mount all the NFS mounted FS at the last > stage of the boot process. Possibly creating a rc.local file, making > it executable and do the NFS mounts from it. This can be one step of > debugging. > > > Another can be to simply add _netdev option in the NFS exports and > check whether it improves things. > > > This is all what I can think of now. Well thanks for this. I think now that the NFS mounting may actually be a red-herring - but you set me on to some more detailed troubleshooting. I did 4 very unscientific tests. I started from a cold reboot and measured the time from pressing the switch to the appearance of the GDM login screen with a stopwatch on my phone (don't phone the Nobel prize people just yet...). Tests were: Test 1) As is - i.e. NFS mounts in fstab as previously described Test 2) Not mounting the 3 NFS mounts at all (i.e. commenting out from fstab) Test 3) Mounting NFS from fstab but with _netdev option Test 4) Attempting to mount NFS drives from rc.local (note - I never got this to work) Results: Test 1: 0:59.2 Test 2: 0:57.8 Test 3: 1:54.2 Test 4: 0:58.9 (Note: All times include the 5s grub pause which I haven't removed yet) However, something didn't seem right - after all the "as is" test seemed just fine (under a minute including the 5s grub pause is quite acceptable) but the long test 3 exhibited the behaviour I had noticed before - the white tear-drop disappears for a while leaving an alarming black screen - eventually returning as the blue "F" for Fedora logo and then proceeding to the GDM screen. So I repeated some tests: Test 3 - repeat 1: 1:55.0 Test 1 - repeat 1: 1:58.7 Test 1 - repeat 2: 1:59.5 Test 1 - repeat 3: 0:56.4 Test 1 - repeat 4: 1:56.0 So the long boot times (c. 2 mins) seem to be random, given no changes in configuration. I looked at dmesg. I am no expert in what dmesg tells me, but here is the last few lines of one of the long boots: ===============8<==================================== [root@localhost ~]# dmesg [ snip ] [ 32.248789] e1000e 0000:00:19.0: em1: 10/100 speed: disabling TSO [ 32.248955] ADDRCONF(NETDEV_CHANGE): em1: link becomes ready [ 42.354015] em1: no IPv6 routers present [ 90.858903] SELinux: initialized (dev 0:21, type nfs4), uses genfs_contexts [ 90.863622] SELinux: initialized (dev 0:22, type nfs4), uses genfs_contexts [ 90.867429] SELinux: initialized (dev 0:23, type nfs4), uses genfs_contexts [ 90.868787] SELinux: initialized (dev 0:24, type nfs4), uses genfs_contexts [ 90.872920] SELinux: initialized (dev 0:22, type nfs4), uses genfs_contexts [ 90.877188] SELinux: initialized (dev 0:25, type nfs4), uses genfs_contexts [ 90.878883] mount[998]: mount.nfs: /mnt/NFSmark is busy or already mounted [ 90.887451] SELinux: initialized (dev 0:22, type nfs4), uses genfs_contexts [ 90.927896] SELinux: initialized (dev 0:21, type nfs4), uses genfs_contexts [ 90.932400] SELinux: initialized (dev 0:22, type nfs4), uses genfs_contexts [ 92.714872] [drm:drm_debugfs_create_files] *ERROR* Cannot create /sys/kernel/debug/dri/channel\xfffffff0i\xffffff80]\xffffffc0\x03/3 [ 95.940096] [drm:drm_debugfs_create_files] *ERROR* Cannot create /sys/kernel/debug/dri/channel\xffffffe9i\xffffff80]\xffffffc0\x03/3 [root@localhost ~]# ===============8<==================================== On the successful boots dmesg ends with the "no IPv6 routers present" line at around 44s. What is this telling me and how do I fix it? Thanks again... Mark
Attachment:
signature.asc
Description: This is a digitally signed message part
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
