# Warning: unable to open an initial console.

## bogdan

I was using arch a while ago and decided i'd change to gentoo. I still wanted to use my computer while everything was compiling so i installed gentoo in a chroot and compiled pretty much everything in there  :Smile: . Now the only problem is that i get "Warning: unable to open an initial console." while booting and nothing shows up on the screen. If i wait a while it loads up everything but it's very annoying not to see what's happening, especially since it is quite slow to boot.

any help would be appreciated  :Smile:  i searched for this problem and i saw you need /dev/console and /dev/null to be present for boot, but they are already there.

----------

## frostschutz

Are they really there? mount the / partition again in /mnt/somewhere and check out /mnt/somewhere/dev

after booting, /dev will be filled by udev, so if the devices are there after booting it means nothing

the static devices are extracted with the stage3 tarball so they should be there... unless you did something strange

other than that, it could be something in your kernel config

----------

## bogdan

yeah, i booted the live cd and extracted the stage3 /dev again and now it's working, so thanks  :Smile: 

and now i see why it's so slow to boot. it keeps doing "Caching service dependencies ..." before every single init script. Do you know what may cause that? i should also note that i'm running ~amd64, so i'm using openrc and baselayout2

----------

## pappy_mcfae

While I know it might get some people upset with me, might I suggest you backpedal and install baselayout-1.12.12. Baselayout-2/openrc is still listed as unstable, and IMHO, for good reason. It is still very much a work in progress. I can only get it to run reliably on my tower. 

The updates in openrc tend to break my networking on my laptop. One day, ndiswrapper works, next day, no dice.  I decided I'd wait until it was closer to right before I try it out again.

Blessed be!

Pappy

----------

## frostschutz

Upgrading is always easy, backpedaling is bound to break tons of stuff. Future version of apps can always made to be backward compatible, but past versions can't be future compatible. Going back means breakage. I'm on ~amd64 as well and have no issues whatsoever with the new baselayout, but then again I don't use ndiswrapper, so ymmv. Unfortunately I haven't seen the 'Caching service dependencies' issue either, so I can't help you fix it. You'll have to find out what condition it is that makes it think it has to rebuild the cache, why this condition is always met, and resolve the problem from there.

----------

## pappy_mcfae

No, it doesn't. I have backpedaled on two of my machines...one of which I am using right now to write this response, and an older Toshiba laptop. 

It's easy to do. It's not like glibc, which goes nuclear if you backpedal. The first machine I removed baselayout-2/openrc as soon as it shut down my wireless networking...which was as soon as I emerged it. Thanks, but no thanks. This system needs to be able to rename the network interface. Baselayout-2 does not support this.

On my other laptop, baselayout-2/openrc survived for a while, until one openrc upgrade came along, and nuked ndiswrapper's ability to connect. The ONLY way I could get ndiswrapper to start properly again was to go back to baselayout-1.12.12 and eliminate openrc. That was about three weeks ago, and the laptop in question is currently recompiling the world after I got rid of the arts USE flag. That would tell me that both systems on which I backpedaled are working now as if baselayout-2/openrc never existed in the first place. Ain't it grand!

Yes, there are things that need to be "fixed" so to speak, but at least once your done doing those fixes, you don't have to get trampled by the NEXT batch of "fixes", and fixes for the "fixes" coming to openrc. Like I said, I'll wait until it becomes stable, and then I might consider emerging it on my laptops.

Ironically, I have never had any trouble with baselayout-2/openrc on my tower. Of course, it doesn't have wireless networking set up, and has a really simple /etc/conf.d/net. Openrc doesn't seem to be able to hurt it.

Blessed be!

Pappy

----------

## bogdan

A init script had a modification time in the future, i don't really get how that happened but now it's ok. Thanks

----------

## frostschutz

 *pappy_mcfae wrote:*   

> No, it doesn't. I have backpedaled on two of my machines...one of which I am using right now to write this response, and an older Toshiba laptop.

 

