Reprise du message précédent :

 
Non seulement un HD
 

J'ai pas compris.  Si l'ordi est éteint il faut le mot de passe pour accéder aux données. Après si l'ordi est en mode sleep forcément c'est autre chose.

Pourtant ton Kernel essaye de lire sur un lecteur de disquettes (fd0 = floppy disk), il échoue et ça prend plein de temps. Le moteur de recherche me sort https://unix.stackexchange.com/ques [...] ux-startup , mais je regarderais d'abord dans le BIOS si il y a un truc à désactiver.

 
Salut, rat de combat.
 
Je peut t'envoyer le fichier texte en MP pour que tu me dise si tout te parais normal?
 
J'ai peur qu'un fichier si long pollue le topic.
 
Merci

Non, je pense qu'on a trouvé le soucis déjà (cf mon message précédent) et je ne suis pas du tout expert pour décortiquer les dmesg. Si tu veux éviter d'insérer trois pages de texte dans ton message tu peux le poster sur un site genre pastebin.com et insérer un lien.

 
Je vais regarder la séquence de boot dans le bios.
Je regarde ça dés demain, là je part bosser
 
Merci
 
 

Moi non plus  

Heu j'ai comme un doute sur l'histoire.
Je demande à voir, mais autant je suis d'accord quand seul le /home est chiffré, autant avec la partition entièrement chiffrée, je ne vois pas comment tu peux la monter vu qu'elle est chiffrée...
Je vais rechercher ça mais ça m'étonne.

Sinon pour le boot, il faudrait creuser le dmesg, par exemple perso j'ai déjà vu des pb de boot à cause d'une webcam en usb. etc.
Y a pas mal de possibilités, dont des réglages de bios nécessaires et des bios à mettre à jour pour espérer avoir des acpi plus standards.

Sur ton pc as tu un lecteur de carte sd ou autre chose du style?

EDIT: je confirme, en mode full crypt, au boot en mode recovery il demande bien évidement le mdp de la partition chiffrée vu qu'il ne peut rien faire...
Donc comme prévu rien n'est accessible.
Et sinon bien évidement le but c'est de ne pas voir ses données accessibles en cas de vol.
Comme on a les photos de famille (je ne parle pas de photo compromettante des photos normales) sur les disques dur, ainsi que des documents perso, je préfère que tout soit chiffré partout.

 
Juste un clavier multimédia sans fil avec mini trackball.

J'ai virer le floppy disc de la séquence de boot du bios ,  J'ai essayé la ligne de commande donné dans le lien. rien n'y fait . je vais donc laisser tomber pour le moment.

Est-ce que les messages concernant fd0 ont disparu de dmesg au moins, ou même pas ?

Pareil, d'autant qu'avec ou sans chiffrement, perso, je ne vois pas de diff à l'œil nu au niveau des perfs.
Il reste par contre une vulnérabilité au niveau du /boot, qui en général n'est pas chiffrée, mais perso ça me suffit comme ça.

La vulnérabilité du /boot pourrait en être une avec un accès physique potentiellement. Mais pas vraiment en cas de vol.
 
Après je pense qu'il doit y avoir moyen de faire quelque chose au pire avec secureboot si besoin.

Oui c'est ça, j'avais vu un lien que je ne retrouve plus, où le gars te changeait ton initramfs pendant que tu as le dos tourné, en mettant dedans un script qui va récupérer ton mot de passe de chiffrement la prochaine fois que tu le rentres, et le stocker sur place. Ensuite, il a plus qu'à te piquer ton ordi, et il a le mot de passe avec.
Pour remédier à ça, il préconisait de chiffrer /boot, en faisant passer le déchiffrement par GRUB, avec une option qui va bien. J'avais testé le truc et ça marchait bien, sauf que ça me gave d'avoir à rentrer mon mdp une fois pour /boot, et ensuite pour Ubuntu… voire encore pour les datas… et pourquoi pas pour la session desktop    
Perso, je rentre mon mdp une seule fois pour déchiffrer ma partition système, et je laisse mon ordi se lancer jusqu'à ma session desktop incluse.

Voilà idem pour moi.

J'ai retrouvé le lien en question, je l'avais tout simplement mis de côté : https://alice.climent-pommeret.red/ [...] ux-system/

Merci pour l'info.
Désactiver le boot usb + CD et mdp bios ça diminue déjà grandement ce problème là.  
 
Mais c'est top de voir comment il faut faire.

 
Non, même pas.

Y'a pas moyen de rajouter une option à GRUB pour lui dire (edit: de dire au Kernel) de ne pas chercher de FDD?

À part le réinstaller avec le paramètre « --no-floppy » ?

Essaie ça, c'est plus récent et plus complet : https://askubuntu.com/questions/719 [...] r-0#884026

 
 
Quand je valide ,  sudo tee /etc/modprobe.d/blacklist-floppy.conf , Le curseur  reste clignotant et n' affiche pas bob@bob-P5Q-E:~$
 
