| View previous topic :: View next topic |
| Author |
Message |
Tender
Apprentice
Joined: 05 Nov 2005
Posts: 166
|
 Posted: Sat Oct 12, 2019 12:00 am Post subject: Stopped at Setting up tmpfiles.d entries for /dev [solved] |
 |
|
Hello,
please someone can help me to correct a strange behaviour of one of my gentoo systems, started after the last update
After powering it on, or after a standard reboot or a kexec reboot the boot stops at:
| Code: | | * Setting up tmpfiles.d entries for /dev [OK] |
If I press the keyboard space bar two times or some other keys boot resumes and ends without issues.
forcefsck already done
Thanks
Last edited by Tender on Sat Oct 12, 2019 11:23 pm; edited 1 time in total |
|
| Back to top |
|
 |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Oct 12, 2019 9:41 am Post subject: |
|
|
all i could say is sometimes, the culprit is not the one who seems to be, so first thing i would do, is looking at who is run after the output message you gave
if you still think culprit is the one that output this, then you should dig up trouble from /etc/init.d/opentmpfiles-dev (or systemd, but no idea about how systemd works) |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sat Oct 12, 2019 4:05 pm Post subject: |
|
|
| Since you got the [OK], I would expect that step is done and the next one is the culprit. Does it always hang for as long as there is no keyboard activity? Does it always recover quickly once you start pressing keys? If you press keys before it reaches that hang point, does it move past the hang? My first thought on seeing a report of "boot hangs, but pressing keys helps" is always to blame something blocking for randomness, while the system has insufficient entropy to satisfy the request. Pressing keys generates entropy, which satisfies the request and allows the system to continue. Adding an automated source of randomness, such as haveged or rdrand, can often fix this. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Oct 12, 2019 4:23 pm Post subject: |
|
|
| Hu wrote: | | Pressing keys generates entropy |
If i remember well, users affected also generate it with mouse moves, a good way to test it rather than keyboard so (if moving mouse do generate entropy) |
|
| Back to top |
|
|
Tender
Apprentice
Joined: 05 Nov 2005
Posts: 166
|
| Posted: Sat Oct 12, 2019 11:23 pm Post subject: |
|
|
Thank you everybody,
this is the first available log from rc.log
| Code: |
rc sysinit logging started at Wed Mar 20 22:40:57 2019
OpenRC 0.38.3 is starting up Gentoo Linux (x86_64)
Press I to enter interactive boot mode
* /proc is already mounted
* Mounting /run ...
* /run/openrc: creating directory
* /run/lock: creating directory
* /run/lock: correcting owner
* Caching service dependencies ...
[ ok ]
* Mounting security filesystem ...
[ ok ]
* Mounting debug filesystem ...
[ ok ]
* Mounting config filesystem ...
[ ok ]
* Mounting fuse control filesystem ...
[ ok ]
* Mounting SELinux filesystem ...
[ ok ]
* Mounting persistent storage (pstore) filesystem ...
[ ok ]
* Mounting efivarfs filesystem ...
[ ok ]
* Mounting cgroup filesystem ...
[ ok ]
* Remounting devtmpfs on /dev ...
[ ok ]
* Mounting /dev/mqueue ...
[ ok ]
* Mounting /dev/shm ...
[ ok ]
* Creating list of required static device nodes for the current kernel ...
[ ok ]
* Setting up tmpfiles.d entries for /dev ...
[ ok ]
* Starting sshd ...
[ ok ]
* Starting udev ...
[ ok ]
* Generating a rule to create a /dev/root symlink ...
[ ok ]
* Populating /dev with existing devices through uevents ...
[ ok ]
rc sysinit logging stopped at Wed Mar 20 22:40:57 2019
|
This is just to say that the boot sequence has never changed and that this problem only occurred recently.
And to say that sshd runlevel was set to both default and sysinit, who knows for how long !!!!!!!!!!!!!!
(it never happened to me to set a sysinit service consciously for whatever reason, openssh in particular, but this is it)
Obviously the problem was solved by removing sshd from the sysinit runlevel.
Now I've also added haveged to the boot sequence and the question now is:
which runlevel is the best to insert it? default, boot or sysinit?
(I'm not kidding)
Thanks |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Oct 13, 2019 12:01 pm Post subject: |
|
|
If it help 
| Code: | rc-status
Runlevel: default
dbus [ started ]
netmount [ started ]
xdm [ started ]
sshd [ started ]
acpid [ started ]
ifserverup [ stopped ]
local [ started ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
rpc.pipefs [ started ]
xdm-setup [ started ]
dhcpcd [ started ]
rpcbind [ started ]
rpc.statd [ started ]
rpc.idmapd [ started ]
nfsclient [ started ]
Dynamic Runlevel: manual
|
|
|
| Back to top |
|
|
Tender
Apprentice
Joined: 05 Nov 2005
Posts: 166
|
| Posted: Sun Oct 13, 2019 1:40 pm Post subject: |
|
|
@krinn
Sorry, I did not specify the subject of the question, I reformulate it
In which runlevel is the best to insert haveged? default, boot or sysinit? |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Oct 13, 2019 5:17 pm Post subject: |
|
|
Answer is pretty simple, if you don't know then it's always default
if your script need to use someone, openrc will start the "someone" if it's not yet start, as such, the more you wait to start it, the more other services are ready up when it try to start it
i just consider sysinit as mostly not for user
and boot runlevel is one that could set hell if you start messing with it, but a useful one for user if he knows what he is doing and if the script really need earlier start. Actually i think adding something that shouldn't be in boot runlevel is major cause of troubles for users |
|
| Back to top |
|
|
|
Other Things Gentoo
