[Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

azen0r · Le 18/08/2020, à 22:52

Bonjour,
Je viens de faire l'acquisition d'un HP ProBook 450 G7 (descriptif complet ici). Et j'ai voulu installer Ubuntu en dual boot, comme je faisais jusque là avec mon vieux DELL Inspiron 1545 qui en est resté à Ubuntu 16.04.1.

EDIT : Aux détenteurs d'un HP ProBook 450 G7 qui souhaitent installer Ubuntu en dual boot, je suggère d'aller directement lire le post #11 qui fait la synthèse des points génériques auxquels faire attention. Et de lire le reste du fil seulement si ça ne suffit pas.

Création d'une live-USB
Je passe les étapes où ma live USB créée avec usb-creator avait un fichier corrompu. Au final, j'ai fait ma live usb en ligne de commande avec dd.
Vérification de l'iso ok :
```
echo "b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d *ubuntu-20.04.1-desktop-amd64.iso" | shasum -a 256 --check
ubuntu-20.04.1-desktop-amd64.iso: OK
```
Vérification des fichiers ok, pas d'erreur/warning avec :
```
md5sum -c md5sum.txt
```
Préparation du PC
J'ai suivi les instructions de la page de doc uefi :
* Dans Windows, j'ai désactivé le Fast startup (en suivant ce tuto).
* Dans le Bios : Fastboot désactivé et Bootorder modifié pour mettre USB en premier
* Dans le Bios, j'ai aussi désactivé le secure boot : le champ initialement à "Legacy Support Disable and Secure Boot Enable" a été passé à "Legacy Support Disable and Secure Boot Disable"
* Je n'ai pas trouvé dans le Bios de référence à Intel Smart Response Technology (SRT) donc je ne sais pas si ce point s'applique à mon PC

Résultat 1
* La page de grub 2 s'affiche, avec les choix
Ubuntu
Ubuntu (safe graphics)
OEM install
Boot from next volume
UEFI firmware settings
* En sélectionnant Ubuntu, j'ai l'écran avec les logos HP et Ubuntu sur fond noir. "checking disks : 0% complete" s'affiche.
* J'appuie sur Echap pour voir ce qui se passe (j'ai recopié à la main les messages à l'écran, il peut y avoir des coquilles) :

[   4.xxxxxx] Initramfs unpacking failed: Decoding failed
[   4.xxxxxx] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000005)
[   4.xxxxxx] ACPI Error: Aborting method \_TZ.GETP due to previous error (AE_A
[   4.xxxxxx] ACPI Error: Aborting method \_TZ.CHGZ.CRT due to previous error
[   4.xxxxxx] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000005)
[   4.xxxxxx] ACPI Error: Aborting method \_TZ.GETP due to previous error (AE_A
[   4.xxxxxx] ACPI Error: Aborting method \_TZ.CHGZ.CRT due to previous error
[   4.xxxxxx] tpm tpm0: tpm_try_transmit: send(): error -5
[   4.xxxxxx] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling inst
stdin: Invalid argument
stdin: Invalid argument
Partition #3 contains a ext4 signature.
[  17.xxxxxx] scsi 2:0:0:0: rejecting I/O to dead device
[  17.xxxxxx] blk_update_request:I/O error dev sda, sector 30943712 op Ox1:(WRITE) flags 0x400...
[  17.xxxxxx] scsi 2:0:0:0: rejecting I/O to dead device
[  17.xxxxxx] blk_update_request:I/O error dev sda, sector 30943952 op Ox1:(WRITE) flags 0x400...
[  17.xxxxxx] scsi 2:0:0:0: rejecting I/O to dead device
[  17.xxxxxx] blk_update_request:I/O error dev sda, sector 30944192 op Ox1:(WRITE) flags 0x400...
[  17.xxxxxx] Buffer I/O error on dev sda3, logical block 2, lost async page write
[  17.xxxxxx] Buffer I/O error on dev sda3, logical block 3, lost async page write
[...4 à 8...]
[  17.xxxxxx] Buffer I/O error on dev sda3, logical block 9, lost async page write
[  17.xxxxxx] Buffer I/O error on dev sda3, logical block 2046, lost async page write
[  17.xxxxxx] Buffer I/O error on dev sda3, logical block 2047, lost async page write
mkfs.ext4: Input/Output error while writing out and closing file system
mount: mounting /dev/sda1 on /cdrom failed: No such file or directory
stdin: Invalid argument
stdin: Invalid argument
[...]
stdin: Invalid argument
Unable to find a medium container a live file system
Attempt interactive netboot from a URL ?

Et là je suis bon pour un arrêt forcé

Même essai avec Ubuntu 18.04.5 à la place de 20.04.1 sur la live-USB
Vérification des fichiers ok, pas d'erreur/warning avec :
```
md5sum -c md5sum.txt
```
Et là je vais jusqu'à l'ouverture de session sans problème visible.
J'ai sorti le rapport Boot-Info
Je ne sais pas lire ce rapport, mais le "0 OS detected" m'interpelle, car j'ai un Windows 10 installé et je compte bien faire un dual boot, pas l'écraser.

Au final, j'aimerais surtout trouver la solution pour avoir Ubuntu 20.04 opérationnel (d'abord le démarrage en live-usb, puis l'installation en dual boot). S'il faut se rabattre sur la 18.04.5, je le ferai mais j'aimerais dans ce cas être rassuré sur le fait que le "0 OS detected" ne signifie pas que l'installation va écraser mon windows 10 actuel.
En vous remerciant,

Dernière modification par azen0r (Le 20/08/2020, à 15:44)

PmGs · Le 19/08/2020, à 06:17

Je vois des erreurs sur /dev/sda3 qui doit être ton live-usb, est-ce que ce pas simplement ceci ton pb? Je referais la manip avec un autre usb ou un cd.

moko138 · Le 19/08/2020, à 09:28

azen0r a écrit :

Je n'ai pas trouvé dans le Bios de référence à Intel Smart Response Technology (SRT) donc je ne sais pas si ce point s'applique à mon PC

Oh que oui ! Voir là le Nota Bene 2.

EDIT : Si du moins elle est présente (soit dans le bios, soit dans Windows).

Dernière modification par moko138 (Le 19/08/2020, à 09:31)

geole · Le 19/08/2020, à 15:29

Bonjour
Je pense que la première clé avait réellement un problème physique Dans la recopie tu as mis SDA3 Mais c'était probablement SDA1

As tu pensé à booter windows et libérer un peu de place disque? car il n'y en a pas!

fdisk -l (filtered): ___________________________________________________________
Disk nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk identifier: BE015D6E-E40F-4A09-8E72-87E5C013F1C4
              Start        End   Sectors  Size Type
nvme0n1p1      2048     534527    532480  260M EFI System
nvme0n1p2    534528     567295     32768   16M Microsoft reserved
nvme0n1p3    567296  998766591 998199296  476G Microsoft basic data
nvme0n1p4 998766592 1000204287   1437696  702M Windows recovery environment

Windows n'est pas détecté dans cette partition

nvme0n1p3: _____________________________________________________________________
    File system:       
    Boot sector type:  Unknown
    Boot sector info:

Mais c'est probablement un bug de boot-info. Il y a encore peu de temps, il ne savait pas lire le contenu des partitions NVME
===> à moins que l'installation de windows ne soit pas totalement standard

Tu pourrais retenter une nouvelle fabrication 20.04 (avec une autre clé?).
sans oublier
Une fois la commande terminée, forcez les buffers à finir de se vider sur la clé avec la commande :

sync

La documentation du constructeur de ton ordinateur n'évoque pas IRST. C 'est un gros avantage avec un disque dur mais très discutable avec un NVME.

AJOUT Pour le dual boot, le contenu de cette partition est utilisé. Windows y est bien détecté

nvme0n1p1: _____________________________________________________________________
    File system:       vfat
    Boot sector type:  Windows 8/2012: FAT32
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        /efi/Boot/bootx64.efi /efi/HP/BiosUpdate/BiosMgmt.efi 
............
                       /efi/Microsoft/Boot/bootmgfw.efi 
                       /efi/Microsoft/Boot/bootmgr.efi 
                       /efi/Microsoft/Boot/memtest.efi

Dernière modification par geole (Le 19/08/2020, à 15:51)

azen0r · Le 19/08/2020, à 21:52

Bonjour

PmGs a écrit :

Je vois des erreurs sur /dev/sda3 qui doit être ton live-usb, est-ce que ce pas simplement ceci ton pb? Je referais la manip avec un autre usb ou un cd.

En effet, avec une autre clé USB, j'ai réussi à booter sur 20.04.1. C'est rageant car la clé défectueuse est récente et la clé qui marche est un vieux goodies... bref, bien vu et merci.

J'ai refait un boot-info depuis la live session 20.04.1. Le résultat est légèrement différent du précédent, mais j'ai toujours 0 OS detected.

geole a écrit :

As tu pensé à booter windows et libérer un peu de place disque? car il n'y en a pas!
[...]
===> à moins que l'installation de windows ne soit pas totalement standard

Cet ordi est tout neuf, donc il y a forcément de la place. Par contre, je me demande si le hic ne vient pas du fait que ma partition Windows est chiffrée par BitLocker. Je pense que ça pourrait aussi expliquer pourquoi geole a l'impression que le disque est plein.

J'ai trouvé ce topic qui parle de BitLocker
Je vais prendre le temps de tout lire, mais à première vue, je pense que je vais suivre les conseils donnés en page 2 et désactiver BitLocker, puis réduire la partition Windows depuis une session Windows (ça fait pourtant 10 ans que je réduis mes partitions Windows avec gparted, les temps changent !)

La discussion citée date d'un an, est-ce que vous estimez qu'elle est toujours applicable ?
Merci

geole · Le 19/08/2020, à 22:17

Lance donc ton windows et demande lui de rétrécir au maxima son C: Car cela n'a pas été fait.

Il ne me semble pas vital que ubuntu aille regarder ce qui est présent dans C: en EFI, tu peux conserver bitlocker puisque le dual boot se fait avec la partition de boot EFI qui est standard.

Comme le C: est chiffré, il est inaccesible ... On ne peut donc pas savoir ce qu'il contient. Ce qui explique que windows n'a pas été découvert. Mais cela n'a pas d'importance.

azen0r · Le 19/08/2020, à 22:36

Merci geole, je vais faire ça (demain). Je ne manquerai pas de vous tenir au courant !
Je n'ai jamais été expert dans le domaine, mais ça fait un paquet d'année que je bricole sous Ubuntu, et j'ai comme l'impression que ça me pénalise plus qu'autre chose. En effet je n'ai pas encore réduit la partition Windows car pour moi c'est quelque chose qui se faisait bien avec gparted au moment de l'install, (ou juste avant depuis la live session). Quant à l'EFI, je découvre complètement ce nouveau standard qui n'a pas l'air de simplifier la vie des linuxiens et les diverses options de boot qui peuvent causer des soucis.
A demain donc...

geole · Le 19/08/2020, à 22:44

Comme la partition est chiffrée, gparted ne va pas probablement pas savoir faire..

Dernière modification par geole (Le 19/08/2020, à 22:50)

azen0r · Le 20/08/2020, à 10:22

Bonjour,
Je constate des problèmes d'accès au forum et des posts qui se sont vidés de leur substance,
j'espère pouvoir continuer la discussion malgré ça. Je toiletterai ce message quand le forum sera remis d'aplomb. Edit : ça c'est fait
Je n'avais pas l'intention de m'entêter à utiliser gparted, si maintenant la meilleure façon de faire est d'utiliser l'utilitaire Windows, ça ne me pose pas de problème.

Pour pouvoir démarrer ma session Windows, j'ai donc rétabli le secure boot dans le Bios. D'après le tuto uefi ça ne doit pas poser de problème :

doc uefi a écrit :

ces versions d'Ubuntu s'affranchissent de la désactivation du Secure Boot.

Les boot sous Windows et Ubuntu (live) fonctionnent alors tous les deux.

Sous Windows, j'ai réduit la partition C: à 56Go (dont 16 de libre, je n'ai pas l'intention de m'en servir beaucoup, et certainement pas pour mes données).

