| Summary: | in runlevel 3, numlock auto-enables itself on laptop without numpad | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marja Van Waes <marja11> |
| Component: | RPM Packages | Assignee: | Thomas Backlund <tmb> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, mageia, mageia, sysadmin-bugs, thierry.vignaud, tmb, wilcal.int |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1043212 | ||
| Whiteboard: | 4RC | ||
| Source RPM: | drakxtools-backend | CVE: | |
| Status comment: | |||
|
Description
Marja Van Waes
2014-01-12 21:27:54 CET
Thierry Vignaud
2014-01-12 21:30:08 CET
CC:
(none) =>
mageia btw, this means that, when typing "live", I get "35ve" and instead of "su" I get "s4" etc,
Marja Van Waes
2014-01-12 22:18:46 CET
CC:
(none) =>
davidwhodgins 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, tmb 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) =>
mageia 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)
William Kenney
2014-01-13 13:50:46 CET
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 =>
RESOLVED |