[opensuse] Systemd says: systemd-modules-load.service failed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm being more polite and I'm not blaming systemd diretly this time ;-) Telcontar:~ # date;systemctl status systemd-modules-load.service Sun Jun 16 20:24:44 CEST 2013 systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since Sun, 2013-06-16 13:57:46 CEST; 6h ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Main PID: 4703 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/systemd-modules-load.service Jun 16 13:57:46 Telcontar.valinor systemd[1]: Starting Load Kernel Modules... Jun 16 13:57:46 Telcontar.valinor systemd-modules-load[4703]: libkmod: kmod_config_parse: /etc/modprobe.d/10-unsupported-modules.conf line 10: ignoring bad line starting with 'allow_unsupported_modules' Jun 16 13:57:46 Telcontar.valinor systemd-modules-load[4703]: Module 'cryptoloop' is already loaded Jun 16 13:57:46 Telcontar.valinor systemd-modules-load[4703]: Module 'twofish_x86_64' is already loaded Jun 16 13:57:46 Telcontar.valinor systemd-modules-load[4703]: Module 'twofish_x86_64_3way' is already loaded Jun 16 13:57:46 Telcontar.valinor systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE Jun 16 13:57:46 Telcontar.valinor systemd[1]: Failed to start Load Kernel Modules. Jun 16 13:57:46 Telcontar.valinor systemd[1]: Unit systemd-modules-load.service entered failed state Telcontar:~ # cat /etc/modprobe.d/10-unsupported-modules.conf # # Every kernel module has a flag 'supported'. If this flag is not set loading # this module will taint your kernel. You will not get much help with a kernel # problem if your kernel is marked as tainted. In this case you firstly have # to avoid loading of unsupported modules. # # Setting allow_unsupported_modules 1 enables loading of unsupported modules # by modprobe, setting allow_unsupported_modules 0 disables it. This can # be overriden using the --allow-unsupported-modules commandline switch. allow_unsupported_modules 1 Telcontar:~ # cer@Telcontar:~> grep MODULES_LOADED_ON_BOOT /etc/sysconfig/kernel MODULES_LOADED_ON_BOOT="cryptoloop twofish" cer@Telcontar:~> No inline comments this time... The "/etc/modprobe.d/10-unsupported-modules.conf" dates from Nov 14 2012, and I don't remember what it was for. Is that one causing trouble? - -- Cheers Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+BKMACgkQtTMYHG2NR9U0GQCfSNN/QiX7ujRz22nGxnLz+/dH LBcAoJaENDM8krlFP7xT2WAHFzb5ALh6 =LfSX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 16/06/13 14:32, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm being more polite and I'm not blaming systemd diretly this time ;-)
Telcontar:~ # date;systemctl status systemd-modules-load.service Sun Jun 16 20:24:44 CEST 2013 systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since Sun, 2013-06-16 13:57:46 CEST; 6h ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Main PID: 4703 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/systemd-modules-load.service
Jun 16 13:57:46 Telcontar.valinor systemd[1]: Starting Load Kernel Modules... Jun 16 13:57:46 Telcontar.valinor systemd-modules-load[4703]: libkmod: kmod_config_parse: /etc/modprobe.d/10-unsupported-modules.conf line 10: ignoring bad line starting with 'allow_unsupported_modules'
This is a warning, a harmless one and has already been fixed. libkmod does not support SUSE-SLE "unsupported modules" feature. openSUSE has no "unsupported modules" either, this is an SLE feature.
The "/etc/modprobe.d/10-unsupported-modules.conf" dates from Nov 14 2012, and I don't remember what it was for. Is that one causing trouble?
No, it just issues a warning. you can remove that file anyway, it is not the reason why the service ends with failure, just remove cryptoloop and twofish from MODULES_LOADED_ON_BOOT because they are already loaded. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 14:38 -0400, Cristian Rodríguez wrote:
El 16/06/13 14:32, Carlos E. R. escribió:
Jun 16 13:57:46 Telcontar.valinor systemd-modules-load[4703]: libkmod: kmod_config_parse: /etc/modprobe.d/10-unsupported-modules.conf line 10: ignoring bad line starting with 'allow_unsupported_modules'
This is a warning, a harmless one and has already been fixed. libkmod does not support SUSE-SLE "unsupported modules" feature.
Yes, I thought all of it were warnings, that's why I found it strange.
openSUSE has no "unsupported modules" either, this is an SLE feature.
The "/etc/modprobe.d/10-unsupported-modules.conf" dates from Nov 14 2012, and I don't remember what it was for. Is that one causing trouble?
No, it just issues a warning. you can remove that file anyway, it is not the reason why the service ends with failure, just remove cryptoloop and twofish from MODULES_LOADED_ON_BOOT because they are already loaded.
Done. I'll see what happens on next boot. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+C3cACgkQtTMYHG2NR9X9RwCffCRxYTJgp1SGZD4K5SEvpT76 H+AAn1YI7TfbXECUO2gli8y9n5EBY7ei =RnXK -----END PGP SIGNATURE-----
El 16/06/13 15:01, Carlos E. R. escribió:
Done. I'll see what happens on next boot.
btw, MODULES_LOADED_ON_BOOT should not be used.. For example, let's say you have need module "foobar" there, otherwise your system misses functionality. this are the correct steps to follow :-) 1. Make sure it is not a kernel, udev or a bug in an application, the best way to ensure that is to fill a bug report, the worst thing that could occur is the bug getting marked as INVALID. 2. in the meanwhile the bug gets fixed, issue echo "foobar" > /etc/modules-load.d/foobar.conf and "foobar" will be loaded at boot next time. PS: I would argue that having to load a module this way to make any application work is always a bug, no exceptions ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
El 16/06/13 15:01, Carlos E. R. escribió:
Done. I'll see what happens on next boot.
btw, MODULES_LOADED_ON_BOOT should not be used..
For example, let's say you have need module "foobar" there, otherwise your system misses functionality. this are the correct steps to follow :-)
1. Make sure it is not a kernel, udev or a bug in an application, the best way to ensure that is to fill a bug report, the worst thing that could occur is the bug getting marked as INVALID.
2. in the meanwhile the bug gets fixed, issue echo "foobar" > /etc/modules-load.d/foobar.conf and "foobar" will be loaded at boot next time.
PS: I would argue that having to load a module this way to make any application work is always a bug, no exceptions ;)
Hmm, how about these modules: ipmi_si, ipmi_devintf ? Sofar I have found no other/better way than creating a "/etc/modules-load.d/ipmi.conf". Works very well too :-) -- Per Jessen, Zürich (23.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 17/06/13 04:02, Per Jessen escribió:
Hmm, how about these modules:
ipmi_si, ipmi_devintf ?
Sofar I have found no other/better way than creating a "/etc/modules-load.d/ipmi.conf". Works very well too :-)
what package uses those modules ? software needing such modules must load them either with an udev rule, or using libkmod , or whatever. anything else, is a bug in my eyes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hmm, how about these modules:
ipmi_si, ipmi_devintf ?
Hrmm.. looking at the modules... ipmi_si has alias: pci:v*d*sv*sd*bc0Csc07i* alias: pci:v0000103Cd0000121Asv*sd*bc*sc*i* Therefore, it must be magically autoloaded if the hardware matches in the running system. if it does not, then there is a bug. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 15:19 -0400, Cristian Rodríguez wrote:
btw, MODULES_LOADED_ON_BOOT should not be used..
For example, let's say you have need module "foobar" there, otherwise your system misses functionality. this are the correct steps to follow :-)
1. Make sure it is not a kernel, udev or a bug in an application, the best way to ensure that is to fill a bug report, the worst thing that could occur is the bug getting marked as INVALID.
2. in the meanwhile the bug gets fixed, issue echo "foobar" > /etc/modules-load.d/foobar.conf and "foobar" will be loaded at boot next time.
PS: I would argue that having to load a module this way to make any application work is always a bug, no exceptions ;)
Well... In this machine, besides the upgraded work partition from 12.1 to 12.3 I have another one with a 12.3 freshly installed. This one created "/etc/sysconfig/kernel", and it contains: INITRD_MODULES="pata_jmicron ata_piix ata_generic" MODULES_LOADED_ON_BOOT="" I assume that the first entry is needed, for the correct initrd to be created. What I don't know is where is the logic to decide that parts of /usr (a separate partition) is copied to initrd. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+0E4ACgkQtTMYHG2NR9UP9ACgibuMTV2TpK/r7hQutL5wGkpa SPgAn0UWv1I4+J4HgnmtqP00Rb+Kv5Uz =zp2I -----END PGP SIGNATURE-----
Carlos E. R. wrote:
In this machine, besides the upgraded work partition from 12.1 to 12.3 I have another one with a 12.3 freshly installed. This one created "/etc/sysconfig/kernel", and it contains:
INITRD_MODULES="pata_jmicron ata_piix ata_generic"
MODULES_LOADED_ON_BOOT=""
I assume that the first entry is needed, for the correct initrd to be created.
Yup.
What I don't know is where is the logic to decide that parts of /usr (a separate partition) is copied to initrd.
mkinitrd and the scripts in /lib/mkinitrd/ -- Per Jessen, Zürich (26.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 12:08 +0200, Per Jessen wrote:
Carlos E. R. wrote:
What I don't know is where is the logic to decide that parts of /usr (a separate partition) is copied to initrd.
mkinitrd and the scripts in /lib/mkinitrd/
I ask because I wonder what happens if one decides, after installation, to move /usr to a separate partition, one simply has to make initrd again, or some setting has to be toggled. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+/tsACgkQtTMYHG2NR9WAXQCfaxz4X8zuRKA7ygHjQCkpCP6y Yo8Aniq933juAt1AI8QHyy6SGJDNr1vW =xqFP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2013-06-17 at 12:08 +0200, Per Jessen wrote:
Carlos E. R. wrote:
What I don't know is where is the logic to decide that parts of /usr (a separate partition) is copied to initrd.
mkinitrd and the scripts in /lib/mkinitrd/
I ask because I wonder what happens if one decides, after installation, to move /usr to a separate partition, one simply has to make initrd again, or some setting has to be toggled.
I don't know, but hasn't this been discussed quite a bit? I don't do it myself, but I thought there was some sort of (new?) issue in keeping /usr on a separate partition. -- Per Jessen, Zürich (29.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 14:30 +0200, Per Jessen wrote:
Carlos E. R. wrote:
I ask because I wonder what happens if one decides, after installation, to move /usr to a separate partition, one simply has to make initrd again, or some setting has to be toggled.
I don't know, but hasn't this been discussed quite a bit? I don't do it myself, but I thought there was some sort of (new?) issue in keeping /usr on a separate partition.
No issues "normally", this system I run has a separate /usr placed on a different disk, so it just works. But it is an upgraded system, not one modified later. There may issues in rescue mode, while /usr is not mounted. I believe I would need to use a rescue system if I have problems, but I can live with that, I guess. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG/IhUACgkQtTMYHG2NR9VzoACePb7zfunps6k3xcdcXuLebNel z+IAnjM1e+3fYK36GJo99hESRiXeNXED =xe+M -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Jun 17, 2013 at 8:30 AM, Per Jessen
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2013-06-17 at 12:08 +0200, Per Jessen wrote:
Carlos E. R. wrote:
What I don't know is where is the logic to decide that parts of /usr (a separate partition) is copied to initrd.
mkinitrd and the scripts in /lib/mkinitrd/
I ask because I wonder what happens if one decides, after installation, to move /usr to a separate partition, one simply has to make initrd again, or some setting has to be toggled.
I don't know, but hasn't this been discussed quite a bit? I don't do it myself, but I thought there was some sort of (new?) issue in keeping /usr on a separate partition.
There is an issue of keeping /usr on it's own partition and NOT using initrd. As of a release or two ago, this is difficult to do because there are libs and exe's on /usr that are used during boot. The opensuse solution is to mount /usr prior to full boot inside the initrd logic. People who don't want initrd have no decent way to solve the problem based on opensuse devs moving more and more libs/exe's from / to /usr. I don't think this is a systemd created problem, but at least for opensuse, the introduction of initrd mounting /usr prior to boot was needed to better allow systemd to control the full boot cycle. Then, once the decision was made to do that, it seems lots of exe's were moved from /sbin to /usr/sbin for no reason I could understand. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 17/06/13 05:00, Carlos E. R. escribió:
INITRD_MODULES="pata_jmicron ata_piix ata_generic"
MODULES_LOADED_ON_BOOT=""
If you need any such thing it will be a bug in mkinitrd, it must detect by itself what ATA drivers are needed for the machine to boot,regardless what INITRD_MODULES has. mkinitrd creates initrd not suitable to machine--> BUG, BUG, BUG ! ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 14:16 -0400, Cristian Rodríguez wrote:
El 17/06/13 05:00, Carlos E. R. escribió:
INITRD_MODULES="pata_jmicron ata_piix ata_generic"
MODULES_LOADED_ON_BOOT=""
If you need any such thing it will be a bug in mkinitrd, it must detect by itself what ATA drivers are needed for the machine to boot,regardless what INITRD_MODULES has.
mkinitrd creates initrd not suitable to machine--> BUG, BUG, BUG ! ;)
YaST created those two entries, not me :-) During installation. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG/VEQACgkQtTMYHG2NR9WC2wCfWf6+4mMRJcTJ0kK4IE+Kbb9B 0AkAnRyse1FlYkbe780GvO59n0QFnXXe =hiHc -----END PGP SIGNATURE-----
El 17/06/13 14:24, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2013-06-17 at 14:16 -0400, Cristian Rodríguez wrote:
El 17/06/13 05:00, Carlos E. R. escribió:
INITRD_MODULES="pata_jmicron ata_piix ata_generic"
MODULES_LOADED_ON_BOOT=""
If you need any such thing it will be a bug in mkinitrd, it must detect by itself what ATA drivers are needed for the machine to boot,regardless what INITRD_MODULES has.
mkinitrd creates initrd not suitable to machine--> BUG, BUG, BUG ! ;)
YaST created those two entries, not me :-)
awww crap :-) it probably does it to workaround old bugs.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 2013-06-16 at 21:01 +0200, Carlos E. R. wrote:
On Sunday, 2013-06-16 at 14:38 -0400, Cristian Rodríguez wrote:
No, it just issues a warning. you can remove that file anyway, it is not the reason why the service ends with failure, just remove cryptoloop and twofish from MODULES_LOADED_ON_BOOT because they are already loaded.
Done. I'll see what happens on next boot.
Nope - same thing: Telcontar login: root Password: Last login: Sun Jun 16 13:52:09 CEST 2013 on tty3 No mail. Starting Console Manager... Starting Authorization Manager... [ OK ] Started Authorization Manager. [ OK ] Started Console Manager. Last login: Sun Jun 16 22:20:49 on tty1 Have a lot of fun... Telcontar:~ # [ OK ] Started LSB: rpm config file scan. [ OK ] Reached target Multi-User. [FAILED] Failed to start Load Kernel Modules. [FAILED] Failed to start LSB: Console mouse support. [FAILED] Failed to start Daemonized version of spamassassin. [FAILED] Failed to start Network Manager Wait Online. Telcontar:~ # But gpm is working: Telcontar:~ # date;systemctl status gpm.service Sun Jun 16 22:23:46 CEST 2013 gpm.service - LSB: Console mouse support Loaded: loaded (/etc/init.d/gpm) Active: active (running) since Sun, 2013-06-16 22:19:43 CEST; 4min 2s ago Process: 1321 ExecStart=/etc/init.d/gpm start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/gpm.service └ 1431 /usr/sbin/gpm -m /dev/psaux -t exps2 Jun 16 22:19:43 Telcontar.valinor systemd[1]: Starting LSB: Console mouse support... Jun 16 22:19:43 Telcontar.valinor /usr/sbin/gpm[1431]: *** info [daemon/startup.c(136)]: Jun 16 22:19:43 Telcontar.valinor /usr/sbin/gpm[1431]: Started gpm successfully. Entered daemon mode. Jun 16 22:19:43 Telcontar.valinor gpm[1321]: Starting console mouse support (gpm)..done Jun 16 22:19:43 Telcontar.valinor systemd[1]: Started LSB: Console mouse support. Telcontar:~ # spamd is working: Telcontar:~ # date;systemctl status spamd.service Sun Jun 16 22:24:25 CEST 2013 spamd.service - Daemonized version of spamassassin Loaded: loaded (/usr/lib/systemd/system/spamd.service; enabled) Active: active (running) since Sun, 2013-06-16 22:20:05 CEST; 4min 20s ago Process: 1434 ExecStart=/usr/sbin/spamd $SPAMD_ARGS -r /var/run/spamd.pid (code=exited, status=0/SUCCESS) Process: 1361 ExecStartPre=/bin/echo Starting spamd: (code=exited, status=0/SUCCESS) Main PID: 1987 (/usr/sbin/spamd) CGroup: name=systemd:/system/spamd.service ├ 1987 /usr/sbin/spamd -d -c --max-children=6 -r /var/run/spamd.pid ├ 3731 spamd child └ 3732 spamd child Jun 16 22:20:03 Telcontar.valinor spamd[1987]: rules: meta test FROM_12LTRDOM has dependency 'ALL_TRUSTED' with a zero score Jun 16 22:20:03 Telcontar.valinor spamd[1987]: rules: meta test HDRS_LCASE has dependency 'ALL_TRUSTED' with a zero score Jun 16 22:20:03 Telcontar.valinor spamd[1987]: rules: meta test TBIRD_SPOOF has dependency 'ALL_TRUSTED' with a zero score Jun 16 22:20:05 Telcontar.valinor spamd[1987]: spamd: server started on port 783/tcp (running version 3.3.2) Jun 16 22:20:05 Telcontar.valinor spamd[1987]: spamd: server pid: 1987 Jun 16 22:20:05 Telcontar.valinor spamd[1987]: spamd: server successfully spawned child process, pid 3731 Jun 16 22:20:05 Telcontar.valinor spamd[1987]: spamd: server successfully spawned child process, pid 3732 Jun 16 22:20:05 Telcontar.valinor spamd[1987]: prefork: child states: IS Jun 16 22:20:05 Telcontar.valinor spamd[1987]: prefork: child states: II Jun 16 22:20:05 Telcontar.valinor systemd[1]: Started Daemonized version of spamassassin. Telcontar:~ # And network manager should already be disabled. Of course, "systemctl --failed" outputs nothing. I could use that one if it did not pipe to less. Ah, ok, that's "systemctl --failed --no-pager". So, I have now this: +++................................. #!/bin/bash # -x # # Author: Carlos E. Robinson # # Supersedes /etc/init.d/helloworld # called from /etc/systemd/system/helloworld.service grep FAILED /var/log/boot.log echo echo "-----" echo systemctl --failed --no-pager if [ $? -eq 0 ] ; then cat /usr/share/sounds/au/hal9.au > /dev/audio 2> /dev/null & /bin/logger -t Mine -p syslog.info "Saying hello world" else echo "Something failed" /bin/logger -t Mine -p syslog.info "Something failed on boot." fi .................................++- which prints: +++................................. Telcontar:~ # helloworld [FAILED] Failed to start Load Kernel Modules. [FAILED] Failed to start LSB: Console mouse support. [FAILED] Failed to start Daemonized version of spamassassin. [FAILED] Failed to start Network Manager Wait Online. ----- 0 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. Telcontar:~ # .................................++- Now I need a suitable sound file to play when something fails. The "Er... Houston, we have a problem" would be nice :-) -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
El 16/06/13 17:21, Carlos E. R. escribió:
On Sunday, 2013-06-16 at 21:01 +0200, Carlos E. R. wrote:
On Sunday, 2013-06-16 at 14:38 -0400, Cristian Rodríguez wrote:
No, it just issues a warning. you can remove that file anyway, it is not the reason why the service ends with failure, just remove cryptoloop and twofish from MODULES_LOADED_ON_BOOT because they are already loaded.
Done. I'll see what happens on next boot.
Nope - same thing:
You are showing all the irrelevant parts.. what does systemctl status systemd-modules-load.service says ? problems with networkmanager or gpm belong to a different subject of matter, we are discussing systemd-modules-load.service here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 16/06/13 17:21, Carlos E. R. escribió:
Done. I'll see what happens on next boot.
Nope - same thing:
You are showing all the irrelevant parts..
what does systemctl status systemd-modules-load.service says ?
Telcontar:~ # systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: active (exited) since Sun, 2013-06-16 22:18:56 CEST; 1h 14min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 312 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/systemd-modules-load.service Jun 16 22:18:56 Telcontar.valinor systemd[1]: Starting Load Kernel Modules... Jun 16 22:18:56 Telcontar.valinor systemd[1]: Started Load Kernel Modules. Jun 16 22:18:57 Telcontar.valinor systemd-modules-load[312]: libkmod: kmod_config_parse: /etc/modprobe.d/10-unsupported-modules.conf line 10: ignoring bad line starting with 'allow_unsupported_modules' Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Telcontar:~ # So it is failing at the start, and succeeding later, which matches the output of "systemctl --failed --no-pager" on the previous post which you did not notice.
problems with networkmanager or gpm belong to a different subject of matter, we are discussing systemd-modules-load.service here.
Ok, right... I'm just tracking all reported failures. They are al similar problems : a failure that is not such. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+MYIACgkQtTMYHG2NR9U6HwCff+zXq+fsLGbAd9so3c32FdkQ BwUAn2zG989GFI+YEsOHJlXWHUZxWYkN =jtf/ -----END PGP SIGNATURE-----
El 16/06/13 17:43, Carlos E. R. escribió:
So it is failing at the start, and succeeding later
No, you get this confusion because you are retriving information from an unreliable source "boot.log", no idea what is writting to that file but it is not systemd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 16/06/13 17:43, Carlos E. R. escribió:
So it is failing at the start, and succeeding later
No, you get this confusion because you are retriving information from an unreliable source "boot.log", no idea what is writting to that file but it is not systemd.
You are partly right. It is systemd, systemv is not running here, but the date does not match last boot, and the format matches what systemd prints on the screen, colours et all: +++······································· Trying manual resume from /dev/disk/by-label/b_swap Invoking userspace resume from /dev/disk/by-label/b_swap resume: libgcrypt version: 1.5.0 Trying manual resume from /dev/disk/by-label/b_swap Invoking in-kernel resume from /dev/disk/by-label/b_swap Waiting for device /dev/disk/by-label/a_main to appear: ok fsck from util-linux 2.21.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/sdc7 a_main: clean, 63742/1313280 files, 2308757/5242880 blocks fsck succeeded. Mounting root device read-write. Mounting root /dev/disk/by-label/a_main mount -o rw,noauto,acl,user_xattr -t ext4 /dev/disk/by-label/a_main /root fsck from util-linux 2.21.2 [/sbin/fsck.xfs (1) -- /dev/sdd8] fsck.xfs -a /dev/sdd8 /sbin/fsck.xfs: XFS file system. Mounting /usr Welcome to openSUSE 12.3 (Dartmouth) (x86_64)! [ OK ] Listening on Syslog Socket. [ OK ] Reached target Remote File Systems. Starting Replay Read-Ahead Data... Starting Collect Read-Ahead Data... ·······································++- Telcontar:~ # l /var/log/boot.log - -rw-r--r-- 1 root root 16675 Jun 10 01:04 /var/log/boot.log Telcontar:~ # It belongs to one of my initial boots after upgrade: 2013-06-10 01:03:40+02:00 - Booting the system now ================================================================================ Linux Telcontar.valinor 3.7.10-1.11-desktop #1 SMP PREEMPT Thu May 16 20:27:27 UTC 2013 (adf31bb) x86_64 x86_64 x86_64 GNU/Linux 2013-06-10 01:24:42+02:00 - Halting the system now =========================================== uptime: 01:24am up 0:21, 0 users, load average: 0.28, 0.39, 0.44 with: <0.6> 2013-06-10 01:27:10 Telcontar kernel - - - [ 0.000000] Command line: root=/dev/disk/by-label/a_main resume=/dev/disk/by-label/b_swap splash=verbose quiet vga=0x31a Next boot had the same command line and did not generate the file: 2013-06-10 01:24:42+02:00 - Halting the system now =========================================== uptime: 01:24am up 0:21, 0 users, load average: 0.28, 0.39, 0.44 2013-06-10 01:27:08+02:00 - Booting the system now ================================================================================ Linux Telcontar.valinor 3.7.10-1.11-desktop #1 SMP PREEMPT Thu May 16 20:27:27 UTC 2013 (a <0.6> 2013-06-10 01:27:10 Telcontar kernel - - - [ 0.000000] Command line: root=/dev/disk/by-label/a_main resume=/dev/disk/by-label/b_swap splash=verbose quiet vga=0x31a Curious... why was that file created, by what? I'm not the only one that has it (Patrick mentioned it yesterday). - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+OPQACgkQtTMYHG2NR9WTMQCfQmFOyZ8qWCqkQCR/PIBBcSnD DscAn1UGa66E9CeTbvlh+fdQJiDnsgcH =9CH8 -----END PGP SIGNATURE-----
El 16/06/13 18:15, Carlos E. R. escribió:
You are partly right Curious... why was that file created, by what?
I only know it was not created by systemd and that you should not rely on what it says. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 16/06/13 18:15, Carlos E. R. escribió:
You are partly right Curious... why was that file created, by what?
I only know it was not created by systemd and that you should not rely on what it says.
I don't rely on it any more, but I know that it was created by something related to systemd, the format matches. It is exactly what systemd prints to the text screen in "splash=verbose" mode, including the color. Look at the end of the file: +++··························· [FAILED] Failed to start Daemonized version of spamassassin. See 'systemctl status spamd.service' for details. [ OK ] Started LSB: Configure network interfaces and set up routing. [ OK ] Started LSB: virus scanner daemon. [FAILED] Failed to start Network Manager Wait Online. See 'systemctl status NetworkManager-wait-online.service' for details. [ OK ] Reached target Network. Starting LSB: Start the MySQL database server... Starting Command Scheduler... [ OK ] Started Command Scheduler. Starting LSB: Domain Name System (DNS) server, named... Starting LSB: Samba SMB/CIFS file and print server... Starting LSB: NFS client services... Starting LSB: Starts the xinet daemon. Be aware that xinetd doesn't start if no service is configured to run under it. To enable xinetd services go to YaST Network Services (xinetd) section.... Starting /etc/init.d/boot.local Compatibility... [ OK ] Started /etc/init.d/boot.local Compatibility. Starting Wait for Plymouth Boot Screen to Quit... Starting Terminate Plymouth Boot Screen... ···························++- Do you see the message about "See 'systemctl status spamd.service'"? It is obvious that something related to systemd wrote it. Perhaps Plymouth? - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+RY0ACgkQtTMYHG2NR9UFQwCfbNwBatjOpk8DMbNqS4Xim/eJ vIUAnjtFlmFzpRgGo/USsA2wPwxd09Xi =hqzE -----END PGP SIGNATURE-----
El 16/06/13 19:09, Carlos E. R. escribió:
Do you see the message about "See 'systemctl status spamd.service'"? It is obvious that something related to systemd wrote it. Perhaps Plymouth?
Yes, I just looked at the source code, and can confirm it is plymouth that wrote that file. I will fix the package so plymouth.rpm "owns" that file to avoid further confusion. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 16/06/13 19:11, Cristian Rodríguez escribió:
I will fix the package so plymouth.rpm "owns" that file to avoid further confusion.
Fixed in plymouth.rpm request id 179217 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 16/06/13 19:09, Carlos E. R. escribió:
Do you see the message about "See 'systemctl status spamd.service'"? It is obvious that something related to systemd wrote it. Perhaps Plymouth?
Yes, I just looked at the source code, and can confirm it is plymouth that wrote that file.
Mistery solved! :-)
I will fix the package so plymouth.rpm "owns" that file to avoid further confusion.
Thanks! Unfortunately (for me) I don't use Plymouth. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+U6YACgkQtTMYHG2NR9XZ1ACfSsXdJRRuFH6tCGzftX08S0ix ipwAn2VFhAeDJjZ5cn6Qfv3VtfEvie0w =WDth -----END PGP SIGNATURE-----
participants (4)
-
Carlos E. R. -
Cristian Rodríguez -
Greg Freemyer -
Per Jessen