Summary: | sysvinit-2.86-r11 fail to start with openrc-0.4.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | thierry volpiatto <thierry.volpiatto+gentoobug> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
messages_save
/home/thierry/rc.log-2008.12.23-1853 /home/thierry/dmesg-2008.12.23 |
Description
thierry volpiatto
2008-12-22 07:26:19 UTC
Created attachment 176128 [details]
messages_save
The relevant section is in Dec 21.
The supplied log is painfully long. Please include the actual section that describes the issue. Additionally, the openrc 0.4.0 ebuild was masked until after sysvinit-2.86-r12 was released and underwent additional changes during that mask. I would suggest re-emerging openrc-0.4.0 and hopefully that will correct the issues. If it does not, you might have to hand migrate the sysvinit init level based on the contents of the ebuild yourself to repair your system. > The supplied log is painfully long. Please include the actual section that > describes the issue. May be you can use something like ,---- | cat messages | grep "Dec 21" | grep sysvinit `---- > Additionally, the openrc 0.4.0 ebuild was masked until after sysvinit-2.86-r12 > was released and underwent additional changes during that mask. So why openrc-0.4.0 is unmasked ? > I would suggest re-emerging openrc-0.4.0 and hopefully that will correct the issues. If it does > not, you might have to hand migrate the sysvinit init level based on the > contents of the ebuild yourself to repair your system. I just switch back to the precedent versions of openrc and sysvinit waiting a fix of sysvinit. My system is not broken. However if you want i can re-emerge openrc-0.4.0 and sysvinit-2.86-r12 to reproduce the bug and give you more infos. Thierry. (In reply to comment #3) > > > Additionally, the openrc 0.4.0 ebuild was masked until after sysvinit-2.86-r12 > > was released and underwent additional changes during that mask. > > So why openrc-0.4.0 is unmasked ? It was unmasked, as we thought it was ready for larger speading. > > However if you want i can re-emerge openrc-0.4.0 and sysvinit-2.86-r12 > to reproduce the bug and give you more infos. > Please retry with these versions. Else we cannot do anything to solve your issue. If it works then: fine, else, please attach the relevant parts (not full log like last attachment) of your log files. Did you run 'etc-update' after emerging udev/openrc/sysinit combo ? Those three are tied together, maybe you've missed something there. >Did you run 'etc-update' after emerging udev/openrc/sysinit combo ?
Yes i did, i am going to retry right now to see if i can reinstall
these versions.
I have more time now :)
Thierry.
Created attachment 176244 [details]
/home/thierry/rc.log-2008.12.23-1853
Hi, here the rc.log
following dmesg.
System is hanging until timeout finish (60s)
on beginning of boot level at:
,----
| Waiting for uevents to be processed
`----
After that ipw3945 should start but it doesn't.
So i have re-emerged openrc-0.3.0-r1 and sysvinit-2.86-r10.
(to be able to send this)
Created attachment 176245 [details]
/home/thierry/dmesg-2008.12.23
Here the dmesg.
Hi, i have solved the problem with the migration from ipw3945 to iwl3945 and the install of kernel 2.6.27-r7. Now openrc 0.4.1 is installed with last sysvinit and working fine. It seem openrc and/or sysvinit are not friends with ipw3945 drivers. So anyway, iwl3945 solve the problem. Thanks to all. Thierry. I honestly can't see how a specific driver would be related to sysvinit or OpenRC. Basically the error you were seeing was the system waiting on the kernel with regard to uevents. More then likely there was an issue with the old ipw3945 driver and it wasn't delivering the correct uevents. |