Many if not all, of suggestions contained in this article could, if misapplied, easily make your system unreachable or ill behaving in many unexpected ways. So, before you start to do changes on some system travelling on next ESA deep space probe or sitting on Mt. Everest top, try them at home on a serial console equipped test system.
Moreover, keep in mind that when everything else fails, you can physically dismount the SD card and edit the offending files off-line.
The first step is meant to get rid of all messages and prompts at the boot.
Edit the following files and carefully make the changes in bold.
sudo nano /boot/cmdline.txt dwc_otg.lpm_enable=0 console=serial1,115200 console=tty3 root=PARTUUID=6b391ee6-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait consoleblank=0 loglevel=3 quiet logo.nologo vt.global_cursor_default=0
sudo nano /boot/config.txt # custom splash disable_splash=1
Next run the following commands that remove the login prompt and Debian native screen saver:
sudo systemctl disable getty@tty1 sudo systemctl mask plymouth-start.service
Next reboot and check: you should see no messages anymore (black screen).
sudo systemctl reboot
Create under /home/pi an images/ directory and copy there the splash screen bitmap:
cd mkdir images cp splash.png images/
Install the fim graphical utility that is able to copy a bitmap into the frame buffer memory area:
sudo apt-get install fim
Create a dedicated service
sudo systemctl edit boot-splashscreen-2.service --force
with the following contents:
[Unit] Description=boot splash screen DefaultDependencies=no # Do not put here any After/Before clauses, just let systemd do its job ! [Service] StandardInput=tty StandardOutput=tty ExecStart=/usr/bin/fim -q -a /home/pi/images/splash.png ExecStartPost=/bin/sleep 3 [Install] WantedBy=sysinit.target
Test the service
sudo systemctl start boot-splashscreen-2.service
enable the service
sudo systemctl enable boot-splashscreen-2.service
reboot to check everything is as expected:
sudo systemctl reboot
What is expected is a full black screen at the start, after few seconds the splash screen is shown. If you didn't configre any other grapphical application, it will stay there till the next reboot/halt.
Using the following command we can verify that the boot splash panel has been started just whene we want.
pi@cm3panel:~ $ sudo systemd-analyze critical-chain
The boot splash is shown in red (bold mine), just after local-fs.target and well before the achievement of sysinit, as per its service file.
graphical.target @13.296s └─multi-user.target @13.295s └─ssh.service @13.046s +248ms └─network.target @13.039s └─dhcpcd.service @4.928s +8.109s └─basic.target @4.921s └─sockets.target @4.921s └─triggerhappy.socket @4.921s └─sysinit.target @4.920s └─systemd-timesyncd.service @4.678s +242ms └─systemd-tmpfiles-setup.service @4.649s +23ms └─boot-splashscreen-2.service @1.630s +3.015s └─local-fs.target @1.616s └─boot.mount @1.601s +14ms └─systemd-fsck@dev-disk-by\x2dpartuuid-6b391ee6\x2d01.service @1.322s +274ms └─dev-disk-by\x2dpartuuid-6b391ee6\x2d01.device @1.294s
In case you need a very short boot time (e.g. if you are using the CM3-Panel as an appliance controller), the following suggestions could help
In the current Raspbian lite images, the dhcpcd.service has a so-called drop-in file, i.e. a file that is changing the package prrovided systemd .service file. Specifically, the option -w is getting added: it causes the process dhcpcd to wait till all the interfaces achieve an IP address.
$ sudo systemctl cat dhcpcd.service # /lib/systemd/system/dhcpcd.service [Unit] Description=dhcpcd on all interfaces Wants=network.target Before=network.target [Service] Type=forking PIDFile=/run/dhcpcd.pid ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -b ExecStop=/sbin/dhcpcd -x [Install] WantedBy=multi-user.target Alias=dhcpcd5.service # /etc/systemd/system/dhcpcd.service.d/wait.conf [Service] ExecStart= ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w
Removing that option the service is able to start in less than one second instead of 12. Of course, that could even trigger anomalous behavior, so it is advisable to use this configuration only on systems where the network services are not critical to the appliance working.
2018 Ⓒ TanzoLab