Après la fin de la garantie sur mon chromebook, j’ai enfin franchis le pas de passer sous linux, en l’ocurrence fedora !
Bien que restant débutant, j’ai suivi les instructions un peu compliquées pour changer d’OS avec une vidéo Youtube et le projet Mrchromebox. Sur ce site, mon PC (Woomax - Asus CM5500FDA) est parfaitement compatible pour un changement complet d’OS (sans dual boot).
Une fois ces étapes terminées, et un PC fonctionnel, toutes les fonctionnalités présentes sur le chromebook ne le sont pas sur ce Fedora. Je m’y attendais, et après quelques recherches j’arrive à corriger une partie de ces problèmes. Je ferai peut-être d’autres posts sur le forum pour ne pas me disperser.
J’ai 2 problèmes un poil embêtant qui sont peut-être liés :
Lors du démarrage du PC, celui-ci met beaucoup de temps à booter sur l’OS, et ne réussi que rarement à booter du premier coup (une sorte de boucle avec des “redémarrages”). Même en ayant activé le chiffrement du SSD, le démarrage prend vraiment très longtemps (entre 30 secondes à plusieurs minutes, ressenti proche d’un vieux HDD). De plus, avant le boot, j’ai 4 fedora qui me sont proposés, alors que je n’ai fais qu’une seule installation (voir image)
Une fois arrivé sur le bureau, la navigation reste fluide, mais vraiment en deçà du matériel utilisé. J’ai avec moi un SSD nvme Patriot P320 de 512 GO qui n’est pas natif du PC mais fonctionnait très bien quand j’étais sous ChromeOS.
Pour avoir fait un test de vitesse avec kdiskmark, j’obtiens la vitesse d’un SSD SATA, assez loin de la vitesse que propose un SSD (voir image jointe). Je sais que la vitesse de ce type de SSD peut être bridée si le PC est trop chaud, mais même avec rien de lancé j’obtiens cette vitesse.
Merci pour votre réponse ! Mon anglais est moyen, je vais continuer en français.
J’ai effectivement oublier de préciser que peu importe la version du fedora choisi depuis le Grub, rien ne change, aucun ne lance fedora du premier coup.
J’ai rentré ces lignes de code depuis le terminal, voici le résultat en image (le forum ne permet pas l’écriture de plusieurs @ pour les nouveaux utilisateurs) :
Je ne comprends pas trop ce qui est dit, mais quand je vois après “systemd-analyze blame” 1min 907ms, si c’est le temps du démarrage, ce n’est qu’une partie du temps total.
En chronométrant ce démarrage, depuis le moment où j’appuie sur le bouton power et le moment où le PC me demande d’entrer la clé de déchiffrement du SSD, il s’est écoulé 4 minutes et 10 secondes !
Après plusieurs tests, le temps de démarrage jusqu’à la demande de la clé de déchiffrement du SSD varie entre 45 secondes et 5 minutes…
Do you have a NFS mount listed in /etc/fstab? If so, does it help if you add nofail to the list of mount options?
Excerpt from man systemd.mount:
With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. Moreover, the mount unit is not ordered before these target units. This means that the boot will continue without waiting for the mount unit and regardless whether the mount point can be mounted successfully.
In your screenshot, nfs-client.target is mentioned. It looks like it is waiting on wpa_supplicant.service (wireless networking). If you are not using NFS at all, maybe you could uninstall the nfs-utils package?
Is there anything under /etc/systemd/system/network-online.target.wants? If so, ls /etc/systemd/system/network-online.target.wants | sudo xargs systemctl disable might help.
Voici des screenshots sur ce qui est à la fin du scroll. A noter que pour une raison que j’ignore, je dois appuyer sur la touche page down pour accéder à l’entièreté de la sortie : la molette de la souris ne suffit pas.
Le screenshot montre 167 ligne, mais à mon avis il y en a beaucoup plus : j’ai pas réussi à les copier dans un fichier .txt, cette action a fait freeze le PC.
Il y a aussi des espaces vides au milieu de la sortie (screenshot 2), je ne sais pas si cela est normal.
Pas d’inquiétude ! Cela facilite la capture, la lecture et l’indexation du site web pour les recherches ultérieures s’il s’agit de texte. Captures d’écran… un cauchemar !
There is a huge delay from plymouth @ 5 seconds to the amdgpu backlight device completing in systemd. You could try booting your kernel with andgpu.backlight=0 to see if that helps (this is a one shot change to that boot only - it’ll revert to the usual behaviour on subsequent boots, so if you get a blank screen, a reboot will reset everything)
You could also try the parameter `acpi_backlight with any of the following values.
acpi_backlight= [HW,ACPI]
{ vendor | video | native | none }
If set to vendor, prefer vendor-specific driver
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
of the ACPI video.ko driver.
If set to video, use the ACPI video.ko driver.
If set to native, use the device's native backlight mode.
If set to none, disable the ACPI backlight interface.
Failing that, the blacklight device can be masked in systemd which will prevent systemd from trying to start it, but we’ll have to rely on some other piece of firmware or code to switch it on - I’m not a laptop user but I assume the backlight is fired up as part of the hardware initialization process
Right now, systemd is waiting for almost 1.5 minutes for the AMD backlight driver to wake up and turn the backlight on and set it to the preferred, stored level and that delays everything else behind it. If we can remove that delay without impacting anything, you’ll get much faster boot times.
It is actually running properly isn’t it?
systemctl status systemd-acklight@amdgpu_bl1.service
En effet j’ai désactivé le rétroécairage et cela fonctionne un peu mieux. Mais pour le désactiver, je n’ai pas pris amdgpu.backlight=0, cela n’a pas fonctionné. J’ai pris sudo tee /sys/class/leds/chromeos::kbd_backlight/brightness <<< 0
Sur ChromeOS, j’avais le raccourci alt+F6-F7 pour gérer le rétroéclairage, qui ne fonctionne pas sur fedora, logiquement.
Par contre je ne comprends pas ce que je dois faire avec ça :
acpi_backlight= [HW,ACPI]
{ vendor | video | native | none }
If set to vendor, prefer vendor-specific driver
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
of the ACPI video.ko driver.
If set to video, use the ACPI video.ko driver.
If set to native, use the device's native backlight mode.
If set to none, disable the ACPI backlight interface.
Ah, voici les quatre valeurs différentes que vous pouvez transmettre au noyau pour lui indiquer comment gérer le rétroéclairage. Il faut un peu de tâtonnement, mais cela implique d’accéder au menu Grub, de sélectionner votre noyau normalement, mais d’appuyer sur e au lieu d’Entrée.
Appliquez ensuite apci_backlight=vendor au paramètre du noyau juste à côté de rhgb et quiet. Appuyez ensuite sur Ctrl-X pour démarrer et voyez si cela fonctionne. Sinon, passez au paramètre suivant. Si aucun de ces paramètres ne change, alors… pas de chance.
Je pose cette question car l’entrée systemd, qui attend si longtemps, attend d’appliquer un niveau de luminosité au rétroéclairage. Si le rétroéclairage n’est pas encore activé, il ne pourra pas le faire. J’essaie donc de voir si nous pouvons accélérer le rétroéclairage en demandant à la gestion de l’alimentation du noyau d’intervenir… ou peut-être de ne pas intervenir – selon ce qui fonctionne le mieux pour accélérer le processus. C’est pourquoi il s’agit d’un peu d’essais et d’erreurs… Cela peut fonctionner, cela peut n’avoir aucun effet.
C’est bizarre ! Comme on pourrait s’y attendre, cela ne devrait avoir aucun effet. Nous pourrions peut-être corriger cela si nous parvenons à comprendre pourquoi votre ordinateur portable met 1,5 minute à régler le rétroéclairage à votre valeur préférée. C’est tout ce que fait le service systemd… Il se peut donc que le désactiver accélère le processus et n’ait pas d’impact notable.
If it reboots several times before succeeding it might be a problem with your latest installed kernel. Does your system ultimately boot to the latest installed kernel or does it end up falling back to an earlier version? Use uname -r to see what kernel version you are running. Use rpm -q kernel to see what kernel versions are installed on your system.
Après avoir essayé chaque combinaison de apci_backlight je constate effectivement que 2 d’entre eux permet de réduire considérablement le temps de démarrage, le processus de rétroéclairage ne prend que ~10 secondes désormais !
Cependant, comment mettre définitivement apci_backlight ? Car à chaque redémarrage, il faut réappuyer sur e et écrire la commande. De plus, vu que le pc redémarre en plein milieu du boot, je dois recommencer plusieurs fois l’opération avant le démarrage définitif de fedora…
Ce redémarrage intempestif est vraiment pénible ! Est-ce que désactiver rhgb quiet permettrait de comprendre pourquoi ça ne fonctionne pas ou cette commande ne fonctionne pas pour le coreboot ?
