Bug 215213

Summary: no default console device in /dev (when no initrd at all)
Product: [Fedora] Fedora Reporter: Etienne Lorrain <etienne_lorrain>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-20 06:39:19 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Etienne Lorrain 2006-11-12 08:19:55 EST 
Description of problem:
I am usually running without any module (custom config for my PC only) so
have no initrd, but anyway when people do not need to load an inirtd to
boot, the kernel say "cannot open initial console) and now FC6 reboots
automatically (FC5 was just showing the message and stay there
so user could read it).
Here is one message on LKML:
http://marc.theaimsgroup.com/?l=linux-kernel&m=114982415932526&w=2
which gives the solution that I am using right now.

Version-Release number of selected component (if applicable):
FC6

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Phil Knirsch 2007-05-24 11:18:41 EDT 
Problem is that the whole bootup process has been built upon the fact that you
typically use kernels with modules (self made or rpm kernels) and you're using
mkinitrd and initrds together with udev.

There was a description how to diable udev support some time ago, but i can't
find it anymore now.

I'm reassigning this to udev, maybe the package owner still knows where to find it.

So basically if you want to run a system with such drastic changes to the bootup
process such additional manual changes are to be expected imo, and creating a
few 'sporadic' /dev entries just in case isn't a good solution as after a while
we'll end up with a semi-filled /dev again which goes exactly against what we
were trying to achive when going to udev.

Read ya, Phil