5:59 a.m.
Hello all,
I have just upgraded my desktop to F16 from F14 (I skipped F15 because the
live distro did not seem able to run gnome 3 on - now it does
apparently!).
I did a clean install (but with the existing /home partition) and copied
accross some config files (see below).
Now, although F16 works OK I notice it takes a veeeerrry looooong time to
boot. A little investigation led me to this:
[root@localhost ~]# systemd-analyze blame
60374ms mnt-NFSmark.mount
60369ms mnt-datastore.mount
60368ms mnt-stuff.mount
3819ms mdmonitor-takeover.service
....
Now this machine connects to a server running F15 on my home network
(192.168.2.2). This is the /etc/exports on that machine:
cat /etc/exports
/home/mark
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/tempstore
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/datastore
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/f11
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
The NFS drives on the F16 desktop PC (192.168.2.4) are mounted by /etc/fstab:
192.168.2.2:/home/mark /mnt/NFSmark nfs rw 0 0
192.168.2.2:/mnt/tempstore/ /mnt/stuff nfs rw 0 0
192.168.2.2:/mnt/datastore/ /mnt/datastore nfs rw 0 0
This was copied from the previous F14 install where it worked fine and
there were no such delays during boot.
Why does it now take so long?
How do I troubleshoot further, or - better yet - fix it?
Thanks in advance...
Mark
10:34 a.m.
New subject: Sloooow Boot [was NFS Mounting oddity...]
On Mon, 2011-12-05 at 19:42 +0000, Arthur Dent wrote:
On Mon, 2011-12-05 at 18:08 +0530, Soham Chakraborty wrote:
snip
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?
Dumb question - but how do I read the above dmesg output?
i.e. does the timestamp refer to the time that task started or the time
it completed?
I guess what I am asking is wast it the "em1: no IPv6 routers present"
that took 48 seconds or was it the SELinux line that was the culprit?
Apologies for asking such an elementary question but google turned up
lots of stuff about dmesg, but no answer to this specific question.
And further... How do I fix it!
Thanks again for the help so far...
Mark
1:42 p.m.
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
6:38 a.m.
On Mon, Dec 5, 2011 at 5:29 PM, Arthur Dent <misc.lists(a)blueyonder.co.uk>wrote:
Hello all,
I have just upgraded my desktop to F16 from F14 (I skipped F15 because the
live distro did not seem able to run gnome 3 on - now it does
apparently!).
I did a clean install (but with the existing /home partition) and copied
accross some config files (see below).
Now, although F16 works OK I notice it takes a veeeerrry looooong time to
boot. A little investigation led me to this:
[root@localhost ~]# systemd-analyze blame
60374ms mnt-NFSmark.mount
60369ms mnt-datastore.mount
60368ms mnt-stuff.mount
3819ms mdmonitor-takeover.service
....
Now this machine connects to a server running F15 on my home network
(192.168.2.2). This is the /etc/exports on that machine:
cat /etc/exports
/home/mark
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/tempstore
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/datastore
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/f11
192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
The NFS drives on the F16 desktop PC (192.168.2.4) are mounted by
/etc/fstab:
192.168.2.2:/home/mark /mnt/NFSmark nfs rw 0 0
192.168.2.2:/mnt/tempstore/ /mnt/stuff nfs rw 0 0
192.168.2.2:/mnt/datastore/ /mnt/datastore nfs rw 0
0
This was copied from the previous F14 install where it worked fine and
there were no such delays during boot.
Why does it now take so long?
How do I troubleshoot further, or - better yet - fix it?
Hi,
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.
Thanks,
Soham
Thanks in advance...
Mark
--
users mailing list
users(a)lists.fedoraproject.org
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
4539
days inactive
4540
days old
4 comments
3 participants
participants (3)
-
Arthur Dent -
Michael Cronenworth -
Soham Chakraborty