with the 6th round of Mageia-4-RC-LiveCD-KDE4-en-i586-CD and Mageia-4-RC-LiveCD-GNOME-en-i586-CD, but not yet in the boot screen, numlock is enabled and is auto-enabled time and again after turning it off. This is on a ThinkPad R50e, Live mode wouldn't start directly from the boot menu (gave a black frozen sceen, even with safe mode) so I tried with systemd.unit=multi-user.target I saw a message that began with "Started LSB: Locks numlock ......" but didn't see all of it. After reaching a prompt and unlocking numlock, after typing "live" it is locked again, then unlocking and typing "su" and it is locked again, unlocking and typing "systemctl start prefdm.service" and again it is locked :-/ After having reached KDE, after unlocking there is no more auto-locking @ tv sorry if I assigned to the wrong package and the wrong person. Reproducible: Steps to Reproduce:
CC: (none) => mageiaAssignee: thierry.vignaud => bugsquadSource RPM: drakx-kbd-mouse-x11 => numlock
btw, this means that, when typing "live", I get "35ve" and instead of "su" I get "s4" etc,
CC: (none) => davidwhodginsWhiteboard: (none) => 4RC
Actually it's a fallout of the fix for nonbooting live images: https://bugs.mageia.org/show_bug.cgi?id=11574 I've done this as a quick fix to: /usr/lib/libDrakX/harddrake/autoconf.pm --- autoconf.pm.old 2014-01-06 19:48:29.000000000 +0100 +++ autoconf.pm 2014-01-11 23:10:33.363368427 +0100 @@ -111,10 +111,10 @@ # } else { # $do_pkgs->ensure_is_installed("numlock", "/etc/rc.d/init.d/numlock"); # } - require services; - services::set_status("apmd", -e "/proc/apm"); - services::set_status("laptop-mode", $on_laptop); - services::set_status("numlock", !$on_laptop); +# require services; +# services::set_status("apmd", -e "/proc/apm"); +# services::set_status("laptop-mode", $on_laptop); +# services::set_status("numlock", !$on_laptop); } sub cpufreq() { as _any_ of those "services::set_status..." will lock up the boot process while I did my own tests I disabled the numlock service with draklive, but forgot to do it for the round 6 live medias :/ I meant to investigate it more, and file a bug about it but didnt get around to it yet...
CC: (none) => sysadmin-bugs, thierry.vignaud, tmbComponent: RPM Packages => Release (media or process)Hardware: i586 => AllAssignee: bugsquad => tmbSource RPM: numlock => drakxtools-backend
Acctually, could this be a fallout of systemctl getting verbose: on mga3: systemctl enable numlock.service numlock.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig numlock on on cauldron: systemctl enable numlock.service numlock.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig numlock on The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). maybe all that confuses harddrake ?
For Blino & Colin...
CC: (none) => mageiaComponent: Release (media or process) => RPM Packages
Hmm, I wouldn't have thought it would confuse harddrake as such, but it certainly looks wrong either way. Will take a look.
OK, this might actually be a more serious problem than it looks.... I can silence the verboseness quite easily (looks like a simple patch), but the *real* bug is not that. It seems that when enabling sysvinit units, it triggers a very strange daemon-reload that puts things in an inconsistent state. This is actually what is causing the /run/nologin files to appear sometimes after upgrading packages. It's a strange one as it seems to related to memory access. Stripping out all the calls and just doing the reload doesn't seem to trigger the problem, so it appears to be some kind of stack corruption. With this in mind I'm going to look at this as a priority this evening (sadly I have to get on with $DAYJOB right now), but I would actually recommend holding back on final RCs until I can get this one worked out :s
(FWIW, this root cause could explain slow boots and non-completing first boots etc too that have been reported)
CC: (none) => wilcal.int
Hopefully this is now fixed with a combination of patches to chkconfig and systemd.
See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1043212
(In reply to Colin Guthrie from comment #8) > Hopefully this is now fixed with a combination of patches to chkconfig and > systemd. Thx, Colin :-) looking forward to the new isos to test
with the new, round 7 isos: The ThinkPad R50e still won't boot in normal mode (that leads to a frozen light black screen), but when using systemd.unit=multi-user.target I get a working Live without numlock issues, so the issue for which this report was opened got solved. (But since it is used for other issues, too, it is maybe better to leave it open and change the summary??) The TP L530, in normal mode, booted till it reached the loop about checking for new hardware. The TP SL510 in normal mode booted to a black or light black screen, I only waited a few minutes and then decided to try again with systemd.unit=multi-user.target it then got as far as checking for new hardware, where it stopped (but again I did not wait for 10 minutes) All those messages about reaching target sound card and the message about restoring it (on all 3 laptops) can't harm?)
(In reply to Marja van Waes from comment #10) > so the issue for which this report was > opened got solved. > > (But since it is used for other issues, too, it is maybe better to leave it > open and change the summary??) Closing, afaik the other issues are solved, too, now
Status: NEW => RESOLVEDResolution: (none) => FIXED