[Bug 1036463] New: Please take over /usr/lib/modules-load.d/sg.conf
http://bugzilla.suse.com/show_bug.cgi?id=1036463 Bug ID: 1036463 Summary: Please take over /usr/lib/modules-load.d/sg.conf Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: fbui@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Hi kernel maintainers, Currently systemd package ships the following file: $ cat /usr/lib/modules-load.d/sg.conf # load sg module at boot time sg I don't know if it's still needed but if so it doesn't seem appropriate to ship it through systemd since it seems to be a workaround for a missing driver dependency or something similar. Would you take this file over ? 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#c1 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #1 from Takashi Iwai <tiwai@suse.com> --- 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#c2 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hare@suse.com, | |jeffm@suse.com, | |lduncan@suse.com, | |mmarek@suse.com Flags| |needinfo?(lduncan@suse.com) --- Comment #2 from Takashi Iwai <tiwai@suse.com> --- Never mind, I found it in the changelog, pointing to bsc#761109. Lee, could you guys take a look again? Do we still need it? And, if yes, can we resolve it by softdep or such instead? Adding more other relevant guys to the loop, too. -- 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 <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(lduncan@suse.com) | --- Comment #3 from Lee Duncan <lduncan@suse.com> --- 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#c4 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(lduncan@suse.com) --- Comment #4 from Franck Bui <fbui@suse.com> --- (In reply to Lee Duncan from comment #3)
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.
Could you explain why the sg driver is special here and needs to be loaded manually unlike most other drivers ? Also how does exactly udev rely on it ? 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#c5 --- Comment #5 from Michal Marek <mmarek@suse.com> --- 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#c6 Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Flags|needinfo?(lduncan@suse.com) | --- Comment #6 from Lee Duncan <lduncan@suse.com> --- (In reply to Franck Bui from comment #4)
(In reply to Lee Duncan from comment #3)
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.
Could you explain why the sg driver is special here and needs to be loaded manually unlike most other drivers ?
The sg driver creates generic SCSI device access points for SCSI devices when they are attached, if and only if it is loaded at that time. So either the burden must be on each and every SCSI device added to ensure that the "sg" driver is loaded before it probes a new device, or the sg driver must be pre-loaded. It has always been pre-loaded.
Also how does exactly udev rely on it ?
Thanks.
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
Out of those, it looks like perhaps the only rules depending on SG devices these days is the libgphoto2 library? So perhaps I misspoke. But certainly customers expect the sg device to be present when they plug in devices, as shown in the original bug (see bsc#761109). -- 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 <oneukum@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oneukum@suse.com --- Comment #7 from Oliver Neukum <oneukum@suse.com> --- (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#c8 --- Comment #8 from Hannes Reinecke <hare@suse.com> --- Correct. Modules might be loaded at any order, so the 'sd' module might be loaded prior to the 'sg' module. Also the 'init' function from the 'sd' driver might be called prior to the 'init' function of the 'sg' driver, causing the sd device to appear _before_ the sg device, and the udev rules relying on the sg device to be present will fail. -- 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 <tiwai@suse.com> --- 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#c10 --- Comment #10 from Hannes Reinecke <hare@suse.com> --- The 'sg' module would slurp in the scsi module. If that's okay I'm fine with it. -- 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 <mmarek@suse.com> --- 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#c12 --- Comment #12 from Lee Duncan <lduncan@suse.com> --- (In reply to Michal Marek from comment #11)
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?
I suspect an issue may come up if a customer scripts a sequence where they install there device, rescan the SCSI bus, and then expect sg access to the device, particularly in a busy system. But that is speculation. -- 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 <oneukum@suse.com> --- 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#c14 --- Comment #14 from Franck Bui <fbui@suse.com> --- If you can write a udev rule which is good enough to prevent loading the sg module on every boot then fine. But currently, the fact that sg is a module and is loaded on every boot unconditionally defeats the whole purpose of the module concept. Quite frankly I don't see the problem to make this driver a builtin. -- 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 <tiwai@suse.com> --- 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#c16 --- Comment #16 from Franck Bui <fbui@suse.com> --- (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. My 2 cents. -- 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 <tiwai@suse.com> --- (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#c18 --- Comment #18 from Franck Bui <fbui@suse.com> --- (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 ? I cannot see a reason why TW and SLE should differ on that matter. 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. -- 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 <tiwai@suse.com> --- (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#c20 --- Comment #20 from Franck Bui <fbui@suse.com> --- (In reply to Takashi Iwai from comment #19)
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.
Sorry but I really don't see the point in making SLE different then. If the faster boot on TW is the only reason then I'm puzzled. Why would we want to keep a slower boot on SLE if there's no technical reason to do so ? Especially since this force us to load unconditionally the module on boot anyways. -- 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 <oneukum@suse.com> --- (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#c22 --- Comment #22 from Takashi Iwai <tiwai@suse.com> --- Also, my slight concern is that built-in solution will make the system unusable with the older kernels or with different kernel configs. -- 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 <oneukum@suse.com> --- (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#c24 --- Comment #24 from Takashi Iwai <tiwai@suse.com> --- (In reply to Oliver Neukum from comment #23)
(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.
Yes, but we usually preserve the availability without much manual configuration. In anyway, the kernel config change in that level needs the general consensus. Raise it on kernel ML if this is really the best way to go over other options. -- 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 <lduncan@suse.com> --- 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 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c26 --- Comment #26 from Franck Bui <fbui@suse.com> --- In order to make some progress, at least from systemd POV, I've created the following PR: https://github.com/openSUSE/suse-module-tools/pull/1 So the plan for now is to move sg.conf in suse-module-tools. -- 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 <hare@suse.com> 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#c27 --- Comment #27 from Franck Bui <fbui@suse.com> --- Hi guys, any updates on this one ? Is CONFIG_SCSI=y finally set for SLE15 kernels as well ? 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#c28 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com --- Comment #28 from Michal Suchanek <msuchanek@suse.com> --- 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#c29 --- Comment #29 from Michal Suchanek <msuchanek@suse.com> --- hm, we have SCSI=y only on ARM. -- 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 <fbui@suse.com> --- 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#c31 --- Comment #31 from Michal Suchanek <msuchanek@suse.com> --- What's exactly the problem with sg being module? When you reload it the devices are recreated. So only race can be between an udev rule requiring the module and loading the module, right? Using sg_utils or gphoto2 by hand or from desktop will not race with loading the module at boot. Two different packages require the module loaded so the only logical place for sg.conf is udev or some dedicated package for modprobe rules. -- 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 <fbui@suse.com> --- (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#c33 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.wilck@suse.com Flags| |needinfo?(martin.wilck@suse | |.com) --- Comment #33 from Michal Suchanek <msuchanek@suse.com> --- is there any problem with including the sg.conf in suse-module-tools? -- 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 <msuchanek@suse.com> --- 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#c35 --- Comment #35 from Martin Wilck <martin.wilck@suse.com> --- Sure, this can be done. I'd suggest the following different approach though: cat >/etc/modprobe.d/05-sg.conf <<EOF softdep scsi_mod post: sg EOF As opposed to force-loading the module, it has the advantage not to load sg if really no SCSI modules are required. dracut resolves the dependency just fine, it runs "modprobe --ignore-install --show-depends" on hostonly modules, which will list sg for any module that requires scsi_mod with the above rule in place. Thus sg will be included in the initrd, and loaded before any other SCSI driver.
$ modprobe --ignore-install --show-depends sd_mod insmod /lib/modules/4.4.92-6.18-default/kernel/drivers/scsi/scsi_mod.ko insmod /lib/modules/4.4.92-6.18-default/kernel/drivers/scsi/scsi_mod.ko insmod /lib/modules/4.4.92-6.18-default/kernel/drivers/scsi/sg.ko insmod /lib/modules/4.4.92-6.18-default/kernel/drivers/scsi/sd_mod.ko
OK? -- 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 <msuchanek@suse.com> --- 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#c37 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tchvatal@suse.com Flags| |needinfo?(tchvatal@suse.com | |) --- Comment #37 from Martin Wilck <martin.wilck@suse.com> --- 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 -- 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 <tchvatal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tchvatal@suse.com | |) | --- Comment #38 from Tomáš Chvátal <tchvatal@suse.com> --- (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#c39 --- Comment #39 from Franck Bui <fbui@suse.com> --- (In reply to Tomáš Chvátal from comment #38)
I've merged the PR and added you as commiter :)
This PR doesn't do what Martin suggested in comment #35 AFAICS. -- 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 <fbui@suse.com> --- (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 <<EOF softdep scsi_mod post: sg EOF
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#c41 --- Comment #41 from Tomáš Chvátal <tchvatal@suse.com> --- (In reply to Franck Bui from comment #39)
(In reply to Tomáš Chvátal from comment #38)
I've merged the PR and added you as commiter :)
This PR doesn't do what Martin suggested in comment #35 AFAICS.
Ah, darn, well then first job martin can do is to run revert :P -- 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 <msuchanek@suse.com> --- 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#c43 --- Comment #43 from Franck Bui <fbui@suse.com> --- (In reply to Michal Suchanek from comment #42)
Either way, unless there is very good reason I do not see that happening this close to release.
The file that Martin wants to introduce is new so I don't see the problem. Anyways if the kernel packages want to install their configuration files in /etc, let it be. -- 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 <martin.wilck@suse.com> --- (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#c45 --- Comment #45 from Martin Wilck <martin.wilck@suse.com> --- I've submitted an update to Base:System, but I'm not in maintainer role for this package on OBS (just IBS), so I also submitted a requestmaintainership for OBS. -- 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 <martin.wilck@suse.com> --- 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#c47 --- Comment #47 from Martin Wilck <martin.wilck@suse.com> --- We have a inconsistent configuration in tumbkleweed/factory.
CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_SG=m
If we insist that sd (soft-)depends on sg, we ought to 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#c48 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com --- Comment #48 from Martin Wilck <martin.wilck@suse.com> --- (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#c49 --- Comment #49 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Martin Wilck from comment #48)
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.
This argument is about system boot, udev rules, and device detection only. We've been early-loading sg for decades, so it's quite likely that user-space applications, either shipped or 3rd party, rely on the sg driver being present. If we don't load sg at all, such applications may fail in strange ways. But to address that issue, "late" loading of sg would be sufficient. Thus the approach of comment 5 should work, and should also address libgphoto2's needs.
From a technical point of view, comment 5 is actually too broad - as argued in comment 48, loading sg isn't necessary for devices that forward ioctls to scsi_cmd_ioctl(), which, AFAICS, applies at least for sd, sr, and st. Anyway, user space apps may not be aware of this, and look for the sg device nodes anyway, so we should probably apply comment 5 even if it's not strictly necessary.
Comments, please. -- 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 <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(lduncan@suse.com) | --- Comment #54 from Lee Duncan <lduncan@suse.com> --- 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#c55 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(martin.wilck@suse | |.com) --- Comment #55 from Franck Bui <fbui@suse.com> --- Martin, has it been addressed eventually ? 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#c56 --- Comment #56 from Martin Wilck <martin.wilck@suse.com> --- (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 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c57 --- Comment #57 from Martin Wilck <martin.wilck@suse.com> --- Although I said otherwise in comment 53, I feel now that a SUSE-specific kernel patch is sub-optimal for this purpose. To be honest, that's the real reason why the patch hasn't been submitted yet. Here's yet another idea.
cat >/etc/udev/rules.d/81-sg.rules <<EOF ACTION=="add", ENV{MODALIAS}=="scsi:t-*", RUN{builtin}+="kmod load sg" EOF
Advantages: 1 This loads sg only if SCSI devices are present. 2 it's executed after 80-drivers.rules, so the specific drivers sd_mod / st / ses ... will be loaded before sg, regardless if they're built-in or modules. 3 no kernel modification needed. 4 I'm guessing that Franck wouldn't want to take it in the udev package, but we can ship it in sg3_utils. 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 Swamp Workflow Management <swamp@suse.de> 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#c59 --- Comment #59 from Martin Wilck <martin.wilck@suse.com> --- As I've pushed the udev rule solution to the latest suse-module-tools package, I've started having doubts again. But I still think the solution is the best one. Documenting my thoughts here for future reference. While the udev solution has the desired effect in terms of module load ordering, it has the disadvantage that an additional call to udev's "kmod" built-in is made for every SCSI device. That call is pretty cheap, as the expensive part (kmod initialization, configuration parsing) is done during udev startup. After its first invocation, the RUN{builtin}="kmod load sg" call comes down to a read() on /sys/module/sg/initstate. I suppose it doesn't do much harm. FTR, the alternatives are 1 Simply add sg.conf in its current form to suse-module-tools, as originally requested by Frack (comment 26, disadvantage: loading sg on non-SCSI systems) 2 SUSE specific kernel patch with compiled-in alias (comment 5, disadvantage: one more SUSE kernel patch with no chance of being upstreamed) 3 Drop early loading of sg altogether (discussion in comment 48 ff., disadvantage: possible regressions in some user space tools, no concrete evidence) Opinions welcome. -- 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 <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(martin.wilck@suse | |.com) | --- Comment #60 from Martin Wilck <martin.wilck@suse.com> --- 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#c61 --- Comment #61 from Swamp Workflow Management <swamp@suse.de> --- This is an autogenerated message for OBS integration: This bug (1036463) was mentioned in https://build.opensuse.org/request/show/647026 Factory / suse-module-tools -- 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 <lduncan@suse.com> --- 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 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|maint:planned:update |ibs:running:9462: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#c64 --- Comment #64 from Swamp Workflow Management <swamp@suse.de> --- 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 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:9462: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#c65 --- Comment #65 from Swamp Workflow Management <swamp@suse.de> --- 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 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| |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#c72 --- Comment #72 from Swamp Workflow Management <swamp@suse.de> --- 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 <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|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 Swamp Workflow Management <swamp@suse.de> 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#c73 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #73 from Martin Wilck <martin.wilck@suse.com> --- Fixed. -- 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 <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- Assignee|martin.wilck@suse.com |fbui@suse.com --- Comment #74 from Martin Wilck <martin.wilck@suse.com> --- (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#c75 --- Comment #75 from Martin Wilck <martin.wilck@suse.com> --- FTR, the latest suse-module-tools update candidate package for factory and SLE15-SP1 (15.1.15) will move sg.conf to /usr/lib/modules.d, where it belongs. File conflicts with systemd do not arise on SLE15-SP1, as the file is identical. -- 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 <fbui@suse.com> --- 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#c77 --- Comment #77 from Swamp Workflow Management <swamp@suse.de> --- This is an autogenerated message for OBS integration: This bug (1036463) was mentioned in https://build.opensuse.org/request/show/710014 Factory / suse-module-tools -- 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 <martin.wilck@suse.com> --- (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#c79 --- Comment #79 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Martin Wilck from comment #78)
(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?
systemd was not branched in SP1 so it is inherited from SLE15:Update Maybe your system is not set up properly for receiving updates? -- 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 <martin.wilck@suse.com> --- (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 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c81 --- Comment #81 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Martin Wilck from comment #80)
(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:
Sounds like an update repo setup issue then -- 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 <swamp@suse.de> 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#c83 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maint-coord@suse.de Flags| |needinfo?(maint-coord@suse. | |de) --- Comment #83 from Martin Wilck <martin.wilck@suse.com> --- @maint-coord, I have tried this (comment 80) on a clean fresh SLE15-SP1 install (no update from beta), and again I get told "No update candidate for 'systemd-234-24-25-1-x86_64'". Can you please check the repos for SLE15-SP1? Why is systemd-234-24.30.1 not available? -- 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 <meissner@suse.com> --- 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 <swamp@suse.de> 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 Swamp Workflow Management <swamp@suse.de> 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 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:10309:moderate |obs:running:10309:moderate |ibs:running:11766:moderate |ibs:running:11766:moderate | |obs:running:10628: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 <swamp@suse.de> --- 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 <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:10309:moderate |ibs:running:11766:moderate |ibs:running:11766:moderate |obs:running:10628:moderate |obs:running:10628: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 <swamp@suse.de> 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 http://bugzilla.suse.com/show_bug.cgi?id=1036463#c86 --- Comment #86 from Swamp Workflow Management <swamp@suse.de> --- SUSE-RU-2019:1984-1: An update that has four recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1036463,1127155,1134819,937216 CVE References: Sources used: SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): suse-module-tools-15.1.16-3.3.1 SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): suse-module-tools-15.1.16-3.3.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 <swamp@suse.de> 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 Joao Walter Bruno Filho <bfilho@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(maint-coord@suse. | |de) | -- 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 <swamp@suse.de> 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 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|fbui@suse.com |martin.wilck@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=1036463 Swamp Workflow Management <swamp@suse.de> 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 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:10629:moderate |obs:running:11095: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 <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mmarek@suse.com | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1036463 https://bugzilla.suse.com/show_bug.cgi?id=1036463#c90 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #90 from Martin Wilck <martin.wilck@suse.com> --- Done -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com