http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c1 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #1 from Takashi Iwai --- Agreed that it's not appropriate to be shipped in systemd, but do you know where did it come from? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c3 Lee Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(lduncan@suse.com) | --- Comment #3 from Lee Duncan --- Yes, the sg driver still needs to be loaded, by default, since it is used by udev as well as the sg3_utils package, which also seems to be installed by default. I can think of two possible solutions: 1. Make the sg module builtin instead of a loadable module, or 2. Move the file /usr/lib/modules-load.d/sg.conf from the systemd package to the sg3_utils package (since I cannot think of a more appropriate place). This would mean udev would have to "require" the sg3_utils package, I believe. I also believe we should create a FATE entry to move all of our internal tools from sg to bsg, to start working towards eliminating this issue. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c5 --- Comment #5 from Michal Marek --- Created attachment 723088 --> http://bugzilla.suse.com/attachment.cgi?id=723088&action=edit [PATCH] sg: Add an alias to always autoload the driver Can somebody check if this patch makes the udev file redundant? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c7 Oliver Neukum changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oneukum@suse.com --- Comment #7 from Oliver Neukum --- (In reply to Michal Marek from comment #5)

Created attachment 723088 [details] [PATCH] sg: Add an alias to always autoload the driver

Can somebody check if this patch makes the udev file redundant?

Doesn't this introduce a race? You cannot be sure that the sg node exists when sd, sr or st appear, as far as I can tell. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c9 --- Comment #9 from Takashi Iwai --- So what's the merit of making sg as a module? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c11 --- Comment #11 from Michal Marek --- Re comment 7, comment 8: Sure, the patch does not introduce any dependency between sg and the different scsi device drivers. But that's the same with the current approach, there is no guarantee that the modules will finish initializing in a given order. And I actually do not see any udev rules working with sd/sr/st devices and sg devices at the same time, so where is the issue? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c13 --- Comment #13 from Oliver Neukum --- Nevertheless why introduce a kernel change for a missing module dependency created by user space. If we want to give the job to udev a module rule would do the job better and without a race condition. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c15 --- Comment #15 from Takashi Iwai --- This seems lost in the forest again... So to recap: we have the following options. 1) Make sg built-in 2) Move modules-load.d stuff into sg3_utils 3) Try to do auto-load via alias (or other way) (1) would be feasible on TW kernel, but on SLE, it's an open question because SLE kernel has CONFIG_SCSI=m. So it's not only about sg on SLE kernels. (2) looks like an easy solution to me. We need to care about the missing package dependency, though. (3) is self-contained in kernel, which is good, but seems racy. If I were to decide, I'd take (2). Any other opinions? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c17 --- Comment #17 from Takashi Iwai --- (In reply to Franck Bui from comment #16)

(In reply to Takashi Iwai from comment #15)

...

This seems lost in the forest again...

So to recap: we have the following options.

1) Make sg built-in 2) Move modules-load.d stuff into sg3_utils 3) Try to do auto-load via alias (or other way)

(1) would be feasible on TW kernel, but on SLE, it's an open question because SLE kernel has CONFIG_SCSI=m. So it's not only about sg on SLE kernels.

If this is done on Factory/TW by now and thereafter will be also done on SLE15, I would vote for that option. It doesn't really matter if SLE12s stay as it is currently.

The kernel configs do differ between openSUSE and SUSE on purpose, and I'm not sure whether we would go with CONFIG_SCSI=y just only for this. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c19 --- Comment #19 from Takashi Iwai --- (In reply to Franck Bui from comment #18)

