Bugzilla – Bug 1036463
Please take over /usr/lib/modules-load.d/sg.conf
Last modified: 2022-07-14 16:39:05 UTC
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.
Agreed that it's not appropriate to be shipped in systemd, but do you know where did it come from?
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.
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.
(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.
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?
(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).
(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.
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.
So what's the merit of making sg as a module?
The 'sg' module would slurp in the scsi module. If that's okay I'm fine with it.
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?
(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.
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.
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.
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?
(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.
(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.
(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.
(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.
(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.
(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.
Also, my slight concern is that built-in solution will make the system unusable with the older kernels or with different kernel configs.
(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.
(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.
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.
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.
Hi guys, any updates on this one ? Is CONFIG_SCSI=y finally set for SLE15 kernels as well ? Thanks.
We have SCSI=y in SLE15 so I suppose we can make sg built-in as well.
hm, we have SCSI=y only on ARM.
So can we make it also for other arches too and finally make sg built-in as well for SLE15 and Factory ? Thanks.
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.
(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.
is there any problem with including the sg.conf in suse-module-tools?
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
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?
That's fine too I guess
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
(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 ;)
(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.
(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...
(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
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.
(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.
(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.
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.
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.
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.
(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.
(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.
FWIW libgphoto2 uses the ruleset to hand out user-access-permissions for sgX devices for a limited set of cameras and picture frames that it can control (most cameras are just libusb users and do not use sgX). It assume sg loaded for this I think.
(In reply to Marcus Meissner from comment #50) > FWIW libgphoto2 uses the ruleset to hand out user-access-permissions for sgX > devices for a limited set of cameras and picture frames that it can control > (most cameras are just libusb users and do not use sgX). It assume sg loaded > for this I think. Yes, that makes sense. The rules that I'm seeing serve only the purpose of setting 'ENV{ID_GPHOTO2}=1' and 'ENV{GPHOTO2_DRIVER}="proprietary"'. GPHOTO2_DRIVER doesn't seem to be used anywhere, but ID_GPHOTO2 is used to set the uaccess tag, as you're saying, and COLORD_DEVICE if colord is installed. Anyway, comment 5 should be fully sufficient to make this work.
We can't implement comment 5 using a modprobe.d "alias" statement, because that would take precedence over the built-in modaliases. But if the generic alias is set in the kernel sg module, it would work.
Last call for objections. I'm going to push the solution from comment 5 to the kernel unless you object. Rationale in comment 46 ff.
no objections
Martin, has it been addressed eventually ? Thanks.
(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.
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?
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.
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.
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
Thank you for all your work on this thankless job.
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
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
@Franck, sg.conf has been in suse-module-tools for some time now. You can remove it from systemd, at least in SLE15-SP1 and Factory. You could put a "Conflicts: suse-module-tools < 15.0.1" dependency if you want to avoid the file missing altogether.
(In reply to Martin Wilck from comment #66) > @Franck, sg.conf has been in suse-module-tools for some time now. You can > remove it from systemd, at least in SLE15-SP1 and Factory. You could put a Thanks for the update Martin. Factory already dropped it. Regarding SLE15-SP1, you actually meant both SLE15 and SLE15-SP1, right ? I'm asking because systemd package is inherited by SP1 from SLE15 and it would be unfortunate to fork it just for this change.
Yes sure, suse-module-tools 15.0.1 is also in SLE15. Please use the Conflicts: line above to avoid trouble. I'd not use "Requires:" because it would pull in suse-module-tools where it isn't necessary.
Done (for SLE15+): https://build.suse.de/package/rdiff/home:fbui:systemd:SLE-15/systemd?linkrev=base&rev=88
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.
Fixed.
(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.
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.
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 ?
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
(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
(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?
(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.
(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
@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?
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.
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.
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.
Done