The new location for init.d state information is located on /var now. However, for systems with seperate /var partitions, this causes init to die. This is because it tries to perform operations on this information *prior* to mounting the local filesystems contained in fstab. The solution would be to mount all local filesystems before attempting to modify state information.
i'm pretty sure that mounting of disks is part of an init.d script and as such, we'd need init.d to be accessible ... so how about this solution: create /mnt/.init.d or /.init.d temporarily, run all the init.d scripts until /var/run/init.d is accessible, and then mount /var/run/init.d as tmpfs ... finally we move everything from /.init.d to /var/run/init.d and umount /.init.d ...
It is because you did not update all ._cfg* files. Attach your /etc/inittab.
Actually I did update everything using etc-config
Created attachment 7069 [details] inittab
Any chance for a log of the startup, fstab, etc please ? (btw, to get it working, you should be able to pass 'gentoo=tmpfs' as kernel option). Log of failure of course ... Thanks.
Created attachment 7089 [details] fstab Ok, here's my fstab, I'll post the error log shortly...
Created attachment 7093 [details] startup.log Here is the best I could do in terms of capturing the errors. I added gentoo=tmpfs to my grub.conf, so what you see is with that enabled. As you can clearly see, mounting of local filesystems happens quite a bit later on.
Nicholas, forgot to tell you .. take out the gentoo=tmpfs, I didnt really fix that part yet, as it will still try to mount a missing dir ...
It took me 2 hrs to get my laptop back to work after emerging the new baselayout, now i'm using 1.8.5.8. again... Just to let you know and prove that emerging this new baselayout will cause some trouble. PS: Beside some other things I've found that after emerging the new one i had sofscripts.new and softlevel in my root-dir (i guess they should be in /var/state/init.d instead). HTH
1) I *did* post a mail that said if you are not interested to maybe experience some difficulty, and know how to fix things, DO NOT MERGE THIS. Its also packaged masked .... 2) I cannot resolve things if you do not try to help in tracking the problem. Nicholas, Ill try to get to fixing the gentoo=tmpfs thing tonight, and get that commited. With the other fixes you tested for me the other day, we should have something much more stable, thanks.
Nicholas, can you give 1.8.6.2 a test run ?
from the tests that I, personally, have done, and the group of 17 volunteers when this was first put into masked portage, it seems to do quite well, provided all the files are updated in /etc. In the -r12 of portage, however, that itself seems to be a possible issue...
works for me
This one is fixed, closing it out.
