| Summary: | sys-fs/lvm2: dmeventd fails to start in early boot runlevel with lvm due to read-only /var/run | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Xake <kanelxake> |
| Component: | [OLD] baselayout | Assignee: | Robin Johnson <robbat2> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | agk, base-system, cardoe, roy, xmw |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Xake
2010-06-06 10:33:24 UTC
@ sys-apps/openrc Maintainers: I've added you because i think you see this on a greater scale, since something's missing a writeable /var/run. A tmpfs over there might help. some services keep the fd open with /var/run files. not many, but it is certainly more than zero. perhaps with those we simply say "dont do it" though. Upstream, we decided not to use dmeventd until after everything else has been initialised, on the grounds that if something that dmeventd would handle fails at such an early stage of booting, you're likely to have serious problems that need manual intervention anyway. vg/lvchange --sysinit skips stuff like that, then a later 'lvchange --monitor y --poll y ' starts it up. Ok, this will be going into 2.02.67-r1, moving all of dmeventd to AFTER lvm/device-mapper. Also uses --sysinit now for new early start/stop stuff. 2.02.67-r1 in CVS. |