I have an intermittent boot problem affecting my internet connection. I’m not sure whether to post it here or the Network/Internet forums, but decided to try here.
Sometimes when I boot (with my modem connected and powered), the connection is not recognised and the network icon in the taskbar remains off, ie has a small x against it. I’ve tried right clicking it but nothing helpful seems to appear. I find the only way I can connect is to reboot (which usually, but not always, works)
The same issue arises if I boot with the modem off, then subsequently turn it on. SUSe does not detect this, and I have to reboot in order to connect.
There must be an easy way of saying retry connection? But googling around hasn’t revealed it. Grateful for any help.
>
> I have an intermittent boot problem affecting my internet connection.
> I’m not sure whether to post it here or the Network/Internet forums, but
> decided to try here.
>
> Sometimes when I boot (with my modem connected and powered), the
> connection is not recognised and the network icon in the taskbar remains
> off, ie has a small x against it. I’ve tried right clicking it but
> nothing helpful seems to appear. I find the only way I can connect is
> to reboot (which usually, but not always, works)
What if you try left clicking the network manager icon in the system tray,
are you then able to select any connection.
Instead of rebooting you could try restarting the network manager service.
In a terminal as root do ‘rcnetwork restart’.
–
Niclas Ekstedt, CNA/CNE/CNS/CLS
Systems Engineer
Atea Sverige AB
By Sod’s Law, now I want the intermittent fault to occur it’s working perfectly! (and even detecting an off/on cycle of the modem). Nevertheless I tried your suggestion (turns out I most specify /sbin/rcnetwork restart), and certainly the network icon went to disconnected then back to connected.
If left click on the icon I get:-
Wired Auto (greyed out)
Auto eth0 (radio button, selected)
VPN connections > [Configure VPN …|Disconnect VPN (greyed out)]
none of which makes any sense to me
So I’ll have to wait for the fault to recur then post back my results. Thanks for such a quick response.
The intermittent problem resurfaced this morning, as intermittents tend to.
I tried ‘sudo /sbin/rcnetwork restart’ and ‘sudo /sbin/rcnetwork reload’ (several times) but to no avail. Also ‘sudo /sbin/rcnetwork stop’ followed by ‘sudo /sbin/rcnetwork restart’
Right clicking on the nework icon in the task bar gave me the options:-
Enable Networking (ticked)
Connection information (greyed out)
Edit connection …
About
I went to Edit Connection, and was presented with a tabbed dialog box, of which the only populated tab was ‘Wired’, In this tab was the line ‘Auto eth0’, and to the right of it the word ‘never’ in grey. All the options in the dialog were greyed out.
So I’m just as confused as ever. Once again rebooting cured the problem (else I couldn’t post this message), but of course now I cannot recreate the error conditions.
obviously, something is happening in one boot sequence that is not
happening always…so, to find the solution (and remove the symptom)
you must first find the problem…
one way to do that is to inspect the logs…
when you boot, a file named boot.msg is generated in /var/log and the
existing (from the previous boot) is renamed to boot.omsg (old
message), so if you boot again and it is broken…i’d immediately copy
/var/boot.msg to /[somewhere]/boot.msg.networking.BROKEN and
/var/log/boot.omsg to [somewhere]/boot.omsg.networking.WORKING and use
some tool (like diff to discover what is different…
[if it is now working, after ONE boot from a broken boot, you can do
similar, but boot.msg is boot.msg.WORKING and boot.omsg is
boot.omsg.BROKEN follow that?]
additionally, there may be clues inside the log file named
/var/log/messages…that file contains many days of logs…each line
beginning with a date/time…look though it for errors and warnings
during the SHUTDOWN preceding the troublesome startup, and then in the
beginning logging of the new broken system…
and, compare those to the shut down preceding a GOOD session, and the
start up of a good new session
somewhere, in there you might/should/probably will find a hint of what
the problem child is…THEN you can come back here and tell us what
the problem is, and maybe someone can help you fix it…
–
goldie
Give a hacker a fish and you feed him for a day.
Teach man and you feed him for a lifetime.
OK. I’ve got the boot logs from a ‘good’ and a ‘bad’ boot (both this morning), and tried comparing the two …
They are broadly in line for the first 400 lines or so, but then they diverge, and I don’t understand the significance of each line. There are far too many lines to post here, but clutching at straws, the ‘bad’ boot has a line
/dev/disk/by-id/ata-Hitachi_HDP725050GLA360_GEC564RJ19BG2J-part3 was not cleanly unmounted, check forced.
I don’t know why the disk was not cleanly unmounted; as far as I recall each time I have shut down via the system shutdown menu, but could this be a pointer to the problem?
> I don’t know why the disk was not cleanly unmounted; as far as I recall
> each time I have shut down via the system shutdown menu, but could this
> be a pointer to the problem?
certainly it could be a pointer (assuming that is the ONLY difference
between the good and the bad)
do you ever shut down any other way? if so: STOP THAT!
and, if your intermittent problem then goes away you know why.
look at /var/log/messages at the shut down sequence BEFORE the next
boot’s forced check (which will be BAD message section)…and compare
it to the shutdown sequence which did not then cause a forced check
(which is GOOD) and i think you might find out what caused the Hitachi
to have not cleanly shutdown…
remember: the “messages” file can run for days, maybe months…so, you
have to find the good and bad shutdown sections by looking at the
date/time…
now, that hitachi, it doesn’t happen to be in a USB enclosure…is it?
