Immediately after the upgrade removes the various repositories I get “Network not Configured” which was reported in an earlier thread that referenced a different video card than I have.
Clicking on any of the buttons on the screen (abort, help, rel notes, back) does nothing. Choosing ‘no’, “do not configure” exits and ‘yes’ blinks and does nothing.
I have an AMD Radeon HD 7500 video card, the driver is fglrx_pci and the network card is RTL8111/8168B, the driver is r8169. The computer is NAT behind a router.
I don’t want to perform a new install, prefer to upgrade.
Had the same issue but I could continue the install only to have it fail installing the boot louder. Could not resolve the problem. I then installed as new and all worked fine. Oh well.
Upgrade not as full proof as I had hoped.
>
> Trying to upgrade 13.1 x64 to 13.2 x64 KDE.
>
> Immediately after the upgrade removes the various repositories I get
> “Network not Configured” which was reported in an earlier thread that
> referenced a different video card than I have.
>
> Clicking on any of the buttons on the screen (abort, help, rel notes,
> back) does nothing. Choosing ‘no’, “do not configure” exits and ‘yes’
> blinks and does nothing.
>
> I have an AMD Radeon HD 7500 video card, the driver is fglrx_pci and the
> network card is RTL8111/8168B, the driver is r8169. The computer is NAT
> behind a router.
>
> I don’t want to perform a new install, prefer to upgrade.
>
> What to do?
>
> Thanks, Jon
>
So far, I’ve managed to get through the update (from the DVD) for both 54
and 32 bit systems despite the message. On a couple of machines, I even had
network connectivity via the hard wired ethernet port if it was plugged in.
Still haven’t gotten the wireless device to setup correctly without a bunch
of monkeying around in the dual netcard systems in any of the laptops I’ve
tried and I still don’t know what to expect for a network setup. Sometimes,
a second update install will fix the mess but I’ve picked a few of the
screwiest machines and put the rest of the bunch I maintain on hold until I
figure out this mess.
Short answer is that a single network wired interface will probably work
just fine using the upgrade path - despite the message. The full install
with a clean home results in considerable work to get the required setup
after the install completes if you have host names and fixed ip addresses to
configure. If there is a way to set those up during installation, I haven’t
found it yet. I suspect that most of the machines around here are likely to
remain on 13.1 for quite a while due the the hassle of dealing with the
“simplified” install process on each machine.
In another thread Wolfi wrote “But, depending on your particular graphics card, the open source radeon driver might be good enough or even better…” and I thought I also saw something that indicated the existing 13.2 driver would work but I may be mistaken.
I forgot to mention that I am using a dvd install that I downloaded from this site. Confirmed the .md5 is correct.
I will try it again with nomodeset but what I have trouble understanding is what fglrx has to do with no network connection.
gogalthorp, are you suggesting that I wait for support of the video card? I haven’t check Lizards yet, I think that is where the fglrx support is coming from.
Will H wrote “a single network wired interface will probably work just fine using the upgrade path - despite the message.”
Will, are you saying just proceed by answering ‘no’ for network configuration and continuing? Then set up eth0 later?
I have seen some suggestions using zypper to do an online update but I’m afraid to proceed on that path and have it fail.
If the Network fails at first try setting it up in Yast. Note that 13.2 introduces the new wicked program rather then the old ifup program. So if wicked does not work for you. Try Networkmanager Also report the problem so it can be fixed for your hardware. Will need info like what net chips is in use etc.
gogalthorp: Thanks, so perhaps a dark screen would be further into the upgrade since I don’t have the correct driver.
Apparently, if I were to continue the upgrade without network configuration there are a number of repo’s that won’t be accessible until I can configure eth0. I am not confident enuf to want to blow away my good 13.1 on an upgrade that might work.
Further info, going to a VT console in the update, lspci -v shows the kernel using R8169 for eth0. This is the same as the info in v13.1.
But using wicked in that VT all I get is that the interface isn’t found.
This stuff is way over my head. I see there are comments in at various sites about problems with RTL8111/8168B but I don’t know how to go any further. There doesn’t seem to be anything at bugzilla so I will make a report there.
I have 13.1 XFCE on dual booting system. One hard disc Windows Vista, other OpenSUSE 13.1 XFCE, 64 bit. On first and second attempt to upgrade to 13.2 with downloaded DVD, I got network not configured, and pressed on. The upgrade failed at boot configuration and subsequent tries of clean install also failed.
From other reports, I have gone back to a clean 13.1 installation. System is ACER Aspire 7720 with Intel T5450 , 4Gb RAM, first hard disc 180Gb (Vista) other 120 GB Linux ( now reset back to OpenSUSE 13.1. XFCE system).
> Will H wrote “a single network wired interface will probably work just
> fine using the upgrade path - despite the message.”
> Will, are you saying just proceed by answering ‘no’ for network
> configuration and continuing? Then set up eth0 later?
>
What is most common is that wicked is set up using DHCP for the ip address
and route info - even if I’m doing an update of an existing system. That
gives me initial network access but I still normally spend a fair amount of
time tweeking the individual settings. Laptops are a particular problem as
most users actually need NetworkManager running to accomodate multiple
wireless access points both at the office and for outside work and that can
be a real challenge. No two machines seem to follow the same steps - or I’m
getting too darned old to understand what’s happening…
I have yet to get a usable wireless setup out of the chute and the biggest
bunch of machines I work on are set up to use manual host names, ip settings
and routes to make the network jumble easier to track (I simply distribute a
hosts file rather than fighting the DNS problems) so I’m less than thrilled
by 13.2 as of now.
> Also report the
> problem so it can be fixed for your hardware.
As I mentioned above, I still haven’t been able to get a usable
characterization of the issues I’ve seen so I have more work to do to get to
that point.
I don’t get an ip addr, the eth0 interface is not seen by the update routine. The nic is reported as not configured. However, if I look at the system config in the update screen it shows the correct info, including the r8169 driver.
I filed a bug report. I don’t know what will come of that yet but here are a few things that I’ve discovered and/or have been pointed out to me since then.
Apparently wicked is used to configure the nic. It apparently is done from a template but I don’t know how that is done and where it comes from. In the update, after the screen where the v13.1 repo’s are removed and before the update continues, I get “network not configured” where it is looking the find the 13.2 repo’s. At this point, if I drop into a VT and look at /etc/sysconfig/network I find ifcfg-lo for the loopback but not a file for the nic. It seems to me, and I could be very wrong, that there should be a file for the nic. For example, in v13.1 there is a file called ifcfg-eth0 but nothing here in v13.2 except the loopback. In addition, eth0 is no longer used in v13.2. Wicked uses a different name, here, my nic is called p3p2 instead of eth0. You can find this with “hwinfo --network”. So however it is that the install determines the name of the nic, update apparently does not create the necessary definition file from the template. Again, this template comment is only my guess.
It’s been noted that the kernel command net.ifnames=0 will alter the new interface naming, I guess reverting it back to eth0. I haven’t tried running the update with that command so I’m not sure if I understand this correctly. I’m waiting for further comments from on my bug report before proceeding.
For example, in v13.1 there is a file called ifcfg-eth0 but nothing here in v13.2 except the loopback. In addition, eth0 is no longer used in v13.2. Wicked uses a different name, here, my nic is called p3p2 instead of eth0. You can find this with “hwinfo --network”. So however it is that the install determines the name of the nic, update apparently does not create the necessary definition file from the template. Again, this template comment is only my guess.
It’s been noted that the kernel command net.ifnames=0 will alter the new interface naming, I guess reverting it back to eth0. I haven’t tried running the update with that command so I’m not sure if I understand this correctly. I’m waiting for further comments from on my bug report before proceeding.
Actually, predictable network interface naming has been around for a while now (even with openSUSE 13.1)
> It’s been noted that the kernel command net.ifnames=0 will alter the new
> interface naming, I guess reverting it back to eth0. I haven’t tried
> running the update with that command so I’m not sure if I understand
> this correctly. I’m waiting for further comments from on my bug report
> before proceeding.
>
I have no issue with the naming convention - “a rose by any other name…” -
but I did come up with a new “funny” today. Trying to build a reasonable
test case, I wiped 2 partitions (love these huge new disks!) and went thru a
clean DVD new installation. Got up with an ethernet connection with wicked
invoking DHCP. Routes, etc. were usable. OK, so far, so good.
Now for the wireless. Whoops! What wireless? No sign of the RT3290 in
ifconfig, network setup with Yast pulls a Sgt. Shultz: I know nozzing!
Reboot, same setup. lspci sees a device there but the system know nothing
of it. ifconfig sees nothing, ect. but rfkill reports both soft and hard
blocking are “no”.
Being retired with lots of time (too cold to go out - temp has dropped 50
degrees F in the last 2 hours) I fell back on old, old habits and booted to
Win 8.1. Wifi works perfectly - even connect in the n band. Back to oS.
Now, the system sees the adapter and after several attempts I finally get
the wireless to configure and connect.
I figure that some bit in the wireless device got reset and the linux driver
isn’t smart enough to turn it on properly. Booting to Windows sets the
adapter up properly but that’s beside the point. If I can repeat the
condition, that will get a bug filed but it still doesn’t get me back the
no-brainer installation I’m looking for!
Try this, it is what I have to do to create a connection in order for yast2 to proceed with the upgrade.
Switch to a VT. There is a message displayed that mentions wicked & dhcpcd.
I type dhcpcd and it displays the new names for eth0 & wlan0.
I do dhcpd <new name> and after about 20 seconds I get a connection.
Switch back to install screen.
I have continued to abort my 13.2 install because I’m still waiting to see if more info will come out of bugzilla. But now I know that I can continue the install beyond the repo’s screen. Since the fglrx video driver doesn’t work I am hesitant to continue the upgrade, waiting to see what the future brings.
I have not been successful in getting the kernel command to disable the new naming convention to work, but the above method does work for me on my wired connection. I don’t use my wlan device on this computer so have not played with it at all.
> Interesting account Will. I wonder why wireless devices aren’t
> immediately visible. Is this just an issue with wicked that you had? Or
> NM?
>
Dean, I’m still trying to figure this one out. On the failed attempts,
modprobe showed that the kernel wasn’t even loading the module until I
booted to Win.
I’ve had issues like this before where Win-xx would reset an adapter config
on shut down in such a way that made it useless when booting another os.
That’s why I resorted to booting Win 8.1. That proved the wireless adapter
was still working and subsequent boots of 13.2 went smoothly so I had
wireless back. I’ve run into this exactly twice installing 13.2 and the
trick worked both times. That’s 2 failures out of a couple of dozen test
installs so it’s not a complete show stopper; just a PITA that I’ like to
see cleared up if I can give the developers a usable test case to work with.
Installing 12.3 with CD/DVD found problems due things missing from DVD, whem did re-install with USB stick it all worked
While installing 13.2 accepted the BTRFS without reading about the changes so ended up doing full re-format and clean install onto my HD, rather than usual re-format couple partitions being used.