(In reply to Takashi Iwai from comment #17)

...

The kernel configs do differ between openSUSE and SUSE on purpose, and I'm not sure whether we would go with CONFIG_SCSI=y just only for this.

You meant CONFIG_CHR_DEV_SG=y, didn't you ?

Yes, but this requires CONFIG_SCSI=y as well due to the dependency. On TW kernel, CONFIG_SCSI is already y, but on SLE, it's been m.

I cannot see a reason why TW and SLE should differ on that matter.

Because the requirements are different. CONFIG_SCSI=y is set on openSUSE kernels *just* for a faster boot in many years ago. Then we kept the config as is. Meanwhile SLE didn't care the faster boot so much but rather be conservative, thus it's kept as module.

It may be too risky to change SLE12 kernels that's the reason why I was suggesting to do the change for SLE15 and later.

Sure, (1) is definitely no-go for SLE12. The question is only about TW / SLE15. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c21 --- Comment #21 from Oliver Neukum --- (In reply to Takashi Iwai from comment #19)

CONFIG_SCSI=y is set on openSUSE kernels *just* for a faster boot in many years ago. Then we kept the config as is. Meanwhile SLE didn't care the faster boot so much but rather be conservative, thus it's kept as module.

Booting faster on SLE is not bad, just not as important. Conservativism is a good answer for SLE12. For SLE15, not so much. The ability to unload the module and load a fixed module is much devalued by kgraft. And most machines need it anyway and those who do not really should have much RAM. Unless you are on s390 you will not escape the need for SCSi. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c23 --- Comment #23 from Oliver Neukum --- (In reply to Takashi Iwai from comment #22)

Also, my slight concern is that built-in solution will make the system unusable with the older kernels or with different kernel configs.

Nothing forces you to build the initrd without the scsi core if the module is present. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c25 --- Comment #25 from Lee Duncan --- I agree with some other that the best approach would be to make it built in for SLE (and leap) as it is for TW. One could certainly argue that SCSI is way more likely on SLE than on a laptop, so this should be a no-brainer, no matter what steps we need to go through to get there. If we make it built in for Leap/Factory/TW, then the current rule of "SLE must follow Factory" will give it more weight in SLE IMHO. In the mean time, we can do whatever it takes to make sure it continues to get always-loaded in SLE (thus showing SCSI should be built-in anyway?), no matter who owns the bits to make that happen. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 Hannes Reinecke changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-maintainers@forge.pr |hare@suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c28 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com --- Comment #28 from Michal Suchanek --- We have SCSI=y in SLE15 so I suppose we can make sg built-in 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=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c30 --- Comment #30 from Franck Bui --- So can we make it also for other arches too and finally make sg built-in as well for SLE15 and Factory ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c32 --- Comment #32 from Franck Bui --- (In reply to Michal Suchanek from comment #31)

What's exactly the problem with sg being module?

Please read the whole bug, I don't want to go into this discussion again...

Two different packages require the module loaded so the only logical place for sg.conf is udev or some dedicated package for modprobe rules.

No udev is not the place where we list static modules that need to be loaded because the module deps are oddly implemented in the kernel. I tried to push this into a package that seems to maintain by the kernel team: https://github.com/openSUSE/suse-module-tools/pull/1 but unfortunately it was ignored. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c34 --- Comment #34 from Michal Suchanek --- btw it looks like the packages will not conflict even if both ship the file because suse-module-tools installs in /etc and systemd in /usr/lib -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c36 --- Comment #36 from Michal Suchanek --- That's fine too I guess -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c38 Tomáš Chvátal changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tchvatal@suse.com | |) | --- Comment #38 from Tomáš Chvátal --- (In reply to Martin Wilck from comment #37)

Thomas,

I just realized that I have no write access to the suse-module-tools repository on github. Could you provide that for me? After all I'm the bugowner...

Martin

Hello Martin, I've merged the PR and added you as commiter :) Btw you can contact all the github admins to do this, i am there just because I helped michal marek setting it up ;) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c40 --- Comment #40 from Franck Bui --- (In reply to Martin Wilck from comment #35)

Sure, this can be done.

I'd suggest the following different approach though:

cat >/etc/modprobe.d/05-sg.conf <

My 2 cents: you probably want to install this in /usr/lib/modprobe.d instead... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c42 --- Comment #42 from Michal Suchanek --- Actually, no. Historically suse-module-tools installs in /etc. Incidentally it makes the installed files visible to the sysadmin. Either way, unless there is very good reason I do not see that happening this close to release. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c44 --- Comment #44 from Martin Wilck --- (In reply to Michal Suchanek from comment #42)

Actually, no.

Historically suse-module-tools installs in /etc.

Incidentally it makes the installed files visible to the sysadmin.

My suggestion would be to use %config(noreplace) if we install under /etc.

Either way, unless there is very good reason I do not see that happening this close to release.

I didn't expect that anyway. systemd is still shipping /usr/lib/modules-load.d/sg.conf, and this bug is open against factory. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c46 --- Comment #46 from Martin Wilck --- I've made a mistake. "softdep" doesn't work in Tumbleweed. It doesn't work with built-in modules in general. Moreover, it's usefulness for distribution-shipped modules is low, as only a single "softdep xxx post:" line per module seems to be supported. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c48 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com --- Comment #48 from Martin Wilck --- (In reply to Lee Duncan from comment #6)

Actually it's udev rules that rely on it:

...

zsh# grep -rl sg /usr/lib/udev/rules.d /usr/lib/udev/rules.d/55-scsi-sg3_id.rules /usr/lib/udev/rules.d/58-scsi-sg3_symlink.rules /usr/lib/udev/rules.d/60-persistent-storage-tape.rules /usr/lib/udev/rules.d/40-libgphoto2.rules

Let's clarify: 1. 55-scsi-sg3_id.rules handles only block devices, which support SG_IO ioctls even if the sg driver isn't loaded (via scsi_cmd_blk_ioctl(), in all kernels since 4.0 at least). Thus it doesn't depend on the sg driver. 2. 58-scsi-sg3_symlink.rules doesn't do any ioctls, thus doesn't depend on the sg driver. 3. 60-persistent-storate-tape.rules accesses only *bsg* devices and thus doesn't depend on the sg driver. 4. 60-persistent-storage.rules (missing in the above list) contains scsi_id calls which do SG_IO ioctls, but only on sd and sr devices, so the same argument as for 1. applies. 5. 40-libgphoto2.rules does not require the sg driver either. It checks for KERNEL=="sg[0-9]". It handles events generated by sg, which means that the sg module is loaded already when the rule is triggered. Thus it doesn't depend on early loading of the sg module. That said, autodetection of libgphoto devices may depend on sg being loaded. But that should probably be handled in the libgphoto2 itself. Adding Marcus Meissner as the libgphoto2 maintainer. Summarizing, unless I'm overlooking something essential, the early loading of the sg driver is really just a relict from the past and could be dropped. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c54 Lee Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(lduncan@suse.com) | --- Comment #54 from Lee Duncan --- no objections -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c56 --- Comment #56 from Martin Wilck --- (In reply to Franck Bui from comment #55)

Martin, has it been addressed eventually ? Thanks. Not yet. It has slipped through. Sorry.

Documentation of the behavior, for future reference. This was done with 4.17 (stable ddde22d). All cases without sg in modules-load.d. Case 1: sd compiled in, sg module, st module, no alias: sg not autoloaded, modprobe on scsi-t:* doesn't load sg.

$ modprobe --ignore-install --show-depends scsi:t-0x00 modprobe: FATAL: Module scsi:t-0x00 not found in directory /lib/modules/4.17.2 $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/st.ko

Case 2: sd compiled in, sg module, st module, alias in modprobe.d: sg autoloaded late, when the udev rule for the scsi device is processed in 80-drivers.rules (MODALIAS=scsi:t-0x00). modprobe on scsi-t:* _only_ loads sg:

$ modprobe --ignore-install --show-depends scsi:t-0x00 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko

Case 3: sd compiled in, sg module, st module, compiled-in alias sg autoloaded late, as in case 2. modprobe resolves deps correctly.

$ modprobe --ignore-install --show-depends scsi:t-0x00 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/st.ko insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko

Case 4: sd and sg compiled in, no modalias (actually, it doesn't matter if modalias is used in this case). sg is initialized early (at the same time as sd_mod).

$ modprobe --ignore-install --show-depends scsi:t-0x00 modprobe: FATAL: Module scsi:t-0x00 not found in directory /lib/modules/4.17.2 $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/st.ko

Side note: if sg is compiled in, the bzImage size on x86_64 increases by 16kB, which is ~0.2% of the current bzImage size. sg.ko (stripped) is ~55kB. Case 5: sd and sg modules, no modalias sg is not autoloaded. modprobe on scsi-t:* doesn't load sg.

$ modprobe --ignore-install --show-depends scsi:t-0x00 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sd_mod.ko $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/st.ko

Case 6: sd and sg modules, modalias in modprobe.d sg is autoloaded, but sd_mod is not. NO DISKS.

$ modprobe --ignore-install --show-depends scsi:t-0x00 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko

Case 7: sd and sg modules, built-in modalias sd and sg are autloaded later than normal (during udev processing of SCSI devices, as in case 2).

$ modprobe --ignore-install --show-depends scsi:t-0x00 insmod /lib/modules/4.17.2/kernel/drivers/scsi/sd_mod.ko insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko $ modprobe --ignore-install --show-depends scsi:t-0x01 insmod /lib/modules/4.17.2/kernel/drivers/scsi/st.ko insmod /lib/modules/4.17.2/kernel/drivers/scsi/sg.ko

Summary: case 2 and 6 (alias in modprobe.d) are garbage. Case 1 and 5 are the current situation (sg not autoloaded). Case 4 (sg built-in) and 3 and 7 (built-in MODULE_ALIAS in sg.c as in comment 5) do the job. This was known already, but I feel better having tested it for real. -- You are receiving this mail because: You are on the CC list for the bug.

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

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c60 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(martin.wilck@suse | |.com) | --- Comment #60 from Martin Wilck --- After some digging in the systemd changelog, I eventually found bug 761109, comment 9. It turns out that until v174 (pre-systemd), udev used to have a rule quite like the one I suggested in comment 57. This rule is still present in SLE11-SP4 (udev 147). That rule was removed in v174 (09637f74) with the informative log message "rules: do not load sg module". For bug 761109, Lee had contacted the udev developers about it, and they said that loading sg from an udev rule was "overkill" (the reason is likely to be the same that I described in comment 59). That's how /usr/lib/modules-load.d/sg.conf came to be. Thus I'll revert the addition of the udev rule, and fall back to the sg.conf approach (option 1 from comment 59). The only change will be that sg.conf is now maintained in suse-module-tools rather than in the systemd package. It's pretty disappointing for myself to reach this conclusion after so many hours of digging around, but it's probably better to follow the upstream approach. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c63 --- Comment #63 from Lee Duncan --- Thank you for all your work on this thankless job. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c64 --- Comment #64 from Swamp Workflow Management --- SUSE-RU-2018:4097-1: An update that has four recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1036463,1105495,1111183,1111300 CVE References: Sources used: SUSE Linux Enterprise Module for Basesystem 15 (src): suse-module-tools-15.0.1-3.3.1 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c65 --- Comment #65 from Swamp Workflow Management --- openSUSE-RU-2018:4113-1: An update that has four recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1036463,1105495,1111183,1111300 CVE References: Sources used: openSUSE Leap 15.0 (src): suse-module-tools-15.0.1-lp150.2.3.1 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c72 --- Comment #72 from Swamp Workflow Management --- SUSE-SU-2019:1364-1: An update that solves four vulnerabilities and has 9 fixes is now available. Category: security (moderate) Bug References: 1036463,1121563,1124122,1125352,1125604,1126056,1127557,1130230,1132348,1132400,1132721,1133506,1133509 CVE References: CVE-2019-3842,CVE-2019-3843,CVE-2019-3844,CVE-2019-6454 Sources used: SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src): systemd-234-24.30.1, systemd-mini-234-24.30.1 SUSE Linux Enterprise Module for Basesystem 15 (src): systemd-234-24.30.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

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

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c74 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- Assignee|martin.wilck@suse.com |fbui@suse.com --- Comment #74 from Martin Wilck --- (In reply to Martin Wilck from comment #73)

Fixed.

Not quite - the sg.conf change made it into SLE-15, but not SLE-15-SP1. I can also see no pending updates for systemd in SLE-15-SP1 Franck, please double check. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c76 --- Comment #76 from Franck Bui --- Hmm I'm not sure to follow... On my up to date SLE15-SP1 system: sles-15-sp1:~ # rpm -q --changelog systemd | grep sg.conf - Drop sg.conf, it's been taking over by suse-module-tools sles-15-sp1:~ # rpm -q systemd systemd-234-24.30.1.x86_64 sles-15-sp1:~ # rpm -qf /etc/modules-load.d/sg.conf suse-module-tools-15.0.2-3.6.1.x86_64 What am I missing ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c78 --- Comment #78 from Martin Wilck --- (In reply to Franck Bui from comment #76)

On my up to date SLE15-SP1 system:

sles-15-sp1:~ # rpm -q --changelog systemd | grep sg.conf - Drop sg.conf, it's been taking over by suse-module-tools sles-15-sp1:~ # rpm -q systemd systemd-234-24.30.1.x86_64

What am I missing ?

rpm -qlp /mounts/dist/install/SLP/SLE-15-SP1-Installer-LATEST/x86_64/DVD1/x86_64/systemd-234-24.25.1.x86_64.rpm | grep sg.conf /usr/lib/modules-load.d/sg.conf

systemd-234-24.30.1.x86_64 exists in SLE15-Update repos, but not in SLE15-SP1, AFAICS. Maybe you've got additional repos installed?

sles15-sp1-01:/home/mwilck # zypper up systemd Refreshing service 'Basesystem_Module_15_SP1_x86_64'. Refreshing service 'Desktop_Applications_Module_15_SP1_x86_64'. Refreshing service 'Development_Tools_Module_15_SP1_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP1_x86_64'. Refreshing service 'Server_Applications_Module_15_SP1_x86_64'. Loading repository data... Reading installed packages... No update candidate for 'systemd-234-24.25.1.x86_64'. The highest available version is already installed. Resolving package dependencies...

Nothing to do. sles15-sp1-01:/home/mwilck # zypper sl # | Alias | Name | Enabled | GPG Check | Refresh | Type --+--------------------------------------------+--------------------------------------------+---------+-----------+---------+------- 1 | Basesystem_Module_15_SP1_x86_64 | Basesystem_Module_15_SP1_x86_64 | Yes | ---- | Yes | ris 2 | Desktop_Applications_Module_15_SP1_x86_64 | Desktop_Applications_Module_15_SP1_x86_64 | Yes | ---- | Yes | ris 3 | Development_Tools_Module_15_SP1_x86_64 | Development_Tools_Module_15_SP1_x86_64 | Yes | ---- | Yes | ris 4 | SUSE_Linux_Enterprise_Server_15_SP1_x86_64 | SUSE_Linux_Enterprise_Server_15_SP1_x86_64 | Yes | ---- | Yes | ris 5 | Server_Applications_Module_15_SP1_x86_64 | Server_Applications_Module_15_SP1_x86_64 | Yes | ---- | Yes | ris 6 | SLES15-SP1-15.1-0 | SLES15-SP1-15.1-0 | No | ---- | ---- | rpm-md

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

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c80 --- Comment #80 from Martin Wilck --- (In reply to Michal Suchanek from comment #79)

...

systemd-234-24.30.1.x86_64 exists in SLE15-Update repos, but not in SLE15-SP1, AFAICS. Maybe you've got additional repos installed?

systemd was not branched in SP1 so it is inherited from SLE15:Update

On IBS, yes. But in the update repos?

Maybe your system is not set up properly for receiving updates?

AFAIK, I did exactly what our customers do. It was a straightforward fresh SLE15-SP1 installation, using the internal registration code from SCC. You can see the list of configured services in comment 78. The list of repos (all enabled, auto-configured during installation) is: SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SLE-Module-Desktop-Applications15-SP1-Pool SLE-Module-Desktop-Applications15-SP1-Updates SLE-Module-DevTools15-SP1-Pool SLE-Module-DevTools15-SP1-Updates SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates I changed nothing in the repo configuration. I checked on another, independently installed system, same effect. -- You are receiving this mail because: You are on the CC list for the bug.

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

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c84 --- Comment #84 from Marcus Meissner --- we are rereleasing updates from 15 ga into 15-sp1 that were too late for the GA cutoff. This was not yet done for the current systemd, but will be done soon. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:10309:moderate |obs:running:10309:moderate |ibs:running:11766:moderate |ibs:running:11766:moderate |ibs:running:10940:moderate | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c85 --- Comment #85 from Swamp Workflow Management --- SUSE-SU-2019:1364-2: An update that solves four vulnerabilities and has 9 fixes is now available. Category: security (moderate) Bug References: 1036463,1121563,1124122,1125352,1125604,1126056,1127557,1130230,1132348,1132400,1132721,1133506,1133509 CVE References: CVE-2019-3842,CVE-2019-3843,CVE-2019-3844,CVE-2019-6454 Sources used: SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): systemd-234-24.30.1, systemd-mini-234-24.30.1 SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): systemd-234-24.30.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1036463 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:11766:moderate |obs:running:10628:moderate |obs:running:10628:moderate |obs:running:10629:moderate |obs:running:10629:moderate | -- You are receiving this mail because: You are on the CC list for the bug.

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

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

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

http://bugzilla.suse.com/show_bug.cgi?id=1036463 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mmarek@suse.com | -- You are receiving this mail because: You are on the CC list for the bug.