openSUSE 12.1 only starts up in console text mode after install

I’ve run out of options right now because I installed 12.1 x64 about 3 times again and always get the same result: Everything is fine with install DVD an installation procedure. The final step is loading all online updates. After reboot the system brings up the green screen and lets me wait for approx. 3 minutes - then goes into fallback console mode. I haven’t seen any graphical desktop any more and the network is not powered up.

I repeated the installation because of this posted network issue. Thus I replaced the onboard Realtek RTL 8111 LAN by a PCI-e addon board with a newer RTL 8111 chip.

The PC is a Windows 7 multiboot Intel Core i7 860 @ 2.80GHz with 4GB RAM, Nvidia GTX 285 graphics card.

The network is configured with static IP and ifup traditional method (so I can power it up manually when being in console mode).

On the text display I see the following first three lines:

doing fast boot
Creating device nodes with udev
udevd[324]: failed to execute ‘/etc/sysconfig/network/scripts/ifup-sysctl’ ‘/etc/sysconfig/network/scripts/ifup-sysctl lo -o hotplug’: No such file or directory

I don’t know those udev things and need an advice to continue/do further research…


At the boot screen
Press F5 and try selecting systemV

or try selecting the Failsafe Boot option

Do either of those make any difference?

I’ll try after work and give you feedback…

The Failsafe Boot option doesn’t work either. It’s very verbose and I can see that it doesn’t get a link on eth0. So the network interface remains being down. In emergency mode I can ifup eth0 manually - but entering normal mode shuts eth0 down immediately. When I try to change network settings with yast2 changes are saved and yast2 insists to configure smpppd. At this point the system hangs for approx. 2 mins. and returns from smpppd configuration at 90%. It simply doesn’t work and I don’t have an idea what smpppd is needed for. My network board is directly connected to a 1GBit/s switch which is connected to a DSL-b-router - so no dialing is in effect.

Your second idea did the kick: F5 and booting with System V worked immediately. I’m in KDE4 right now. Thanks :slight_smile:

The question is about the next step:

  1. does it make sense to make System V the default boot mode?
    If yes, how to make it change permanently to that mode in standard start configuration and Fail Safe option?

  2. is there a chance to find the problem with the standard boot option?
    I think this does make sense because I’ve found a lot of postings where network problems are an issue with 12.1

You could check the log at /var/log/messages
To copy it to your /home

sudo cat /var/log/messages > /home/*yourusername

  1. thx a lot, that works :slight_smile:

  2. I went back to the standard default and had a deep look into the /var/log/messages file:
    Finally I realized that the system didn’t start the network because it gave up at another point that I never saw before. After the main installation I added one entry into /etc/fstab from my old 11.1 system file backup. It is a eSATA disk which is normally powered off. In the messages file I found many retries occuring on this device. While not possible mounting it the system quits normal mode and enters emergency mode.

So I added the nofail option in /etc/fstab for the failing eSATA device. I didn’t know this option before because it wasn’t necessary in 11.1 - and it is obviously not necessary on 12.1 with the System V boot init option.

Now the system works with both boot options, not realizing what the System V init actually does. Nevertheless I let it at default boot … and it seems there is nothing wrong with the network board. rotfl!

From Product highlights - openSUSE

with more detail here: Product highlights - openSUSE

System V (sysV-init) was the older system I believe.

Reads like the new “Systemd” as implemented has a bug here ? (which does not impact the older ‘sysV-init’ ? )

I’m wondering if a bug report is appropriate ?

This is harmless - didn’t say it’s normal. lo is the loopback interface, not a physical device. Once the system has booted, lo will be available. I see that error on all machines booting in systemd. If a physical nic fails to be detected in time, you can increase the value of WAIT_FOR_INTERFACES in /etc/sysconfig/network/config. If you’re running samba, you might have a different problem, but you didn’t mention it.

It seems that you solved the problem by switching to system V. It’s another possibility.

Thanks, good to know. I don’t use samba (for now) even if I installed it. In fact I installed all of the available packages except AppArmor, LDAP and mobile computer related stuff.

In the situation while it was not working I even increased WAIT_FOR_INTERFACES to 180 and that didn’t make it.

No, not by switching to System V. As described in my previous post it works with both systemd init and System V init. The only difference is that the systemd init mode stops the init process on a non-existent SATA device from /etc/fstab. In other words: the nofail option in a /etc/fstab entry is necessary for systemd while it isn’t for System V.

I’m not sure if this behaviour can be treated as a bug. If systemd depends on bus-activated devices and a device entry in /etc/fstab doesn’t exist (because it is hotpluggable and currently offline) it’s maybe necessary having all these devices present. It should be mentioned somewhere that the nofail option in /etc/fstab is needed for optional devices.

Well, I didn’t try yet if the failing disk is recognized when I put it online. However it should be treated like a CD/DVD device.

It is in the mount man page (since it is a mount option).

Yes, you’re right - and also in the fstab man page. I meant a stronger advice to do so … since I’m using SUSE distros since 4.3 and never had this mess before. I had no idea that using systemd implies a different behaviour on disk devices.

It took me more than three weeks to find the real source for the problem as it looked like a failure of the onboard LAN chip and even replaced it by an addon LAN board. Worse than that is that I’ve spent five installations of three different Linux distros which I have written on my SSD again and again so that I hope its life cycle did not take harm >:(

As it is working fine now (with the original onboard LAN too) my final question is: Should the systemd behaviour treated as an error and therefore a bugzilla placed or not?

I got a similar problem with a totally different cause. You could assume that if NICs don’t work in systemd, that’s because of something else.

So then it’s really worth a bugzilla I think - I only don’t know to define the “something else”. :frowning:

You have to figure out what it is. In my case, it was the nmb daemon: