| Summary: | 6_s1: plymouth-start.service fails to run first time with "splash" argument removed | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bit Twister <bittwister2> |
| Component: | RPM Packages | Assignee: | All Packagers <pkg-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | doktor5000, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | plymouth-0.9.2-4.mga6.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Bit Twister
2016-01-18 14:25:42 CET
Assigning to all packagers collectively, because plymouth has no maintainer. CC:
(none) =>
marja11 (In reply to Bit Twister from comment #0) > Description of problem: You seem to be missing something meanful here, apart from the status output. What is the actual problem that you encountered, when doing what? Did you see plymout splash when booting, did it hang/block the boot, or anything else happened? Steps to reproduce are also not present ... > # systemctl status plymouth-start CC:
(none) =>
doktor5000 (In reply to Florian Hubold from comment #2) > something meanful here err, something _meaningful_ here :) (In reply to Florian Hubold from comment #2) > (In reply to Bit Twister from comment #0) > > Description of problem: > > You seem to be missing something meanful here, apart from the status output. No, I thought an app attempting to address memory outside of its control was meaning enough. My guess is it needs some other service running before it can start working. > What is the actual problem that you encountered, Problem is application fails to run the first time. > when doing what? Booting. > Did you see plymout splash when booting, No, I want to see what might be failing rather than having to debug what is wrong with something not running. Reverent snippet from from /var/log/dmesg kernel: Command line: BOOT_IMAGE=mga6_64_netinstall root=LABEL=hh noresume noiswmd audit=0 vga=794 > did it hang/block the boot, Yes, until plymouth-start timed out and was restarted. > or anything else happened? Rest of the services completed while plymouth-start was timing out. > Steps to reproduce are also not present ... Sorry, always doing a "reboot", after clearing the logs for the next boot. /local/bin/new_boot_logs code snippet follows: !/bin/bash _cmd=reboot <snipped bunch of files being removed, others being nulled with cp /dev/null and stopping services which can hang shutdown for several minutes. > :( echo "clearing journal log" _log_dir=/var/log/journal/$(cat /etc/machine-id) if [ -e $_log_dir ] ; then echo "Wiping journal logs" systemctl kill --signal=SIGUSR1 systemd-journald.service systemctl kill --signal=SIGUSR2 systemd-journald.service sleep 2 /bin/rm -f $_log_dir/user-*.journal /bin/rm -f $_log_dir/*@* fi echo " Running $_cmd" sleep 1 $_cmd exit
Bit Twister
2016-06-17 04:59:27 CEST
Hardware:
i586 =>
x86_64 (In reply to Florian Hubold from comment #2) > (In reply to Bit Twister from comment #0) > Did you > see plymout splash when booting, did it hang/block the boot, or anything > else happened? Removal of splash argument causes the failure. No, idea why it is able to restart the second time. Summary:
6_s1: plymouth-start.service: Main process exited, code=killed, status=11/SEGV =>
6_s1: plymouth-start.service fails to run first time with "splash" argument removed no longer seeing fail message in journal. Status:
NEW =>
RESOLVED You removed the splash boot argument, and then wonder why bootsplash fails to run? Totally makes sense ... (In reply to Florian Hubold from comment #7) > You removed the splash boot argument, and then wonder why bootsplash fails > to run? > Totally makes sense ... Seems you are a bit behind in your reading since this was resolved about two months ago. Had you bothered to read the bug title and Description the bug is about the Plymouth.Start service failing because of the removed argument. The problem is that the service should not have failed the first time. |