Summary: | sys-fs/udev-104-r11: modprobe.sh writes to /dev/console | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jimmy.Jazz |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | spock, wolf31o2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jimmy.Jazz
2007-02-15 09:50:19 UTC
Not baselayout. What messages are you seeing? Do you have CONSOLE=/dev/tty1 properly set? @spock: How to find out in the code if one is allowed to write to /dev/console, or where to write? One possible idea is to check $CONSOLE and use that. But first: at that point of time it is possible that the device node does not exist (udev-start only creates /dev/null and /dev/console) and udev later processes all other stuff. Second: udev clears environment, that means udev-start has to check and write device to some file /dev/.udev_console (or whatever), and modprobe.sh can then check existence and in case write to that. Or udev-start just disables verbose if CONSOLE!=/dev/console. Here are some loose thoughts about the problem: The general idea would be not to write to /dev/console when the silent splash mode is requested (because then /dev/console is the current tty on which the splash image is displayed) and to use $CONSOLE instead. If /dev/tty1 from the root fs is accessible when modprobe.sh is run (which I think it's not -- correct me if I'm wrong here) then if it doesn't exist, we can simply fall back to /dev/console (splash won't start if /dev/tty1 isn't present on the root fs). If it's not accessible, then maybe it could be created in seed_dev() along with /dev/console and /dev/null? Clearing the environment shouldn't be that much of a problem because you can always get the CONSOLE setting from /proc/cmdline (I think). This should be fixed in udev-104-r12. It uses $CONSOLE in modprobe.sh. udev.start additionally creates /dev/tty1 to be able to write before udevd has created it. (In reply to comment #2) > What messages are you seeing? Do you have CONSOLE=/dev/tty1 properly set? > yes, i did deleting the redirection "> /dev/console" in the file works for me. The message then goes to $CONSOLE (i have defined at the kernel cmdline) without other needs. So i don't think it is necessary to force the output to $CONSOLE explicitly. But i can be wrong. The explicit redirection is necessary, as else output would go to /dev/null (where udevd redirects stdin/stdout). |