1 |
Daniel Pielmeier schrieb am 23.02.19 um 16:37: |
2 |
> Daniel Pielmeier schrieb am 23.02.19 um 16:25: |
3 |
>> Holger Hoffstätte schrieb am 23.02.19 um 15:15: |
4 |
>>> |
5 |
>>> Last night openrc was updated to ~0.41, supposedly fixing [1]. |
6 |
>>> |
7 |
>>> Unfortunately it seems it had the opposite effect and made things worse |
8 |
>>> compared to the previous 0.42.3 - the deptree is broken, rc-status |
9 |
>>> remains confused and a reboot results in a read-only root fs because |
10 |
>>> (I think) the runlevels are all mixed up, esp. /etc/runlevels/boot. |
11 |
>>> |
12 |
>>> Restoring /etc/runlevels from backup & downgrade to 0.40.3 fixed it. |
13 |
>>> |
14 |
>>> If someone can reproduce this in a VM (I cannot do so right now) please |
15 |
>>> file a bug with more information. |
16 |
>>> |
17 |
>>> hth, |
18 |
>>> Holger |
19 |
>>> |
20 |
>>> [1] https://bugs.gentoo.org/659906 |
21 |
>>> |
22 |
>>> |
23 |
>>> |
24 |
>> |
25 |
>> Same here! However I am still on sys-apps/openrc-0.38.3-r1. I think the |
26 |
>> culprit is sys-fs/udev-init-scripts-33 which got an upgrade from version |
27 |
>> 32 on the day before this started happening! |
28 |
>> |
29 |
> |
30 |
> What's to add is that restarting from the semi booted state always |
31 |
> resulted in the same partial boot with the rootfs mounted read-only. |
32 |
> After fixing this by manually starting all services everything was fine |
33 |
> after the next boot. Today when booting again the same happened. I am |
34 |
> writing this now from the manually started system. I will try restarting |
35 |
> over and check if I can reproduce this issue reliable. |
36 |
> |
37 |
|
38 |
Rebooting a few times always resulted in a failed boot! Maybe the other |
39 |
time I was just lucky. Downgrading to sys-fs/udev-init-scripts-32 seems |
40 |
to fix the issue. I opened bug 678638 [1] about this issue. |
41 |
|
42 |
[1] https://bugs.gentoo.org/678638 |
43 |
|
44 |
-- |
45 |
Regards |
46 |
Daniel |