Après réduction de la partition C:, Windows et Ubuntu (live) restent opérationnels. gparted voit bien 420 Go d'espace "unallocated" entre la partition C: chiffrée de Windows et la partition de recovery Windows en fin de disque.

Depuis la live USB, je lance donc l'installation proprement dite d'Ubuntu. J'ai alors le choix entre

Installer Ubuntu à côté de Windows Boot Manager
J'aurais bien opté pour ce choix, quitte à modifier un peu les partitions à posteriori (pour me créer une partition /Data dédiée à mes données) mais je bute sur une page Désactiver BitLocker
Cet ordinateur utilise le chiffrement BitLocker de Windows. Vous devez désactiver BitLocker dans Windows avant d'installer Ubuntu. Pour obtenir des instructions, ouvrez cette page sur un téléphone ou un autre appareil : help.ubuntu.com/bitlocker
Effacer le disque et installer Ubuntu
Ce n'est pas ce que je veux

Autre chose
Vu qu'il y a de l'espace "unallocated" sur le disque, et avec les explications de geole, je me dis qu'il doit être possible d'installer Ubuntu sans qu'il ait besoin d'aller triturer la partition chiffrée du C: Windows, mais je suis un peu perdu dans la page suivante. La table de partition se présente comme ceci :

/dev/nvme0n1
   espace libre          1MB
   /dev/nvme0n1p1 efi   272MB        89MB     Windows Boot Manager
   /dev/nvme0n1p2       16MB         inconnu
   /dev/nvme0n1p3       60190MB      inconnu    (lui c'est le windows chiffré)
   espace libre        450887MB
   /dev/nvme0n1p4 ntfs  736MB         0MB
   espace libre         5MB

Que faut-il choisir pour le "Périphérique où sera installé le programme de démarrage" ? /dev/nvme0n1 comme proposé par défaut ou /dev/nvme0n1p1 ?

L'installateur va-t-il ensuite me laisser choisir le partitionnement et les points de montage ? Vu que le bouton suivant est "Installer Maintenant" j'ai un peu peur de lâcher les chevaux
Merci

Dernière modification par azen0r (Le 20/08/2020, à 13:21)

geole · Le 20/08/2020, à 11:04

Bonjour
Réponse en mode dégradé
Le logiciel va trouver automatiquement la partition de boot EFI et y ajouter un répertoire; 
Tu auras juste à choisir l'espace libre pour installer le logiciel

 Si tu choisis "installer à coté de windows", il va  s'installer automatiquement dans l'endroit qui a le plus d'espace libre.

Je continue de penser  qu'il est inutile de déactiver  bitllocker.   Il ne doit pas intervenir dans l'écriture de la partition formatée en EXT4. 
Tu ne pourras simplement pas lire le contenu du C:  qui ne  contient que du logiciel. 
Mais  tu ne pourras pas avoir une partition de données commune en NTFS. C'est toi qui voit

Dernière modification par geole (Le 20/08/2020, à 11:06)

azen0r · Le 20/08/2020, à 15:37

J'avais pas bien compris que l'interface qui arrive immédiatement après "Autre chose" est déjà celle où on peut créer les partitions et les points de montage.
Une fois que ça a été fait, j'ai sélectionné /dev/nvme0n1p1 comme "Périphérique où sera installé le programme de démarrage" (mais l'installateur se serait peut-être aussi bien sorti avec /dev/nvme0n1). Et l'installation s'est bien déroulée.

