http://bugzilla.suse.com/show_bug.cgi?id=960669 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|959764 | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trenn@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c7 --- Comment #7 from Jan Engelhardt --- Actions for 13.2: * switch udev script from net.ifnames!=0 to net.ifnames==1 so that 75-persistent-net.rules is generated * make sure 75-persistent-net.rules, if present, ends up in the initramfs Actions for TW: * make sure 75-persistent-net.rules, if present, ends up in the initramfs Actions for OpenQA: * make sure that the 13.2 QCOW image is actually populated with all updates (that did not seem to be the case last time I checked in December - it lacked the systemd-210.+biggitnumberhere+) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c9 --- Comment #9 from Jan Engelhardt --- "work" is coincidental. systemd 210 does not support virtio-net. systemd 228 does. Change in default behavior. 13.2 systems rely on defaults and fail to store the "custom parts" that OpenQA actually so depends on. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c11 --- Comment #11 from Ludwig Nussel --- So the problem is very similar to https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.1/#idm1400963... Maybe we should enable the name generator mechanism always, no matter what the actual naming policy is (the generator can decide that), just to make sure we always get the udev rule so network interfaces never change names. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c13 --- Comment #13 from Fabian Vogt --- (In reply to Jan Engelhardt from comment #12)

...

So after the update to TW, udev grabs the network interface during the initrd already

It always grabbed the name during the initrd (in case of virtio-net), because virtio-net.ko gets loaded in the initrd (and e1000.ko is not!).

Yeah, but that's not a big issue. It's a tiny bug that should be fixed, but it should not change behaviour in any way. If it does, that's a different bug.

...

it should be enough to include the rule in TW only,

But you have to make sure 75-p exists and mkinitrd was run, both before you reboot into the TW systemd. This is why I am saying that 13.2 needs to record its naming scheme first before it can be upgraded to TW. I'm not sure whether it is even possible (without doing something weird) to boot tumbleweed with a 13.2 generated initrd.

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c15 --- Comment #15 from Jan Engelhardt --- Correct, persistent naming never worked because of this. You will find that 13.2 gives you enp0s3 and wwp0s2u24 or something in that style, and will also not generate /etc/udev/rules.d/7*-persistent-net* on its own. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c17 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(trenn@suse.com) | --- Comment #17 from Fabian Vogt --- He removed it as "merged mainline" although it was not. I hesitate to add it back in as it will cause breakage in VMs running TW and also machines with / on network. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c19 --- Comment #19 from Ludwig Nussel --- why do you fear breakage? TW doesn't use persistent names so the file in question doesn't exist unless it was an upgrade from e.g. leap. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c21 --- Comment #21 from Franck Bui --- (In reply to Ludwig Nussel from comment #20)

confirmed that making dracut include 70-persistent-net.rules in the initrd correctly renames the virtio net device as used by openQA.

I don't see why including this rule in initramfs helps if it's already present in /etc/udev/rules.d/ Could anybody explain ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c23 --- Comment #23 from Franck Bui --- (In reply to Fabian Vogt from comment #22)

...

I don't see why including this rule in initramfs helps if it's already present in /etc/udev/rules.d/

Could anybody explain ?

It's only triggered on device recognition, e.g. "rmmod virtio-net; modprobe virtio-net" renames the device.

udev is restarted once the system has switched to the real rootfs and it should apply *all* rules at this point, including renaming the net interface. Did anybody actually tried to include the rule in /etc/udev/rules.d but not in initramfs ? Here it simply works as expected. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c25 --- Comment #25 from Ludwig Nussel --- (In reply to Fabian Vogt from comment #22)

(In reply to Ludwig Nussel from comment #18)

...

no, the patch was actually reverted. there were two patches, one that adds it and one that reverts it, ie noop. With the version upgrade to 44 both were removed.

Which one is the reverting patch? I can't see any patch related to this in the changes for 44. I remember removing some pointless patches, but not network related.

$ osc ls -R 69 openSUSE:Factory dracut|grep pers 0022-95udev-rules-add-persistent-network-rule.patch 0136-Revert-95udev-rules-add-persistent-network-rule.patch

...

why do you fear breakage? TW doesn't use persistent names so the file in question doesn't exist unless it was an upgrade from e.g. leap.

Has this changed during some point in TW?

The change from persisent to predicable was in 13.1 already AFAICT, so very long ago.

I have a old Tumbleweed system here that uses "ens*".

Which is expected as that is a predictable name :-) That system doesn't have 70-persistent-net.rules then, right? Just to summarize, we are talking about upgrade problems here and the problems are different depending on base distro: 1. upgrade from leap: leap uses persistent names (eth0), just as SLE, so an upgrade to TW must honor 70-persistent-net.rules 2. upgrade from 13.2: 13.2 does use predicatable names but udev on 13.2 apparently didn't support predicable names for virtio devices. So in openQA all machines still used eth0. 1) will be immediately fixed when dracut includes 70-persistent-net.rules in initrd again. 2) requires an additional workaround in 13.2 to create 70-persistent-net.rules, we may do that in openQA or just don't test upgrades from 13.2 anymore :-) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c27 --- Comment #27 from Jan Engelhardt ---

