openSUSE 13.1 configuration stalls on Asus Eee PC 1015PEM

English Install/Boot/Login
#1

Hi,

I have been trying to install openSUSE 13.1 x86_64 on my Asus Eee PC 1015PEM for a couple of days, but the installation systematically stalls either

  • during the auto-configuration step at 3%(top)/11%(bottom) (if auto-conf is enabled), or
  • during “check installation” “Preparing the initial system configuration” (if auto-conf is disabled).

I am using the network installation, and I tried both with and without additional update and non-OSS repositories, but the same effect occurs in both cases.

This PC previously had openSUSE 11.4 installed and working fine. This is a new installation in a distinct partition, and the old 11.4 still works fine. So it seems to be a problem specific to the (openSUSE 13.1 / Asus Eee PC 1015PEM) pair.

Did anyone get the same problem? Any idea how to solve this?

Thanks & kind regards,
Gilles

#2

Am I the only one having such problems? :frowning:

#3

This might be unrelated.

On installing 13.1RC2, I ran into some problems which are documented in Bug 848803.

Briefly, I installed with the DVD. I set the installer to add online repos during the install.

When done, I did not have any network. The adding of online repos during install wanted to call my ethernet card “p5p1” while the installed system wanted to call it “enp4s0”. The conflict seemed to be a problem.

For the final install, I avoided adding online repos, and all was fine. However, tests showed that the same problem would likely have occurred if I had added online repos. I only ran into this on one box.

I don’t know if it applies to your problem. It would not surprise me that a network install might run into this.

Have you tried setting it to use NetworkManager? Since that does not depend on device names, it is less likely to run into the problem.

#4

My Asus eeepc works fine
I’ll have to post the spec later but it sounds to be close to what you have

#5

For the record
Mine: 1015PEM

Everything works

Here is my hardware, you never know, something might be different

00:00.0 Host bridge [0600]: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge [8086:a010] (rev 02)	Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
	Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
	Kernel driver in use: i915
00:02.1 Display controller [0380]: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a012] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ce]
	Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 02)
	Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 02)
	Kernel driver in use: pcieport
00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 4 [8086:27d6] (rev 02)
	Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: uhci_hcd
00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: uhci_hcd
00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: ehci-pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)
00:1f.0 ISA bridge [0601]: Intel Corporation NM10 Family LPC Controller [8086:27bc] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: lpc_ich
00:1f.2 SATA controller [0106]: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] [8086:27c1] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
	Kernel driver in use: ahci
01:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8132 Fast Ethernet [1969:1062] (rev c0)
	Subsystem: ASUSTeK Computer Inc. Device [1043:838a]
	Kernel driver in use: atl1c
02:00.0 Network controller [0280]: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090]
	Subsystem: AzureWave Device [1a3b:1087]
	Kernel driver in use: rt2800pci
#6

I have been having the same issue with my work machine, dell latitude e6530. I used the same installation process I used on my two home machines, lenovo h505s & asus laptop, but it runs into this issue on the work computer and not the home computers. I’m going to try not loading the online repositories and see if that will clear up the issue as I’ve tried every other option available.

#7

I just tried the installation again without having the dell latitude e6530 connected to the docking station and without installing the online repos. I’m also using the network installation method. The installation still stalls at ‘check installation’.

#8

Enter the BIOS settings and disable the floppy drive if possible (especially if you don’t have one).

You could also try to disable the wireless (either in the BIOS or via the hardware switch). I’ve heard of occasions where that could cause the installation system to freeze.

#9 
Installing again with all wireless devices disabled via BIOS (I had already disabled the floppy in previous attempts). Even though wireless was turned off via the wireless switch on the computer, it would seem that disabling it via BIOS is the only sure option. I did not have to actually re-install from scratch. I continued the previous installation that was stalled and installation completed.
To note here, this last installation attempt (that finally succeeded) was not done via network installation. I had downloaded the full ISO and burned it to DVD. It appears that no matter the installation method, stalling will occur on some machines if the wireless devices are not disabled. I'm not experienced enough with Linux systems to find the logs to find out why the stalling was occurring though.
#10

Apparently there’s a problem with the broadcom driver in 13.1 that can cause that freeze.

Installing kernel-firmware should help though.

Or try to install broadcom-wl and broadcom-wl-kmp-desktop (or broadcom-wl-kmp-default according to the kernel you use) from Packman.
But better start a new thread in the Wireless subforum if you have questions about this. And please provide the exact model of your wireless card at least, i.e. the output of “lspci -nnk”. See also the stickies in the Wireless forum.

#11

Broadcom drivers or firmware are not shipped with openSUSE
They have to be downloaded and installed post installation.

It would be more helpful if the OP posted the info requested /sbin/lspci -nnk

#12

Well, the open source b43, b43legacy, and brcmsmac drivers are shipped with openSUSE (they are part of the kernel package).
And firmware for the brcmsmac driver is included in kernel-firmware AFAIK. If this is not installed, it can freeze I think.

I’ve also read about freezes during installation with the b43 driver on 13.1. Installing broadcom-wl should fix it in that case.
Not sure whether installing the b43-firmware helps as well.

But yes, as I wrote, for more specific advise the output of lspci would be needed.

#13

I am having what might perhaps be the same problem. I’m trying to do a clean install of either openSUSE 12.3 or 13.1, but both fail in much the same way.

The machine is currently running openSUSE 10.3 (if I put its disk in) and has been for years without problems. It’s a desktop with a quad core Q6600 CPU and I think the MOBO is an Asus P5K-VM. Currently it’s configured with an optical drive, a single 750GB SATA disk and a card reader. No wireless or floppy.

If there’s a previous installation on the disk, the install freezes early on while probing the system and “searching for Linux partitions”. If I delete all partitions from the disk, it pauses for a couple of minutes at this point and then continues. However, it always freezes again later at some point. Exactly where it freezes seems to vary, but it’s usually about 2/3 of the way through the install while installing some small software package. Once it got as far as “saving the boot loader configuration” and then froze, although there were also some ridiculously long pauses before getting to that point.

When it freezes, the machine isn’t accessing the HDD and (judging from the fan speed) not doing much processing either. The “Abort” button is inoperative but the cursor still moves and “rotates” to denote busy.

I’ve tried the 12.3 network install, the 13.1 network install and the 13.1 full DVD install (the 64-bit versions with KDE) and all give much the same problem. All the install media pass their media checks. I’ve also tried installing the current Scientific Linux and Debian distros and both install cleanly without any issues - so apparently not a hardware fault.

I, too, would really appreciate some help to solve this. Thanks.

#14

Try the live DVD, that worked for me on some machines

#15

You say that there is no floppy. See if in the BIOS a floppy is enabled. This can cause problems. Disable the floppy in the BIOS

#16

Absolutely .

#17

Oooooh, that is so annoying! I wish I’d consulted you guys before wasting all that time :wink: There was indeed a floppy enabled in the BIOS (strange that it only affects openSUSE though). The start of the install now goes a lot faster without any pauses, so I suspect that has fixed it. It’ll take a while to do the full install, so I’ll report back, but it looks good so far. I hope the OP can find a solution as easily.

#18

Actually it is a kernel issue (in combination with non-optimal behaviour of other applications used by the installer) that got fixed recently fortunately, so this should not happen anymore with 13.2.
https://bugzilla.novell.com/show_bug.cgi?id=773058

So it’s not really openSUSE-specific, but other installers might not trigger the issue because they maybe do things differently.

#19

OK, the install seems to have completed properly this time and a lot faster too, so that seems to have fixed it. Thanks for the help. I see from the bug discussion that the BIOS being reset at some point is likely to leave it in this (somewhat incorrect) state. That’s probably what has happened; on an older machine, the BIOS is likely to have got reset at some point.

#20

Well, not quite.
Actually the floppy drive is enabled by default on many BIOSes. The problem is/was that some BIOSes tell the kernel in that case that a drive is present even if there’s none, and the kernel believes it. Trying to access the non-existing drive causes those hangs then.

If the BIOS gets reset, it switches back to the default setting. If that were disabled, the problem would not occur…