Bug ID 953769
Summary clean (nov 2014, original install) 13.2: dup to 42.1 resets network stack completely from enpXsY to ethZ type again, offlines system, needs manual on site intervention
Classification openSUSE
Product openSUSE Distribution
Version Leap 42.1
Hardware x86-64
OS openSUSE 42.1
Status NEW
Severity Normal
Priority P5 - None
Component Network
Assignee bnc-team-screening@forge.provo.novell.com
Reporter abittner@opensuse.org
QA Contact qa-bugs@suse.de
Found By ---
Blocker ---

clean (nov 2014, original install) 13.2: dup to 42.1 resets network stack
completely from enpXsY to ethZ type again, offlines system, needs manual on
site intervention



rant mode bugreport, sorry please bear with me :((

Oh why me :(
Happily working 13.2 x64, originally installed november 2014, fresh/clean back
then. no fancy things. only a number of pci(e) ethernet devices.

Configured them back and worked happily ever since.

Network cards are (two interfaces in use) set to fixed ipv4 on those enpXsY
device type.

========
(all via remote ssh login):

Now after the 42.1 leap gold release I first zypper up to latest 13.2 zypper
stack and latest updates. All good.

Then removed all repos. Then added the leap-oss and the leap-update-oss repo.

Then zypper dup --download only
Then zypper dup

System processed for a while, then reported dup was complete.
Then issued a reboot.

System never came back online :(
Had to drive across the country. Once again. Because of SuSE operating systems.

Seriosly guys, I am kind of fed up or I give up. SuSE still has elementary
problems with things like keeping config in a workable and usable state from
right one OpenSUSE release to the rightful next release that supposedly is a
properly supported upgrade path. And zypper dup is a supported upgrade path as
well as far as I know.

When I physically arrived at the machine, everything was hellishly sluggish as
tons of services (normal stuff like bind, nmb/smb, ntp, ssh, ntp) apparently
wait endlessly for timeouts for nonexistant devices. Reboots and logins and
even yast2 are painfully slow during a messed up networking stack.

Anyways, the system tells me it is apparently an upgrade 42.1 leap installation
just fine, but wicked ifstatus all all of a sudden lists all from eth0 to eth4
all unconfigured stuff.

I find my original files from November 2014 in
etc/sysconfig/network/ifcfg-enpXsY all still there.

I also find 70-persistent-net-rules or whatever it is called in
/etc/udev/rules.d/ or so (typing from memory right now).

Also my SuSEFirewall2 file also lists the old enpXsY for firewall-internal and
firewall-external device names obviously this had worked for like a year on
13.2 just fine.

So why, oh why did a zypper dup to 42.1 just decide to skip over all my
existing configs and abandon just everything.

Is it still that OpenSUSE cant properly handle package upgrades, or even if
kernel maintainers or whomever decide to go back again to classical ethX naming
of ethernet devices, that openSUSE then cannot do a proper matching and porting
of settings from old config to new config, or make sane decisions.

Like hey look, this is the current device name, this is its mac address, if new
package changes to other name, lets look for this device name everywhere where
it is currently activated and alive and switch those settings to the new name?

Maybe I havent followed recent discussions about ethernet naming or stuff, but
I had actually thought linux would finally stay with the enpXsY naming?

Odd enough, I have had another machine zypper dup-ed at the same time which
came back online normally. Has fewer interfaces but was also 13.2 before. But
has a longer openSuSE history.

Maybe this doesnt matter, actually what matters is, if it is possible to create
software that takes in the current way of doing things and configuration and if
it is know that the upgrade changes stuff, re-write the currently existing
configs into sane new-way-to-do-things config style.

OpenSUSE has really broken my neck so many times, back in the old days I had
problems with separate /var/ partitions, then grub 1 bootloader woes or initrd
and all kind of crazy things.

Can we please make this basic stuff absolutely robust under all circumstances.
A system needs to be able to connect to a network and run very basic things
like an ssh and be able to boot.

I mean I never had stuff like raid or exotic hardware or anything. It always
was a few or one networking card, also always supported drivers for these
cards, and a single disk. Heck I remember things like you could set the /boot/
partition to a filesystem via yast or something that then later grub would fail
to boot from or fail to write I cant remember. With a lot of pain I have
figured to only use extX for boot or completely abandon, as nice mkinitrd would
just atempt to write new bootconfig and run out of space and completely ruining
(empty file) the boot.cfg or grub.cfg or whatever it was named, and the old
kernel still being there and even the new kernel files fit the /boot/ partition
but the menu.cfg config file of grub was written witz zero bytes to the boot
partition as it would be completely filled and no warnings issued and the
system never boot again without manual intervention.

Sane minds would keep a grub.cfg file as backup, write the new one then and if
succeeded only then delete/rename the old file. But oh well.

I cant even remember any more all the dreaded bugs that OpenSUSE (or maybe
Linux style of doing things) gave me. Seriously, compared to even historic
windows operating systems and their upgrades to the next OS level (not updates,
or servicepacks), this takes the cake. I have never in my life had as much
trouble with pretty basic things as with Linux (OpenSUSE) here. Single disk,
network cards. This alone causes a user extreme pain in the Linux world.

Is this really the state of the art that Linux can and does do, even in the
year 2015?


You are receiving this mail because: