Ceci ne se veut pas un tutoriel mais une liste d’idées plus ou moins expérimentales pour atteindre des temps de démarrage de l’ordre de la seconde (hors bios/uefi) pour un ordinateur mono-utilisateur. Pour utilisateur expérimenté.
0/ Le minimalisme : pas d’environnement de bureau, système “léger”
1/ ne pas faire de partition séparée (notamment /home)
2/ Le parallélisme : je passe par systemd. Le démarrage fainéant : activation par socket des serveurs réseaux, ajout de l’option x-systemd.automount dans le fstab pour tout ce qui est hdd (le disque principal est évidemment ssd).
3/ Il y a toute une série d’optimisation envisageables avec systemd qui est par défaut très mal fichu du point de vue du temps de démarrage (sa “rapidité” est un effet de bord non recherché). Malheureusement Systemd a conservé une partie de la philosophie de ces prédescesseurs : nous avons des étapes qui agissent comme butoir durant le processus de démarrage.
3.a/ Par exemple Xorg est lent à démarrer : plus d’une seconde, Wayland est bien meilleur mais je le trouve encore trop peu fiable. Exemple d’unité Xorg :
[Unit]
Description=Xorg
DefaultDependencies=false
Conflicts=shutdown.target
Before=shutdown.target
[Service]
Type=simple
ExecStart=/usr/bin/Xorg -nolisten tcp :0 -quiet -gamma 0.8 -logverbose 1
L’unité est démarrée le plus tôt possible (et pas après une première phase d’initialisation). De fait c’est Xorg qui va être le plus bloquant durant le processus du démarrage (compter 1s environ + noyau ~0.5s). Pour réellement passer à 1s il faut utiliser Wayland (dans mon cas : iGPU intel driver modeset) et c’est alors clavier+souris USB qui sont les plus long à “donner la main”.
3.b/ masquer dbus.service dbus.socket et systemd-logind.service, désactiver aussi tous les getty@
3.c/ On ne peut alors plus se “logguer” ainsi (prévoir une clef usb de secours au cas où…), il faut ouvrir sa “session” via systemd. Par exemple, avec i3 :
[Unit]
Description=i3
DefaultDependencies=false
Requires=Xorg.service
After=Xorg.service
Conflicts=rescue.service shutdown.target
Before=rescue.service shutdown.target
[Service]
Type=simple
WorkingDirectory=/home/gaudin
Environment=HOME=/home/gaudin SHELL=/bin/zsh DISPLAY=:0 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/gaudin/bin
ExecStart=/usr/bin/i3
User=gaudin
RestartSec=20ms
Restart=on-failure
[Install]
WantedBy=multi-user.target
Évidemment aucun exec ne doit se trouver dans le ~/.i3/config : préférer à cela un service systemd dédié autant que possible (je pense à Urxvtd entre autres).
4/ Compiler son propre noyau linux
4.a/ désactiver tout ce qui ne sert pas, désactiver les modules (mettre en dur le nécessaire).
4.b/ activer le CPU hotplug dans le menuconfig du noyau => c’est extrêmement long de démarrer les cœurs d’un CPU ! Le noyau doit démarrer avec l’argument maxcpus=1 puis les CPUs seront démarrés via des unités CPU@.service :
[Unit]
Description=CPU %i
DefaultDependencies=false
[Service]
Type=oneshot
ExecStart=/bin/dash -c 'echo 1 > /sys/devices/system/cpu/cpu%I/online'
[Install]
WantedBy=multi-user.target
5/ Avec uefi, utiliser le lanceur de la carte mère (noyau compatible efi dans efi/boot/bootx64.efi d’une 1ère partition en fat32)
6/ nettement plus couillu. Lors de l’analyse des log noyaux au tout début du démarrage j’ai remarqué une série de lignes du style : raid6: %-8s gen() %5ld MB/s\n"
Tout ceci pour tester la rapidité d’algorithmes et sélectionner le meilleur : qu’à cela ne tienne ! pas besoin de refaire le test à chaque fois. On modifie directement le source :
static inline const struct raid6_calls *raid6_choose_gen_alt(
void *(*const dptrs)[(65536/PAGE_SIZE)+2], const int disks)
{
const struct raid6_calls *best;
best = raid6_algos[5];
pr_info("raid6: using algorithm %s", best->name);
raid6_call = *best;
return best;
}
En adaptant le [5] à votre cas (voir dans le source le contenu, en dur, du tableau). On remplace l’appel à la fonction originale par notre alternative, on redémarre et vérifie que l’algo retenu est le même que celui sélectionné avec le test. Tout ceci se trouve dans le fichier lib/raid6/algos.c
7/ pester contre l’assembleur de la carte mère, qui lui n’a rien optimisé du tout (5s dans le meilleur des cas \o/)
# Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par totof2000 . Évalué à 8.
… et a possibilité de récupérer celui-ci d'une façon ou d'une autre que de mettre moins d'1 S pour booter et ne pas pouvoir récupérer quoi que ce soit.
De ce fait il y a au moins deux choses que je ne ferai jamais :
- avoir un seul FS pour tout
- désactiver tous les getty (par contre réduire à 1 ou 2 pourrait avoir du sens).
Le getty peut être utile pour killler un process qui fige l'UI graphique sans devoir tout redémarrer, ou pour killer une session graphique sans arrêter des taches qui tournent en arrière plan.
Il y a certainement une raison pour ça, et il faudrait savoir pourquoi ces étapes ont été pensées ainsi avant de tout casser ce qui a été fait (tu ne penses que "vitesse de démarrage" alors qu'il y a peut-être d'autres contraintes qui ont poussé les maintenenurs de la distrib ou de systemd à faire ainsi).
Autre chose : le démarrage fainéant, ou l'illusion que le système est démarré (comme on peut le trouver sur Windows) me paraît être une mauvaise idée : je déteste windows pour ça : le système te fait croire qu'il est démarré en te laissant te logger, mais en fait dès que tu veux lancer le moindre truc, tu te retrouves à devoir attendre des plombes parce que le système en réalité n'est pas prêt.
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par freem . Évalué à 2.
Tiens, toi aussi t'as tiqué en lisant ça?
Idem. En fait, ma solution, c'est d'utiliser un autre getty. Parce que bon, à l'heure actuelle, sur une Debian, par défaut c'est agetty qui est utilisé, un bestiau qui… supporte les connections de type RS232… la plupart des machines n'ont aujourd'hui plus de liaison série, je pense.
Moi, je le remplace par ngetty… il ne supporte pas les liaisons séries, et à l'admirable propriété de n'utiliser une archi type client/serveur, donc pas obligé de se limiter en sessions.
Sauf que… ben je ne sais pas et n'ai pas trouvé comment faire comprendre à systemd que le choix par défaut de ma distrib est pourri, alors je suis reparti sous sysV, qui malgré sa complexité permet au moins de remplacer facilement un foutu getty.
+1. Le bouzin est au final plus lent, parce que pendant qu'il glande à attendre que l'utilisateur se log, il pourrait charger des données utiles. Dans le cas de windows, il y a tellement de bordel à initialiser que c'est réellement long. Mais, c'est un bon argument commercial: système qui boote plus vite, ne veux pas dire système utilisable plus vite.
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par xcomcmdr . Évalué à 3.
T'as pas cherché loin, ça se fait en 30 secondes avec un oveeride :
https://raymii.org/s/tutorials/Run_software_on_tty1_console_instead_of_login_getty.html
Ou encore :
https://unix.stackexchange.com/questions/247293/how-can-i-get-systemd-to-use-qingy-as-my-default-tty-program-instead-of-agetty
C'est bizarre, je le reproduis pas. Que ce soit sous Windows 10, Windows 7, ou Windows XP.
Et pour cause : ce n'est pas comme ça que Windows fonctionne.
Quand tu te logues, Windows a déjà démarré. Si ton ouverture de session est longue, il faut voir du côté des logiciels qui démarrent avec la session, et désactiver ce qui est inutile. Ça dépend de l'utilisateur et de ce qu'il a installé.
Et ça se fait facilement avec le Gestionnaire de tâches.
Et perso, vu que j'ai besoin de pas mal de trucs, j'utilise l'hibernation. Depuis 20 ans.
Et le problème est réglé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par freem . Évalué à 2.
Moi, personnellement, j'ai avec le poste du bureau: 10s de boot, je me log, et la, il mets 1 minute. J'en ai déduit (peut-être à tort) que c'était ça la raison.
Ah… p'tet l'antivirus, mais à part ça… ou peut-être le truc des pilotes graphiques ou touchpad? Parce qu'il n'y a que ça…
Ca, j'ai essayé sur diverses machines. Par forcément l'impression que ce soit tellement tellement plus rapide dans mes usages (assez peu de trucs qui mettent du temps de calcul à s'initialiser en général, plutôt des accès disques, donc l'hibernation ne ferait pas vraiment gagner, je pense).
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par totof2000 . Évalué à 2.
hum …
https://support.microsoft.com/fr-fr/help/305293/description-of-the-windows-fast-logon-optimization-feature
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par freem . Évalué à 2.
Et pourtant, si, j'ai cherché. Mal, a priori, j'approfondirai ces liens.
J'ai commencé en fait par faire un grep sur mon système pour savoir dans quels fichiers c'était défini, et déjà, j'ai eu la surprise de trouver ces fichiers de config dans /lib, et non /etc comme je m'y serai attendu (ce qui du coup me fait penser que le doc sur raymii.org ne s'applique pas à ma debian, surprenant compte tenu du fait qu'il semble se baser sur une ubuntu).
Il y avait dedans 2 fichiers avec getty, et honnêtement, je n'ai pas osé toucher, peur de rendre mon système inopérable.
Pour le 2nd lien, ok, il faut créer un fichier. Je suppose qu'en cherchant un peu je trouverai ou.
Je peux un peu plus bidouiller maintenant que mon système est redevenu à peu près sous mon contrôle…
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par .Nicolas. . Évalué à 2.
Pourquoi ?
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par freem . Évalué à 2.
Parce qu'une eventuelle corruption d'un seul fs fait perdre potentiellement la totalite du systeme, notamment en cas d'absence de sauvegarde.
On peut aussi arguer du fait qu'avoir un fs systeme, un pour le home et un pour les donnees volatiles (genre /var) permets de reduire la fragmentation (donc d'qur disque mecanique, de garder un systeme plus reactif) ou meme, d'avoir plusieurs os et un seul home.
Sans parler de risquer de se retrouver sans comprendre pourquoi avec un systeme bride a cause de la saturation de la partition racine.
Ni le fait pouvoir parametrer differemment les fs (typiquement, j'ai tendance a prefere de gros clusters dans mon /var, ainsi que dans une partition que je reserve aux fichiers iso et multimedia).
Je suis sur qu'il reste nombre d'arguments (dans l'autre sens aussi bien sur) plus ou moins adaptes au vecu et aux besoins de chacuns.
Maintenant, la commande mount, chez moi, et meme sur de tres vieux systemes, c'est (quasi pour le vieux matos de plus de 15 ans) instantanne. Du coup, est-ce ca fait vraiment gagner du temps?
[^] # Re: Je préfère LARGEMENT avoir un système qui met cinq à 10 S de plus pourdémarrer ....
Posté par totof2000 . Évalué à 3.
Ca permet également de mieux gérer les installations/réinstallations ainsi que les restaurations.
# Ou sinon ...
Posté par ninis666 . Évalué à 3.
<troll
Ou sinon:
et hop, ton système est up & running en moins de quelques secondes !
/troll>
En fait je ne comprends pas trop ce genre de démarche en fait : Si tu veux pouvoir ré-démarrer très rapidement, je trouve que le "suspend to disk" ou "suspend to ram" marche assez bien en pratique sur les machines de bureau … Pour les systèmes "embarqués", à la limite, le truc avec /bin/bash aurait vraiment du sens :)
Et puis même si je trouve le boot par systemd trop invasif pour que ce qu'il devrait faire, son vrai intérêt à mes yeux, c'est la gestion des dépendances des services plutôt élégante.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.