(In reply to Fabian Vogt from comment #22)

udev is restarted once the system has switched to the real rootfs and it should apply *all* rules at this point, including renaming the net interface.

Except that renaming the net interface is NOT done when it already WAS renamed at some point in the past. ^ Which is what happens with virtio-net inside openqa. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c29 --- Comment #29 from Fabian Vogt --- (In reply to Ludwig Nussel from comment #25)

...

...

why do you fear breakage? TW doesn't use persistent names so the file in question doesn't exist unless it was an upgrade from e.g. leap.

Has this changed during some point in TW?

The change from persisent to predicable was in 13.1 already AFAICT, so very long ago.

...

I have a old Tumbleweed system here that uses "ens*".

Which is expected as that is a predictable name :-) That system doesn't have 70-persistent-net.rules then, right?

I don't know, I only have the config files for it (ifcfg-ens1).

Just to summarize, we are talking about upgrade problems here and the problems are different depending on base distro:

1. upgrade from leap: leap uses persistent names (eth0), just as SLE, so an upgrade to TW must honor 70-persistent-net.rules 2. upgrade from 13.2: 13.2 does use predicatable names but udev on 13.2 apparently didn't support predicable names for virtio devices. So in openQA all machines still used eth0.

1) will be immediately fixed when dracut includes 70-persistent-net.rules in initrd again.

2) requires an additional workaround in 13.2 to create 70-persistent-net.rules, we may do that in openQA or just don't test upgrades from 13.2 anymore :-)

I talked to trenn, the cause for the (chaotic) revert is bug 886669. Basically, 70-persistent-net.rules does not work correctly in the initrd due to various reasons and bugs. It also conflicts with dracut's network naming scheme (but that can be fixed). I'll only commit the removal of forced virtio-net in QEMU, that should fix it as well. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c31 --- Comment #31 from Jan Engelhardt --- (In reply to Franck Bui from comment #30)

...

Except that renaming the net interface is NOT done when it already WAS renamed at some point in the past.

^ Which is what happens with virtio-net inside openqa.

That's not what I'm seeing here:

$ journalctl -b ... Jan 26 12:03:36 linux-nypb kernel: virtio_net virtio0 ens3: renamed from eth0 Jan 26 12:03:36 linux-nypb systemd-udevd[321]: renamed network interface eth0 to ens3 ... Jan 26 12:03:42 linux-nypb kernel: virtio_net virtio0 eth0: renamed from ens3 Jan 26 12:03:42 linux-nypb systemd-udevd[655]: renamed network interface ens3 to eth0 ...

That's not what the openqa test showed. If it was rerenamed back to eth0, then the openqa test would not have failed. Something seems wrong with your system. In 75-persistent-net-rules-generator, you find # ignore the interface if a name has already been set NAME=="?*", GOTO="persistent_net_generator_end" # device name whitelist KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end" So by definition, you even have a bug because ens must not be rerenamed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c33 --- Comment #33 from Franck Bui --- (In reply to Jan Engelhardt from comment #31)

That's not what the openqa test showed. If it was rerenamed back to eth0, then the openqa test would not have failed. Something seems wrong with your system.

Initially this bug was about an upgrade from 13.2 to TW. In the case of 13.2, /etc/udev/rules.d/70-persistent-net.rules is just missing since as you already know, 75-persistent-net-rules-generator is boggus. And if the rule is missing, well no renaming happens obviously. However if you add manually a persistent rule in /etc/udev/rules.d in order to make sure that the virtio net interface is named "eth0" then it will work just fine. For some reasons the persistent net rules generator had been fixed on SLE12-SP1/Leap, and that the reason why the behavior is different and the reason why adding it in the initramfs makes difference. And here is what is generated by the generator: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:12:34:56", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" Please note the KERNEL=="eth*" condition. Right after the system switched to the final rootfs, the interface is named "ens3" (since 70-persistent-net.rules is not included). When udev is started (again), it reads 70-persistent-net.rules but the rule doesn't apply since the above condition is not met. So if you remove this condition, the renaming will work as expected even if systemd already renamed it "ens3" from within the initramfs. Now I have another question: why 80-net-setup-link.rules is included in the initramfs ? It's the rule which enables the predictable naming scheme done by udev for eth0, if I'm understanding correctly: if it's removed then the NIC name will be "eth0" as usual and the generated rule (if present) will work as expected. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c35 --- Comment #35 from Franck Bui --- (In reply to Fabian Vogt from comment #34)