Je n'ai pour l'instant détecté aucun problème de matériel (touch pad, wifi, etc) mais je commence à peine à l'utiliser.

Au reboot sous Windows, il a fallu que je fournisse une clé de récupération de BitLocker car la partition de boot a été modifiée.

Au final, l'installation de Ubuntu 20.04.1 sur un HP ProBook 450 G7 est possible et même assez facile si on connaît la marche à suivre. Le point le plus particulier étant que ce PC est livré avec un chiffrement de la partition Windows (BitLocker) à prendre en compte. Les points importants :

Il faut avoir une clé USB qui fonctionne bien en live-USB.
ça parait évident mais c'est ce qui m'aura le plus pénalisé, car même quand l'intégrité de chaque fichier de la clé est validée, ça ne garantit pas que la clé est ok. Merci d'avoir su traduire les messages d'erreur
Conformément aux divers tuto cités dans ce fil :
° J'ai désactivé Fast startup (se fait depuis la session Windows). De mon côté, j'ai d'abord décoché l'option dans les outils graphiques, puis carrément supprimé l'option via "powercfg /h off" en ligne de commande
° J'ai désactivé Fastboot dans le Bios
° J'ai modifié le boot order dans le Bios pour passer l'USB en 1er
° J'ai réduit la partition C: Windows depuis l'utilitaire Windows pour faire de la place à Ubuntu (puisqu'elle est chiffrée, pas envisageable de le faire depuis Linux)
Contrairement à ce qu'on peut lire sur certains tuto/fils plus ou moins anciens, dans le cas de ce PC :
° Il n'est pas nécessaire de désactiver le Secure Boot, l'installateur Ubuntu se débrouille très bien avec
° Il n'y a pas à désactiver Intel Smart Response Technology (SRT) car cette techno semble tout simplement absente de ce PC
° Il n'est pas nécessaire de désactiver BitLocker
L'installation automatique à côté de Windows n'est pas possible car l'utilitaire d'installation détecte que la partition du Windows est chiffrée par BitLocker et refuse d'aller plus loin. Pourtant, vu qu'on a préalablement fait de la place sur le disque, l'utilitaire n'a pas besoin de manipuler cette partition. En choisissant "autre chose" dans l'utilitaire, on peut créer ses partitions dédiées Ubuntu manuellement, choisir comme "Périphérique où sera installé le programme de démarrage" celui qui contient le "Windows Boot Manager"et là tout se passe très bien.
Une fois l'installation Ubuntu terminée, le premier boot sur Windows bascule dans un utilitaire de récupération de BitLocker car la partition de boot a été modifiée. J'ai obtenu la clé sur mon compte en ligne Windows http://aka.ms/myrecoverykey (adresse donnée sur la page d'erreur lors du boot Windows) et ça a bien marché. Je pense qu'il serait plus prudent d'obtenir cette clé de récupération AVANT de démarrer l'installation d'Ubuntu !

Voilà, merci aux aidants, et bonne chance aux suivants !
Je vais passer ce fil en résolu et ajouter mon PC à la liste_portables_hp

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/08/2020, à 22:52

[Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#2 Le 19/08/2020, à 06:17

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#3 Le 19/08/2020, à 09:28

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#4 Le 19/08/2020, à 15:29

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#5 Le 19/08/2020, à 21:52

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#6 Le 19/08/2020, à 22:17

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#7 Le 19/08/2020, à 22:36

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#8 Le 19/08/2020, à 22:44

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#9 Le 20/08/2020, à 10:22

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#10 Le 20/08/2020, à 11:04

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

#11 Le 20/08/2020, à 15:37

Re : [Résolu] Ubuntu 20.04.1 sur HP ProBook 450 G7

Pied de page des forums