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