It's been in upstream dracut since 37 (basically since we use it). It is important that NICs are called the same in the initrd and the full system, as the configuration files for wicked are just "cp -R"ed over.

Could you explain how the config files for wicked are used inside the initramfs ? I don't think you meant that wicked (and all of its deps) can be included in the initramfs... If you don't want NICs to be renamed after switching to the new rootfs, I'm afraid you'll have to include all rules in /etc/udev/rules.d/ -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c37 --- Comment #37 from Franck Bui --- (In reply to Fabian Vogt from comment #36)

(In reply to Franck Bui from comment #35)

...

(In reply to Fabian Vogt from comment #34)

...

It's been in upstream dracut since 37 (basically since we use it). It is important that NICs are called the same in the initrd and the full system, as the configuration files for wicked are just "cp -R"ed over.

Could you explain how the config files for wicked are used inside the initramfs ? I don't think you meant that wicked (and all of its deps) can be included in the initramfs...

It is, with most parts stripped. (No DBus for example, as mentioned in the last meeting). One example: https://build.opensuse.org/package/view_file/Base:System/dracut/0015- 40network-replace-dhclient-with-wickedd-dhcp-supplic.patch?expand=1

...

If you don't want NICs to be renamed after switching to the new rootfs, I'm afraid you'll have to include all rules in /etc/udev/rules.d/

I totally agree with this, but it's not possible right now, I'm afraid.

The support of the network in dracut seems to have some issues (missing udev rules, now virtio_net driver is going to be removed, ...). Is a bug report already opened to track those shortcomings ? if not shouldn't it be created ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c39 --- Comment #39 from Ludwig Nussel --- Can you estimate when to expect a fix/workaround for Factory? I'm just asking as I need to evaluate whether it's worth investing time into adding a temporary hack to the openQA tests to make them pass. systemd is stuck in stagings far too long already unfortunately. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c41 --- Comment #41 from Franck Bui --- (In reply to Fabian Vogt from comment #40)

A proper fix takes a bit longer, but that is not needed as fixing the other two bugs (one of which is currently in SR #356093, but it's likely not sufficient) is enough: Not forcibly include network stuff in the initrd. It shouldn't take too long to fix, I already talked to pwieczorkiewicz yesterday and he confirmed that network support isn't needed by default. If nothing goes horribly wrong (if it does, I'll let you know) it should be done in a few hours.

I don't see how removing network stuff from initramfs will help for the initial test case which is: - updating systemd from version lesser than v226 to v228 - virtio-net is used - no persistent rule has been generated previously This basically happens when: - updating TW - upgrading 13.2 -> TW -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c43 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(lnussel@suse.com) --- Comment #43 from Franck Bui --- (In reply to Fabian Vogt from comment #42)

(In reply to Franck Bui from comment #41)

...

(In reply to Fabian Vogt from comment #40)

...

A proper fix takes a bit longer, but that is not needed as fixing the other two bugs (one of which is currently in SR #356093, but it's likely not sufficient) is enough: Not forcibly include network stuff in the initrd. It shouldn't take too long to fix, I already talked to pwieczorkiewicz yesterday and he confirmed that network support isn't needed by default. If nothing goes horribly wrong (if it does, I'll let you know) it should be done in a few hours.

I don't see how removing network stuff from initramfs will help for the initial test case which is:

- updating systemd from version lesser than v226 to v228 - virtio-net is used - no persistent rule has been generated previously

This basically happens when:

- updating TW - upgrading 13.2 -> TW

This says otherwise:

(In reply to Ludwig Nussel from comment #20)

...

confirmed that making dracut include 70-persistent-net.rules in the initrd correctly renames the virtio net device as used by openQA.

Not including network stuff at all is basically the same.

I guess this was for Leap... Ludwig ? OTOH it's easy to give it a test. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c45 --- Comment #45 from Fabian Vogt --- (In reply to Franck Bui from comment #43)

(In reply to Fabian Vogt from comment #42)

...

(In reply to Franck Bui from comment #41)

...

(In reply to Fabian Vogt from comment #40)

...

A proper fix takes a bit longer, but that is not needed as fixing the other two bugs (one of which is currently in SR #356093, but it's likely not sufficient) is enough: Not forcibly include network stuff in the initrd. It shouldn't take too long to fix, I already talked to pwieczorkiewicz yesterday and he confirmed that network support isn't needed by default. If nothing goes horribly wrong (if it does, I'll let you know) it should be done in a few hours.

I don't see how removing network stuff from initramfs will help for the initial test case which is:

- updating systemd from version lesser than v226 to v228 - virtio-net is used - no persistent rule has been generated previously

This basically happens when:

- updating TW - upgrading 13.2 -> TW

This says otherwise:

(In reply to Ludwig Nussel from comment #20)

...

confirmed that making dracut include 70-persistent-net.rules in the initrd correctly renames the virtio net device as used by openQA.

Not including network stuff at all is basically the same.

I guess this was for Leap...

Ludwig ?

OTOH it's easy to give it a test.

To get an initrd without network, https://build.opensuse.org/package/show/home:favogt:branches:Base:System/dra... is needed. I'm currently testing for regressions. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c47 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(lnussel@suse.com) | --- Comment #47 from Ludwig Nussel --- (In reply to Franck Bui from comment #43)

...

This says otherwise:

(In reply to Ludwig Nussel from comment #20)

...

confirmed that making dracut include 70-persistent-net.rules in the initrd correctly renames the virtio net device as used by openQA.

Not including network stuff at all is basically the same.

I guess this was for Leap...

Yes, it was Leap as 13.2 doesn't create 70-persistent-net.rules. If we can get the Leap upgrade working the 13.2 one isn't that important anymore. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|udev 228: after update from |udev 228: after update from |13.2, the network is not |13.2/leap 42.1, the network |enabled |is not enabled -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c52 --- Comment #52 from Ludwig Nussel --- (In reply to Franck Bui from comment #49)

(In reply to Ludwig Nussel from comment #47)

...

If we can get the Leap upgrade working the 13.2 one isn't that important anymore.

It is important: as I said earlier it's the same case as updating TW from v224 to v228.

Ok, that sucks but I'm not sure this problem should prevent systemd from passing stagings. It's at least not a problem for the development process as we unfortunately don't have upgrade tests that zypper dup between TW snapshots yet. If we don't find a fix for that problem we can warn about it before a snapshot with 228 gets released. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c54 --- Comment #54 from Franck Bui --- (In reply to Dominique Leuenberger from comment #53)

(In reply to Ludwig Nussel from comment #52)

...

Ok, that sucks but I'm not sure this problem should prevent systemd from passing stagings. It's at least not a problem for the development process as we unfortunately don't have upgrade tests that zypper dup between TW snapshots yet. If we don't find a fix for that problem we can warn about it before a snapshot with 228 gets released.

And as usual forget about it down the line until SLE comes up with a new systemd version and then remember again that we had that problem long ago but decided to 'speed up things' instead of fixing it.. I for one prefer a fix when it's time to fix it - nothing else is blocked for not having the latest version of this package in TW for now.... I don't understand the hard push to circumvent all the processes we have in place.

Totally agreed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 Markos Chandras changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchandras@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c64 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jbohac@suse.com) --- Comment #64 from Franck Bui --- Of course there's one see FATE#323174. Also could you be so kind to actually answer my questions in my last comment ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c67 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.molkentin@suse.com Flags| |needinfo?(daniel.molkentin@ | |suse.com) --- Comment #67 from Franck Bui --- @Daniel, could you include /etc/udev/rules.d/70-persistent-net.rules in the initramfs (if it's present) please ? Also we should make sure that custom link files end up in the initramfs too. The same happened to Debian a couple of years ago, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793374 that might give you some relevant information. Currently the link files dont seem to be considered by dracut, tested with TW. Just make sure this is done for Factory *only* as all SLE versions (including SLE15) will continue to use the obsolete persistent naming scheme. And yes if customers decide to use the predictable names then renaming won't work for them... oh well. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c69 --- Comment #69 from Bernhard Wiedemann --- This is an autogenerated message for OBS integration: This bug (960669) was mentioned in https://build.opensuse.org/request/show/535999 Factory / dracut -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c72 --- Comment #72 from Daniel Molkentin --- The *.link files already do get included in SLE15. In fact, also SEL13SP2 and 3. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| maint:planned:update |maint:planned:update | |ibs:running:5752:important -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:5752:important | |ibs:running:5751:important | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c76 --- Comment #76 from Swamp Workflow Management --- SUSE-RU-2017:3412-1: An update that has 7 recommended fixes can now be installed. Category: recommended (important) Bug References: 1011554,1019938,1048551,1052840,1067279,1072424,960669 CVE References: Sources used: SUSE Linux Enterprise Server 12-SP3 (src): dracut-044.1-114.17.1 SUSE Linux Enterprise Desktop 12-SP3 (src): dracut-044.1-114.17.1 SUSE Container as a Service Platform ALL (src): dracut-044.1-114.17.1 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 http://bugzilla.suse.com/show_bug.cgi?id=960669#c78 --- Comment #78 from Swamp Workflow Management --- openSUSE-RU-2017:3429-1: An update that has 8 recommended fixes can now be installed. Category: recommended (important) Bug References: 1011554,1019938,1036323,1048551,1052840,1067279,1072424,960669 CVE References: Sources used: openSUSE Leap 42.2 (src): dracut-044.1-16.15.1 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960669 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:7614:important | |obs:running:7615:important | -- You are receiving this mail because: You are on the CC list for the bug.