Well, it always depends where, and how, you backpedal. The original poster said he was on ~amd64, so I understand that he uses the ~arch versions of everything. Backpedaling from there is much harder to do when you, say, just ~keyworded a single package and go back to stable for a single package again. Moving from ~amd64 to amd64 however, as in a global backpedal, is sure to break your system.

Backpedaling baselayout2 alone is already hard to do. When you install baselayout2 it screws you one over with the config files that moved around, and you have to undo those moves as you go back or you end up with invalid config files. Not something I'd recommend for a user who has only a minor problem with it.

 *bogdan wrote:*   

> A init script had a modification time in the future, i don't really get how that happened but now it's ok. Thanks

 

I'd report it as a bug anyway, because it is one. Modification times in the future can happen easily, especially during install when whatever live cd you are using did not get the time right. 'make' relies on timestamps and complains about modification times in the future, openrc should do the same.

----------

## Kotw

 *frostschutz wrote:*   

> other than that, it could be something in your kernel config

 

I've the same problem as him but in my case i'm pretty sure it's a problem in my kernel config.

According to you, what can be the forgotten option resulting the same error message at boot time (with a kernel panick after)

----------

## pappy_mcfae

 *frostschutz wrote:*   

> Backpedaling baselayout2 alone is already hard to do. When you install baselayout2 it screws you one over with the config files that moved around, and you have to undo those moves as you go back or you end up with invalid config files. Not something I'd recommend for a user who has only a minor problem with it.

 

Yes, backpedaling with baselayout-2 took some doing. However, the process of removal was a lot less damaging to my system than the install of baselayout-2/openrc. That left two out of three systems without networking whatsoever. A very dirty trick considering it was placed in portage with nary a warning it would send systems to kingdom come.

I'm sure once the Madagascar Hissing cockroaches in baselayout-2/openrc are killed, then it will rock. Until then, I simply cannot use it with my laptop machines. 

I have yet to have minor problems with baselayout-2/openrc.

Blessed be!

Pappy

----------

## sonicbhoc

I have the initial console problem as well, but I don't think it's a kernel prob... It could be, but whatever it is, it's driving me insane. But I don't want to downgrade - openrc is tons faster than baselayout-1.

----------

## pappy_mcfae

I grant you that, but is the boot speed REALLY that important? Yeah, I wish this machine booted a bit faster, but there's more than baselayout affecting boot time. Besides, I leave my machines most of the time, so what difference does boot time make. It's not like I'm waiting for a Pentium MMX233 with 96 megs of ram. And even if I were, I'd have two other machines up, running, and ready to go.

Like I said, I know baselayout-2 will rock when it's closer to done, but for now, it breaks my laptops, and that's unacceptable. It doesn't seem to bother my tower, so for that machine at least, baselayout-2/openrc works great! Of course, even with baselayout 1.x, a Core2 Duo is going to boot really fast...so I don't know that I've gained anything.

Blessed be!

Pappy

----------

## frostschutz

 *sonicbhoc wrote:*   

> I have the initial console problem as well

 

Same question to you... are you sure you got a proper /dev directory on your root fs, i.e. the standard set of static dev nodes _before_ udev gets started (and thus mounted over /dev, hiding the static nodes)? You can check this by mounting the /dev/root somewhere else (e.g. in /mnt/root) and then check out the contents of /mnt/root/dev/. There should be a ton of device nodes in there, including 'console'.

----------

## sonicbhoc

(oops, didn't notice that someone had replied)

Alright, I'll look.

It seems that I have everything, including console and tty, there. So why does it have a problem opening it?

----------

## frostschutz

No idea. Is your root device actually your root during booting, or are you using an initramfs or initrd? Then it may be missing there.

----------

## sonicbhoc

Yeah, I'm using an initrd for the theme. How do I check and/or fix that?

----------

## frostschutz

Well, the initrd image is an archive of sorts, gzip and cpio I think? (not using initrd so I'm not sure)

Anyway, you have to extract / mount the image and check out its /dev directory and see if the device nodes are by chance missing in there.

----------