Question: la barre verticale dans la 2end ligne du lien que tu m'as donné  (avant , sudo tee /etc/modprobe.d/blacklist-floppy.conf) ça veux bien dire qu'il faut le taper en 2 fois?  1 fois ce qui est avant la barre et 1 fois ce qui est après ?

Non non, chaque ligne est une commande à copier-coller telle quelle.
La barre en question est un pipe (tube,tuyau) qui dit que le résultat de la première commande est passé à la seconde, c'est un opérateur de concaténation de commandes si tu veux.

Merci;
 
en insistant un peut je suis arrivé à ça.
 

 
Pardon ça:
 

 
Je vais rebooter pour voir;

C'est la même image que tout à l'heure là…

Problème avec l 'éditeur image je refait
 

Ca a marché, je boote nettement plus vite!  
 
Merci à tous , vous etes vraiment au top.

Mets nous un petit retour de systemd-analyse stp  
Tu peux juste copier coller le résultat de la commande si tu veux.

Bien-sur.
 
 11.521s systemd-journal-flush.service
          9.188s dev-mapper-mint\x2d\x2dvg\x2droot.device
          8.313s lvm2-monitor.service
          8.187s keyboard-setup.service
          8.088s systemd-modules-load.service
          6.934s systemd-udevd.service
          6.478s networkd-dispatcher.service
          5.884s NetworkManager.service
          5.436s thermald.service
          5.139s udisks2.service
          4.925s ubuntu-system-adjustments.service
          4.229s wpa_supplicant.service
          3.891s ModemManager.service
          3.566s accounts-daemon.service
          2.740s grub-common.service
          1.750s dns-clean.service
          1.716s lm-sensors.service
          1.680s apport.service
          1.518s systemd-resolved.service
          1.483s lvm2-pvscan@8:1.service
          1.405s rsyslog.service
          1.359s apparmor.service
          1.330s gpu-manager.service
          1.250s systemd-tmpfiles-setup-dev.service
          1.052s hddtemp.service
          1.050s alsa-restore.service
           943ms systemd-remount-fs.service
           915ms systemd-random-seed.service
           906ms lightdm.service
           902ms plymouth-quit-wait.service
           899ms speech-dispatcher.service
           897ms sys-kernel-debug.mount
           897ms dev-hugepages.mount
           891ms dev-mqueue.mount
           864ms systemd-logind.service
           799ms polkit.service
           758ms ntp.service
           594ms avahi-daemon.service
           584ms dev-mapper-mint\x2d\x2dvg\x2dswap_1.swap
           362ms systemd-journald.service
           310ms plymouth-read-write.service
           289ms plymouth-start.service
           172ms systemd-update-utmp.service
           158ms upower.service
           152ms networking.service
           139ms kmod-static-nodes.service
           125ms setvtrgb.service
           123ms blk-availability.service
           113ms user@1000.service
            92ms systemd-udev-trigger.service
            92ms systemd-tmpfiles-setup.service
            48ms console-setup.service
            47ms ufw.service
            43ms rtkit-daemon.service
            41ms systemd-sysctl.service
            12ms kerneloops.service
             8ms ureadahead-stop.service
             6ms systemd-update-utmp-runlevel.service
             5ms openvpn.service
             5ms systemd-user-sessions.service
             3ms sys-fs-fuse-connections.mount
             3ms pppd-dns.service
             3ms sys-kernel-config.mount

Je voulais dire systemd-analyse tout court (sans le blame après).
Le truc qui renvoie juste deux lignes avec trois temps.
Mais il y en a quelques-uns qui ont pris une bonne claque là déjà, dont udisks2 et grub-common.

Voila.
 
bob@bob-P5Q-E:~$ systemd-analyze
Startup finished in 37.437s (kernel) + 24.066s (userspace) = 1min 1.504s
graphical.target reached after 24.058s in userspace
 
 
ça fait plaisir.

À comparer avec ça : https://www.noelshack.com/2019-16-3 [...] -07-50.png
C'est mieux    

Avant:

 
Après:

Top si c'est résolu.

Bonjour, surement un pilote à installer sous linux...  
 
Regarde dans le panneau de contrôle des pilotes propriétaire tu devrais trouver quelque chose.

 
Donne le retour de:
 
lspci
 
Dans un terminal. (La première lettre est un L minuscule)

 
Fais la mise à jour du firmware car la carte ethernet est pas détectée.

 
C'est la carte wifi
Sinon au niveau du BIOS rien à signaler ? Aucun réglage pour la carte ethernet ?

 
J'ai édité. Regarde dans ton BIOS les réglages qu'il y a pour la carte ethernet (s'il y en a)
Et redémarre si tu ne l'as pas fait après la mise à jour du firmware.

Et done:
 
lspci -v
 
(L'option v comme verbose va donner plus de détails)

Si, cela peut venir du BIOS car Windows possède la capacité dans certains cas de jouer avec le power de la carte ethernet. Regarde les options dans le BIOS. Pour le moment, ta carte ethernet n'est pas vue par Linux.