Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: michnixweiss on February 01, 2022, 06:06:20 PM
-
Im on RPI Zero W with piCore 13.1.0 kernel 5.10.77
How can I reduce boottime?
Is there something like
systemd-analyze blameFrom raspian?
-
Hi michnixweiss
A couple of ideas come to mind.
Go through your onboot.lst file and remove any entries you don't currently need, for example, compiletc, bc,
squashfs-tools, any extension ending in -dev. You don't need to physically delete or uninstall the extensions.
If your backup file is large, that will slow things down.
If you have a lot of stuff in your /home or /opt directories, consider making them persistent:
http://forum.tinycorelinux.net/index.php/topic,25432.msg162862.html#msg162862
If you are backing up stuff under /usr or /etc, don't backup entire directories if you only need a few files.
You can also see where the system is spending its time. Add the following boot codes:
printk.time=1 syslogThen reboot the system and:
Check the timestamps in dmesg for large gaps:
dmesg | lessDo the same for messages:
less /var/log/messagesIf it exists, do the same for messages.0:
less /var/log/messages.0
-
I switched the not always needed tcz from onboot to ondemand, which safes me about 14sec
The big entrys of dmesg
[ 27.863825] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 28.057639] bcm2835_audio bcm2835_audio: there is not valid maps for state default
[ 28.534840] snd_soc_wm8960_soundcard: loading out-of-tree module taints kernel.
[ 28.553075] Error: Driver 'asoc-simple-card' is already registered, aborting...
[ 28.554973] Error: Driver 'asoc-simple-card' is already registered, aborting...
[ 29.083949] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 29.393462] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 29.393727] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 29.393750] cfg80211: failed to load regulatory.db
[ 29.518231] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 29.559919] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 29.566067] usbcore: registered new interface driver brcmfmac
[ 29.877183] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 29.877383] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 29.877508] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 29.878649] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd
[ 30.134113] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 102.615146] random: crng init done
looks similar in messages
Jan 1 00:00:27 box user.warn kernel: [ 27.863825] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
Jan 1 00:00:27 box daemon.info init: starting pid 1508, tty '/dev/tty1': '/sbin/getty -nl /sbin/autologin 38400 tty1'
Jan 1 00:00:28 box user.info kernel: [ 28.057639] bcm2835_audio bcm2835_audio: there is not valid maps for state default
Jan 1 00:00:28 box auth.info login[1508]: root login on 'tty1'
Jan 1 00:00:28 box user.warn kernel: [ 28.534840] snd_soc_wm8960_soundcard: loading out-of-tree module taints kernel.
Jan 1 00:00:28 box local2.notice sudo: tc : TTY=unknown ; PWD=/home/tc ; USER=root ; COMMAND=/usr/bin/tee /etc/sysconfig/backup
Jan 1 00:00:28 box user.err kernel: [ 28.553075] Error: Driver 'asoc-simple-card' is already registered, aborting...
Jan 1 00:00:28 box user.err kernel: [ 28.554973] Error: Driver 'asoc-simple-card' is already registered, aborting...
Jan 1 00:00:29 box user.notice kernel: [ 29.083949] cfg80211: Loading compiled-in X.509 certificates for regulatory database
Jan 1 00:00:29 box user.notice kernel: [ 29.393462] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
Jan 1 00:00:29 box user.warn kernel: [ 29.393727] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Jan 1 00:00:29 box user.info kernel: [ 29.393750] cfg80211: failed to load regulatory.db
Jan 1 00:00:29 box user.debug kernel: [ 29.518231] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
Jan 1 00:00:29 box user.info kernel: [ 29.559919] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
Jan 1 00:00:29 box user.info kernel: [ 29.566067] usbcore: registered new interface driver brcmfmac
Jan 1 00:00:29 box user.info kernel: [ 29.877183] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
Jan 1 00:00:29 box user.info kernel: [ 29.877383] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
Jan 1 00:00:29 box user.info kernel: [ 29.877508] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited chan>
Jan 1 00:00:29 box user.info kernel: [ 29.878649] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.>
Jan 1 00:00:30 box user.info kernel: [ 30.134113] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Jan 1 00:01:42 box user.notice kernel: [ 102.615146] random: crng init done
Jan 1 00:01:42 box auth.info sshd[1994]: Server listening on 0.0.0.0 port 22.
messages.0 does not exist
What does crng init (so long)?
-
Hi michnixweiss
... The big entrys of dmesg ...
Those numbers indicate a point in time for that line, not how long that line took to execute.
... What does crng init (so long)?
That message refers to the random number generator. It uses various sources from the hardware to attempt to
derive a random seed to use as a starting point. I think one of those sources may be the RTC. If you are using the
nortc boot code, that may be contributing to that delay.
Does your Pi actually take 102 seconds before it is responsive?
Execute these 2 commands:
dmesg > dmesg.txtcp /var/log/messages messages.txtAttach those 2 files to your next post.
-
Because the rpi zero does not have devices that generate entropy very fast. The RPI processor does have hardware entropy capabilities, but that requires another extension and a process to be started (rngd.tcz)
That has nothing to do with boot time though. (At least not once your ssh keys are generated on the first boot)
piCore has a better tracking what the extensions are costing you during boot.
~$ cat /tmp/bootlog.txt
0.0 - Build TCZ list
4.4 - Mount TCZ (47)
0.3 - Add to file system
2.0 - Execute startup scripts
0.0 - udev trigger
~$
-
I added a soundtest in the script to restore asound.state from alsa. The sound is playing after about 35sec. But ssh is not reachable befor about 100sec. Until now I thought, that this is because it's headless and used only over WLAN...!?
cat /tmp/bootlog.txt
0.0 - Build TCZ list
2.7 - Mount TCZ (40)
4.0 - Add to file system
10.3 - Execute startup scripts
0.2 - udev trigger
the two files are attached.
-
Hi michnixweiss
... But ssh is not reachable befor about 100sec. ...
I'm guessing maybe you skipped this step:
After the first run
===================
Execute 'filetool.sh -b' shell command after the first boot to save
generated unique SSH keys which will be used during next boots. It will
speed up boot and eliminate to bother new keys in SSH client.
Found here:
http://tinycorelinux.net/www/12.x/armv6/releases/RPi/README
-
Hi Paul_123
... The RPI processor does have hardware entropy capabilities, but that requires another extension and a process to be started (rngd.tcz) ...
Did you mean (rngd which is provided by rng-tools.tcz) ?
-
You are correct Rich.
Openssh should only care about random entropy during key generation. Once keys are saved, and backed up, the it should not care, but adding rng-tools will help, just make sure to start rngd early in your bootlocal.sh
-
I'm guessing maybe you skipped this step:
I don't think so. But if I missed it ssh (putty in my case) would ask at every connect to accept the new keys!?
Anyway, generated keys should be stored at any point if I run filetool.sh -b or only after first boot?
My filetool.lst
#Cannot post, file attached
I noticed that there are no entrys for the config
Open
/opt/.filetool.lst
Add
#Cannot post this too
Installed rng-tools.tcz and added
/usr/local/sbin/rngd -b
But if rng only is used when keys are generated, this should be irrelevant if the setup is corret!?
-
Adding rng makes ssh ready much faster. Now I can connect after about 37sec.
And there is no crng entry in dmesg anymore.
So are my keys generated at every boot or something else using rng at startup or crng just hangs cause of missing devices?
-
Perhaps the newest OpenSSL requires it now. I load rngd by default, so I would not notice.
-
Hi michnixweiss
I noticed this in your filetool.lst file:
lib/modules/5.10.77-piCore/build #no folder, only lnAre you sure it's OK to place comments in that file?
-
Are you sure it's OK to place comments in that file?
The comment is not present in the file.
The goal was to avoid a discussion about backing up huge folders blah...
Not successful :'(
-
Perhaps the newest OpenSSL requires it now. I load rngd by default, so I would not notice.
So I leave rngd just as it is now.
Is there anything else I can do to reduce boottime or are the 37sec related to the hardware limitations of the RPi Zero?
-
I’m not sure you have shown us your onboot.lst. 40 extensions seems like a lot for WiFi ssh and sound.
-
onboot.lst attached
-
So you have extra extensions loaded that are only needed for development.
i2c-tools
p_ython3.8-pip
nano
Not sure what is in your startUp extension
The tcz startup scripts taking 10seconds to run seems quite long.
-
Hi @Paul_123,
I switched i2c-tools to ondemand, without change. I temporarely removed all python from the onboot.lst but I'm still at
cat /tmp/bootlog.txt
0.0 - Build TCZ list
2.3 - Mount TCZ (35)
2.6 - Add to file system
10.2 - Execute startup scripts
0.1 - udev trigger
My startUp extension is/was a test for the easiest way to autostart things. I want to save me the need for an entry in bootlocal.sh
I think using the tce.installed folder will be the easier way...
But for boottime it doesn't matter from where things are startet.
So onboot.lst is now
firmware-rpi-wifi.tcz
wifi.tcz
openssh.tcz
nano.tcz
onoffshim-1.2.tcz
wm8960min_5.10.77-piCore.tcz
alsa.tcz
alsa-utils.tcz
alsa-plugins.tcz
rng-tools.tcz
bootsync.sh (without comments) is not changed
/usr/bin/sethostname box
/opt/bootlocal.sh &
bootlocal.sh is this
cannot post this - attached file
-
The problem is that using a tce.installed script is a blocking activity. It is best to put your startup activities in bootlocal.sh. And run them in the background if possible.
-
The problem is that using a tce.installed script is a blocking activity. It is best to put your startup activities in bootlocal.sh. And run them in the background if possible.
Ok, get it.
How can I figure out what is causing the 10sec?
-
If I have to guess, it’s ca-certificates. Look in /usr/local/tce.installed. The scripts are there, if there is no script, tce-load just creates a zero length file so the system knows it’s loaded.
-
/usr/local/tce.installed/ca-certificates
cannot post the script, file attached
But what shall I do with it to fasten it up? ca-cerfificates extension is required by openssh, python, wifi, etc
I could include the files to the filetool.lst and remove the script from the extension if that helps!?
Otherwise there are only scripts from wifi and file. The rest in tce.installed are zerofiles.
-
Not much.
-
Hi michnixweiss
Try this:
Remove the startup script from ca-certificates.tcz and save it to /opt.
Then make sure it's executable:
sudo chmod 775 /opt/ca-certificates
Place the following in bootlocal.sh:
cp -f /opt/ca-certificates /usr/local/tce.installed
/usr/local/tce.installed/ca-certificates &
-
First of all many thanks! Now I'm at
cat /tmp/bootlog.txt
0.0 - Build TCZ list
2.3 - Mount TCZ (34)
2.5 - Add to file system
3.8 - Execute startup scripts
0.1 - udev trigger
And ssh is reachable after about 28sec.
One question to the "trick": why copy ca-certification back to tce.installed before run it?
Is there anything else I can optimize to reduce boot time?
-
I decided to make a bootlocal dir for extensions
As an example the ca-certification.tcz:
- in squashfs-root -
mv usr/local/tce.installed/ca-certificates usr/local/tce.installed/ca-certificates.sh
mv usr/local/tce.installed usr/local/bootlocal
Then added to my /opt/bootlocal.sh
cannot post - attached fileDoes the job, I can use it for my own extensions and have a small log for them ;D
-
Hi michnixweiss
... One question to the "trick": why copy ca-certification back to tce.installed before run it? ...
Simple, I didn't think that one through. You could just execute it from /opt/.
-
So if there is no more possiblity to reduce boot time this can be set to solved.
Thanks @Rich and @Paul_123
-
Hi michnixweiss
Then solved it is.