Every time I boot plymouth is always killed by SEGV
Every few reboots the system will hang without continuing to boot at this message:
init: udev-fallback-graphics main process (993) terminated with status 1 init: plymouth main process (538) killed by SEGV signal init: plymouth-splash main process (998) terminated with status 2 init: plymouth-log main process (1026) terminated with status 1
Sometimes the system will hang during reboot as well, I think it may be related to `plymouth-stop`, but I don't have strong evidence of that currently.
My kernel config has only very minimal changes from `omap2plus_defconfig`
- enabling devtmpfs and automounting it - disabling omap2, omap4, etc, except omap3 - disabling all boards except for overo
I don't think that plymouth is a particularly necessary service (especially since I don't have a display), so my temporary solution is to disable it like so:
cd /etc/init ls plymouth*.conf | while read CONF do mv ${CONF} ${CONF}.off done
Can anyone offer me any suggestions?
AJ ONeal
After rebooting several times in succession I can confirm that
- the hang at boot-time no longer occurs - the hang at reboot still occurs
However, there is another error which has surfaced
Warning... fsck.ext3 for device /dev/mmcblk0p2 exited with signal 11. mountall: fsck / [721] terminated with status 8 mountall: Unrecoverable fsck error: / mountall: Skipping mounting / since Plymouth is not available
- clean reboots cause the filesystem to be reported as corrupted (I'll start a different thread about this issue on linux-omap and gumstix) - Plymouth's availability reported/y affects `/` being mounted - yet there are no errors on the filesystem and it still mounts (though in read-only mode)fsck -y /dev/mmcblk0p2 fsck from util-linux-ng 2.17.2 e2fsck 1.41.14 (22-Dec-2010) ROOTFS: clean, 26907/131648 files, 209899/526128 blocks
AJ ONeal
On Mon, May 2, 2011 at 3:23 PM, AJ ONeal coolaj86@gmail.com wrote:
Every time I boot plymouth is always killed by SEGV
Every few reboots the system will hang without continuing to boot at this message:
init: udev-fallback-graphics main process (993) terminated with status 1 init: plymouth main process (538) killed by SEGV signal init: plymouth-splash main process (998) terminated with status 2 init: plymouth-log main process (1026) terminated with status 1
Sometimes the system will hang during reboot as well, I think it may be related to `plymouth-stop`, but I don't have strong evidence of that currently.
My kernel config has only very minimal changes from `omap2plus_defconfig`
- enabling devtmpfs and automounting it
- disabling omap2, omap4, etc, except omap3
- disabling all boards except for overo
I don't think that plymouth is a particularly necessary service (especially since I don't have a display), so my temporary solution is to disable it like so:
cd /etc/init ls plymouth*.conf | while read CONF do mv ${CONF} ${CONF}.off done
Can anyone offer me any suggestions?
AJ ONeal
On Mon, May 02, 2011, AJ ONeal wrote:
Warning... fsck.ext3 for device /dev/mmcblk0p2 exited with signal 11.
fsck.ext3 segfaulting is pretty bad
- Plymouth's availability reported/y affects `/` being mounted
That might be normal (see other message)
- yet there are no errors on the filesystem and it still mounts (though
in read-only mode)fsck -y /dev/mmcblk0p2
Well even without errors, something causes fsck to segv when run from mountall apparently; maybe different flags?
On Mon, May 02, 2011, AJ ONeal wrote:
I don't think that plymouth is a particularly necessary service (especially since I don't have a display), so my temporary solution is to disable it like so: cd /etc/init ls plymouth*.conf | while read CONF do mv ${CONF} ${CONF}.off done Can anyone offer me any suggestions?
Plymouth is used a message and user-interaction multiplexer so that new devices and filesystems can appear during boot and be fscked, and the user can be prompted -- asynchronously. It's not just the framebuffer output used to display a splash.
I don't have suggestions for your SEGV; there are debug flags for plymouth which you might be able to use; you could also spawn a terminal at various stages of the boot and try running plymouth yourself or under gdb