Démarrage du OS le plus rapide possible

Salut, je cherche à gagner du temps dans le boot d’un RPi1. C’est toujours sur le sujet de mon projet de Dashcam.

J’ai monter le code sous Raspbian Lite, mon code sont des « Bash Scripts » en grande partie. J’utilise « Raspivid » (interne) et « Raspidmx » (externe). Avec Raspbian OS j’obtient un démarrage dans les 45 secs ~ 1m 30s (selon le temps requis pour fscheck la carte SD). Avec DietPi j’ai un boot en 30s en moyenne mais plus long (2m) si je ne suis pas en réseau. Et c’est là le problème, il n’est pas sur réseau le 95% du temps.

J’ai été capable de réduire le temps de 2mins à un 45s~60s avec le DietPi en désactivant le « NMBD » et déplaçant mes scripts de démarrage après le « udev.target » au lieu de « network.target » (After=…).

Alors, est-ce que vous connaissez un OS ou un moyen de faire gagner du temps en démarrage ?

Si vous vous demandez pourquoi c’est important; c’est pour une Dashcam, un démarrage rapide est préférable car une voiture, une foi assis tu peux partir rapidement, et pas sur que je vais attendre le démarrage de ma caméra avant de bouger. Mais le réseau est requis pour « vider » la dashcam rapidement. (réalisable en USB, mais c’est looooooooong)

Salut @levelKro

Ton Rpi1 est-il doté d’un module RTC ?
Cela pourrait peut-être lui permettre d’accélérer le démarrage en supprimant des recherches d’info d’horodatage.
Bon, j’avoue … J’en doute … Mais comme je ne crains pas de dire des bêtises (on saura me reprendre), je partage ici ma pensée :wink:

++

Le module RTC est commandé, je l’attend, j’ai besoin de la date fix justement, sinon mes noms de fichiers ce dédouble.

hello,

Il y a des solutions vidéos sur des contrôleurs genre ESP32-CAM qui doivent être plus rapidement opérationnel et avec un enregistrement sur sd (4Go)

si tu veux le faire sur un rpi 1 et si DietPi fonctionne avec systemd, un sudo systemctl list-units|grep "loaded active"|less te listera les services activés et dont certain ne te sont pas utile.(dhcp ? ça expliquerait peut être le temps de démarrage hors réseau )

LA solution royale se serait de te faire un OS perso comme on peut le faire avec LFS mais je ne sais pas si ça peut se faire sur ARM ou peut être avec archlinux ( https://archlinuxarm.org/ )

Pour l’idée de me démarrer un OS, ce n’est pas mauvais, mais je part de trop loin pour arriver à un produit fiable, mes connaissance Linux reste limité.

Le long process réseau a été coupé en partie; j’utilise Samba, et en désactivant du boot le NetBIOS (nmbd.service), le process ne stop pas aussi longtemps. Mais ceci amène vers une autre idée… détecter le réseau.

Le processus de camera démarre auto, même si je me connect à la maison, mais je me dit que si j’ajoute un script dans le boot qui détect la présence du cable Ethernet, et que seulement dans ce cas il active les services réseaux (et stop la camera). Faudrait un « dual boot mode » genre…

Les process de démarrage sont pas mal limite; udev (bien sur), networking, SMBD, … c’est tout. Mais le RPI1 ce n’est pas une bête, alors est-il possible de baisser sous les 30-45s le démarrage ? Je crois le mieux réaliste est dans les 20s.

ArchLinux, si je me fit au fichier, est plus gros que DietPi; 487Mo le ArchLinux, 153Mo DIetPi. Et c’est un environnement basé CentOs/RedHAT, je ne sais pas si la camera Pi va aimer…

HéHé, je suis fière de mon coup :stuck_out_tongue:

Il faut dire que c’est une première pour moi; ajouter des boutons sur le RPi1, 4 en tout depuis un interface recyclé

5 Pins GND (pin 14) + GPIO #17 (B), #27 (C), #22 (D), #23 (A)

Et voici ce qu’ils font;

  1. A : Active/Désactive la caméra (record et preview) : Autostart par défaut
  2. B : Lance le mode « Copy to USB » : J’ai désactivé mon service pour détecter la clé USB et le lancer, j’ai changer mon code pour stopper la caméra le temps de la copie; plus rapide
  3. C : Ajoute un document avec la date/heure pour notifier qui il a un moment important à ce « timestamp » là.
  4. D : Fermeture propre (poweroff)

La c’est le script Python qui ce lance au démarrage pour utiliser les boutons. La réaction est rapide et j’ai penser ajoute des variable pour éviter les multiples détections, vu que la détection est un « while ».

Pour info, mon code

from gpiozero import Button
from signal import pause
import os, datetime, time
from datetime import datetime as dt

buttonA = Button(23)
buttonApressed = False
buttonB = Button(17)
buttonBpressed = False
buttonC = Button(27)
buttonCpressed = False
buttonD = Button(22)
buttonDpressed = False

while True:
    if buttonA.is_pressed and buttonApressed is not True:
        buttonApressed = True
        print("Button A is pressed")
        stat = os.system('service camera status')
        if stat == 0:
            os.system("systemctl stop camera &")
        else:
            os.system("systemctl start camera &")
    elif buttonA.is_pressed:
        pass
    else:
        buttonApressed = False
        
    if buttonB.is_pressed and buttonBpressed is not True:
        buttonBpressed = True
        print("Button B is pressed")
        os.system("/root/pidashcam/runcopy.sh &")
    elif buttonB.is_pressed:
        pass
    else:
        buttonBpressed = False
        
    if buttonC.is_pressed and buttonCpressed is not True:
        buttonCpressed = True
        print("Button C is pressed")
        now=dt.now().strftime("%m-%d-%y_%H-%M")
        os.system("touch /root/pidashcam/saves/important_"+now+".txt")
    elif buttonC.is_pressed:
        pass
    else:
        buttonCpressed = False
        
    if buttonD.is_pressed and buttonDpressed is not True:
        buttonDpressed = True
        print("Button D is pressed")
        os.system("poweroff")
    elif buttonD.is_pressed:
        pass
    else:
        buttonDpressed = False

Et l’interface;

J’ai pas encore songé à son boitier final pour les boutons, j’attend de toute façon mon RTC et je vais devoir faire de ajustement pour que tout entre. Je suis encore a régler des problème au niveau caméra de recul (rien à voir avec le Pi) et du filage. Je dois alimenter 3 appareils et rendre le tout dans un minimum d’apparance (cacher les fils);

  • Caméra de recul : 12V
  • Raspberry Pi (piCam : Caméra avant) : USB 5V
  • Écran TFT : 9~36V

J’ai choisi mon RPi 1 à cause ;

  • Il est incompatible avec mes écrans LCD (sauf le 5" via HDMI)
  • Il est aussi performant que le RPi0WH que je voulais utiliser à la base
  • Il n’as pas de Wifi ou Bluetooth inutilisé, vu qu’il en as pas (usage optimisé du hardware)
  • Il est vieux et si il est « brisé » dans le projet, et bien pas grave, il a 10 ans quand même
  • Surtout: Il a une sortie RCA, compatible avec mon écran déjà en place.

Si j’aurais utilisé un RPi0;

  • Un Wifi et Bluetooth inutilisé
  • Pas de boitier propre sous la main
  • J’ai déjà trop d’accessoires pour lui, que le dédié à une Dashcam me ferait perdre des investissements
  • L’ajout de la sortie TV OUT (avec soudure et config qui en découle) pour la sortie en vidéo

Pour aider, j’ai inclus mes code de décodage pour le RPi (utilisais Kodi avant)

J’ai réussi a amener le Boot à moins de 15 secondes. Avec les boutons, je me suis créé un « mode maintenance », en fait, j’ai désactivé les services; ssh, networking, smbd et nmbd (qui sont pour le partage et l’accès distant) et en plus de fermer le service de la caméra.

Je vais me créer surement un boite de contrôle, avec les boutons; Poweroff, Maintenance mode, Copy mode, et un plus gros facilement accessible, pour enregistrer le « tag » (signet).

Bon vu un problème (autre post) je suis revenu a Raspbian. Je poste une réponse car je tient a ajouter un information pour aider a analyser justement el temps de démarrage.

La version courte, soit le total du temps; systemd-analyze

pi@PICAM:~ $ systemd-analyze
Startup finished in 5.821s (kernel) + 24.824s (userspace) = 30.646s
graphical.target reached after 24.118s in userspace

Mais pour savoir les détails; systemd-analyze blame

pi@PICAM:~ $ systemd-analyze blame
          9.334s dev-mmcblk0p2.device
          7.373s dhcpcd.service
          4.029s systemd-udev-trigger.service
          3.904s keyboard-setup.service
          3.788s smbd.service
          3.710s systemd-rfkill.service
          2.983s dphys-swapfile.service
          2.608s systemd-fsck@dev-disk-by\x2dpartuuid-72aa17b3\x2d01.service
          2.433s systemd-fsck-root.service
          2.403s systemd-journald.service
          2.223s raspi-config.service
          2.048s rc-local.service
          2.015s rng-tools.service
          2.007s rpi-eeprom-update.service
          1.956s systemd-user-sessions.service
          1.941s systemd-timesyncd.service
          1.893s systemd-logind.service
          1.481s nmbd.service
          1.335s kmod-static-nodes.service
          1.333s rsyslog.service
          1.294s user@1000.service
          1.231s run-rpc_pipefs.mount
          1.227s systemd-remount-fs.service
          1.220s systemd-modules-load.service
           954ms networking.service
           879ms systemd-sysctl.service
           831ms sys-kernel-debug.mount
           743ms systemd-tmpfiles-setup.service
           639ms systemd-update-utmp.service
           633ms systemd-sysusers.service
           628ms systemd-journal-flush.service
           556ms systemd-update-utmp-runlevel.service
           548ms ssh.service
           481ms systemd-random-seed.service
           452ms dev-mqueue.mount
           379ms systemd-udevd.service
           301ms user-runtime-dir@1000.service
           290ms sys-kernel-config.mount
           283ms boot.mount
           219ms systemd-tmpfiles-setup-dev.service
           205ms nfs-config.service
           182ms console-setup.service
            62ms ifupdown-pre.service
1 J'aime

Bonjour,

Je like ton message sur systemd-analyze. Cela permet de faire du ménage dans tous les services qui démarrent et qu’on ne souhaite pas.

A+