Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème d'installation d'Ubuntu 19.04

Psykopak

Firefox a crash et impossible de le redémarrer du coup j'ai tout recopier.
Possible qu'une commande soit mal recopié même si j'ai fait attention

 root@ubuntu:/# grub-install --no-nvram 
Installing for i386-pc platform. 
grub-install: error: install device isn't specified. 
root@ubuntu:/# grub-install --no-nvram  --root directory=/mnt
Installing for i386-pc platform. 
grub-install: error: install device isn't specified. 
root@ubuntu:/# mkdir -p /mnt/boot/efi
root@ubuntu:/# umount /dev/sdb1
umount: /dev/sdb1: not mounted. 
root@ubuntu:/# mount /dev/sdb1 /mnt/boot/efi
root@ubuntu:/# grub-install --no-nvram 
Installing for i386-pc platform. 
grub-install: error: install device isn't specified.

geole

C'est un peu ce que je soupçonnais: Seule la partie 32 bits est présente, il n'y a pas de 64 bits.
root@ubuntu:/# grub-install --no-nvram
Installing for i386-pc platform.

Pourtant, dans ton boot-info, il y a bien
boot-info is executed in live-session (Ubuntu 18.04.1 LTS, bionic, Ubuntu, x86_64)

Il y aura donc une commande à faire de plus avant d'installer. Cela va certainement se trouver dans le forum

Psykopak

La partie 64bits de Ubuntu ?

geole

En fait, j'ai dit une bêtise . Le grub 64 bits, ne peut pas être présent puisqu'on a installé avec ubiquity -b qui dit de ne pas installer le grub..
Que donne le redémarrage avec les icones refind ?

Si refind est toujours à coté de la plaque, tu rebootes en technique chroot

Puis la partie d'installation du grub 64 bits sera tentée par (d'après une adaptation libre de https://doc.ubuntu-fr.org/boot-repair#installation_de_la_structure_de_boot_efi_en_lignes_de_commandes )

apt  update   
apt install grub2-common         #######   et pas    apt install grub2-commun
apt  install grub-pc
apt install grub-pc-bin

grub-install   -v    --no-nvram       --efi-directory=/boot/efi

Je stoppe pour ce soir.

Psykopak

geole a écritEn fait, j'ai dit une bêtise . Le grub 64 bits, ne peut pas être présent puisqu'on a installé avec ubiquity -b qui dit de ne pas installer le grub..
Que donne le redémarrage avec les icones refind ?

Si refind est toujours à coté de la plaque, tu rebootes en technique chroot

Puis la partie d'installation du grub 64 bits sera tentée par (d'après une adaptation libre de https://doc.ubuntu-fr.org/boot-repair#installation_de_la_structure_de_boot_efi_en_lignes_de_commandes )
apt  update   
apt install grub2-commun
apt  install grub-pc
apt install grub-pc-bin  
grub-install   -v    --no-nvram       --efi-directory=/boot/efi  
Je stoppe pour ce soir.

Voilà ce que j'ai fait, je pense l'avoir mal fait :

 
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@ubuntu:~$ setxkbmap fr
ubuntu@ubuntu:~$ sudo -i  
root@ubuntu:~# apt  update 
Ign:1 cdrom://Ubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725) bionic InRelease
Hit:2 cdrom://Ubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725) bionic Release
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:5 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]      
Get:6 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]    
Get:7 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [697 kB]
Get:8 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [464 kB]
Get:9 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [160 kB]
Get:10 http://security.ubuntu.com/ubuntu bionic-security/main amd64 DEP-11 Metadata [22.7 kB]
Get:11 http://security.ubuntu.com/ubuntu bionic-security/main DEP-11 48x48 Icons [10.4 kB]
Get:12 http://security.ubuntu.com/ubuntu bionic-security/main DEP-11 64x64 Icons [31.7 kB]
Get:13 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [4296 B]
Get:14 http://security.ubuntu.com/ubuntu bionic-security/restricted Translation-en [2192 B]
Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [255 kB]
Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 DEP-11 Metadata [282 kB]
Get:17 http://archive.ubuntu.com/ubuntu bionic-updates/main DEP-11 48x48 Icons [66.7 kB]
Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/main DEP-11 64x64 Icons [134 kB]
Get:19 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [7024 B]
Get:20 http://archive.ubuntu.com/ubuntu bionic-updates/restricted Translation-en [3076 B]
Fetched 2317 kB in 31s (75.1 kB/s)                                             
Reading package lists... Done
Building dependency tree       
Reading state information... Done
668 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@ubuntu:~# apt install grub2-commun
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package grub2-commun
root@ubuntu:~#

Vu qu'il y a E: Unable to locate package grub2-commun

geole

Bonjour
C'est dommages que tu n'ais pas pensé à dire si les noms de fichiers des icones oranges proposés par refind avaient un peu changé...

Je suis profondément surpris que, après la grosse mise à jour de hier, on se retrouve encore avec
668 packages can be upgraded. Run 'apt list --upgradable' to see them.

Je pense que tu as oublié de refaire le CHROOT pour revenir dans le ubuntu installé et que tu soit resté sur le support d'installation.
Finalement je suis content d'avoir fait une faute de frappe, sinon je crois que cela aurait fortement abîmé le support d'installation.

Donc, tu fais bien la manipulation de passage CHROOT

Tu vérifies que tu es bien en CHROOT avec cette commande

ls   -ls  /home

qui doit indiquer ton nom d'utilisateur et tu fais les commandes

apt  update   
apt install grub2-common
apt  install grub-pc
apt install grub-pc-bin

grub-install   -v    --no-nvram       --efi-directory=/boot/efi

et tu rebootes et tu dis ce que les icones de refind proposent comme fichiers de boot.

Psykopak

geole a écritBonjour
C'est dommages que tu n'ais pas pensé à dire si les noms de fichiers des icones oranges proposés par refind avaient un peu changé...

Je suis profondément surpris que, après la grosse mise à jour de hier, on se retrouve encore avec
668 packages can be upgraded. Run 'apt list --upgradable' to see them.

Je pense que tu as oublié de refaire le CHROOT pour revenir dans le ubuntu installé et que tu soit resté sur le support d'installation.
Finalement je suis content d'avoir fait une faute de frappe, sinon je crois que cela aurait fortement abîmé le support d'installation.

Donc, tu fais bien la manipulation de passage CHROOT

Tu vérifies que tu es bien en CHROOT avec cette commande
ls   -ls  /home
qui doit indiquer ton nom d'utilisateur et tu fais les commandes
apt  update   
apt install grub2-common
apt  install grub-pc
apt install grub-pc-bin  
grub-install   -v    --no-nvram       --efi-directory=/boot/efi  
et tu rebootes et tu dis ce que les icones de refind proposent comme fichiers de boot.

Mais c'est quoi la manipulation du passage en chroot exactement ?

geole

J'ai tout récapitulé dans ce message https://forum.ubuntu-fr.org/viewtopic.php?pid=22132632#p22132632
La technique de passage en CHROOT Plus la correction proposée sous forme d'ajout.

Psykopak

geole a écritJ'ai tout récapitulé dans ce message https://forum.ubuntu-fr.org/viewtopic.php?pid=22132632#p22132632
La technique de passage en CHROOT Plus la correction proposée sous forme d'ajout.

J'ai recopié les commandes sur un nouveau terminal après avoir fermé le premier :

ubuntu@ubuntu:~$ setxkbmap fr 
ubuntu@ubuntu:~$ sudo -i  
root@ubuntu:~# mount   /dev/sdb2 /mnt
root@ubuntu:~# mount -t sysfs /sys               /mnt/sys
root@ubuntu:~#    mount --bind   /dev               /mnt/dev
root@ubuntu:~#  mount --bind   /run               /mnt/run
root@ubuntu:~#    mount --bind   /sys               /mnt/sys
root@ubuntu:~#    mount --bind   /etc/resolv.conf   /mnt/etc/resolv.conf
root@ubuntu:~#    modprobe efivars 
root@ubuntu:~# chroot /mnt
-bash: /usr/sbin/chroot: Input/output error
root@ubuntu:~#

geole

Avec ton support d'installation, on va essayer de regarder l'état du disque

1) Installe le logiciel avec cette commande

sudo apt-get install --no-install-recommends smartmontools

Ne poste que si cela ne fonctionne pas

2) Publie l'état du disque avec cette commande

sudo   smartctl  -s   on  -a    /dev/sdb

Psykopak

Les deux fois où je ferme le terminal il y a écrit
"Close this terminal ?
There is still a process running in this terminal. Closing the terminal will kill it.

[Cancel] [Close the terminal]"

Je rentre les commandes à la suite ou j'ouvre un nouveau ?

sudo apt-get install --no-install-recommends smartmontools 
sudo   smartctl  -s   on  -a    /dev/sdb

(A vrai dire je ne sais même ce qu'est le chroot)

geole

Tu rentres ces commandes dans une instance qui fonctionne. Donc celle qui tourne convient.
Elle va donner l'état du disque dur car cette commande

root@ubuntu:~# chroot /mnt
-bash: /usr/sbin/chroot: Input/output error

a sorti un message d'erreur d'accès à un disque. Je ne connais pas trop le mécanisme de gestion d'erreur et je suis incapable de savoir si l'erreur est sur le disque dur ou sur la clé USB. Je pars du principe qu'il vaut mieux regarder l'état du disque dur en premier. Si je le trouve de qualité, j'envisagerais que c'est la clé qui a un problème, et il faudra que tu en achètes une autre... Je me demande d'ailleurs, vu les derniers ennuis que tu as eu pour booter si l'état de la clé n'y est pas pour quelque chose.

Je pensais t'avoir donné le lien sur la documentation chroot https://doc.ubuntu-fr.org/chroot
C'est écrit " La commande chroot permet de changer le répertoire racine vers un nouvel emplacement. "
En clair, lorsque tu es dans une instance ubuntu qui fonctionne et qu'il y en a une autre sur la machine, au lieu de booter, on fait la commande chroot et on se retrouve dans l'autre instance. On la peut quitter en revenant dans l'instance et aller sur une autre. Comme tu le vois c'est assez pratique. Boot-repair est basé sur ce principe. Mais avant de faire ce saut, il y a des commandes de préparation pour aller au bon endroit. Sinon on va dans le mur.

Comme le GRUB ne sait pas fonctionner et que refind ne trouve pas, il ne reste que cette technique ou l'utilisation de Super Grub 2 Disk dont il me semble que tu n'as pas préparé le support

Antt0n

Bonjour,
Pour rEDInd, le plus simple est de monter la partition sur laquelle il se trouve, puis d'éditer le fichier de configuration.
Vu l'état actuel de la conversation, j'ai du mal à comprendre où se situe le problème.
Il peut rester des résidus de l'installation de GRUB dans la partition principale EFI (sda1, le BootLoader de Windows), qu'il faut supprimer manuellement, en cas d'une première tentative d'installation d'Ubuntu avec BootLoader.

Le plus simple ne serait-il pas de formater les partitions et recommencer depuis une installation propre ?
=> https://antt0n.github.io/papers/lordi-linux.pdf
Tout est expliqué, il ne devrait normalement n'y avoir aucun problème.

EDIT:

Je me permets aussi de donner ce lien, permettant une remise à l'état d'usine de l'ordinateur :
https://lordi.grouperdi.com/_layouts/download.aspx?SourceUrl=%2FNOTES%20TECHNIQUES%2FHP%20ProBook%20x360%2FCreate%2DCRecovery%2Eexe&FldUrl=&Source=https%3A%2F%2Flordi%2Egrouperdi%2Ecom%2FNOTES%2520TECHNIQUES%2FForms%2FAllItems%2Easpx%3FRootFolder%3D%252FNOTES%2520TECHNIQUES%252FHP%2520ProBook%2520x360%26FolderCTID%3D0x012000640FFE2AA01D4C49ACE51C8F77FE9778%26View%3D%7BC9548D50%2D3EC0%2D4342%2DA49B%2D109BFD52D7E9%7D
Cela implique le retour de Windows, ainsi que du BootLoader présent au départ avec l'ordinateur.

geole

Bonsoir Antt0n

Merci de ton arrivée. La discussion est très longue. L'idée de base que j'ai suivie était d'utiliser refind.
J'ai le sentiment qu'il y a un bug dans refind.
Probablement d'abord en documentation. Il y a plusieurs fois que je le constate. J'ai d'ailleurs ouvert un bug ( https://bugs.launchpad.net/ubuntu/+source/refind/+bug/1836487 ) encore sans réponse.
En théorie, d'après la documentation, la présence des fichiers de boot dans /boot doit suffire à proposer l'icone de boot. Ce n'est pas le cas Voir les photos de l'échange 101 https://forum.ubuntu-fr.org/viewtopic.php?pid=22123165#p22123165 et les quelques échanges qui suivent
Ainsi que le post 132 https://forum.ubuntu-fr.org/viewtopic.php?pid=22132600#p22132600 qui liste les seuls fichiers proposés et le suivant montrant que les fichiers officiels sont bien présents dans /BOOT

Qu'à cela ne tienne, on a fait une entrée manuelle.
Puis après avoir forcé le lancement du fichier de boot, le boot opère mais il se plante avec le message d'erreur disant qu'il manque un truc (il n'y a pas d'autre mot que "truc" ) dans le fichier de boot
Message d'erreur : Error: Not Found while loading vmlinuz-4.15.0-55-generic
voir post N° 137 https://forum.ubuntu-fr.org/viewtopic.php?pid=22132650#p22132650

J'en déduis, peut-être prématurément, que ce fichier de boot n'est pas proposé par refind, car il a vérifié le contenu (pas indiqué dans la DOC) et constaté qu'il manque un truc. Si on peut mettre un nom sur truc , on avancera . Dans ce nom, il y aura certainement de la structure de boot 64 bits qui n'est pas mise lors d'une installation par la commande ubiquity -b (Un bug de ubiquity ?)

L'installation initiale était en 19.04. Elle a totallement cassé le bios qui a été réinitialisé. C'est maintenant une tentative en 18.04.1.
Je tente de faire installer le grub 64 bits en espérant pouvoir y mettre l'option --no-vram afin que ce bios ne casse pas une nouvelle fois.

Nota. Dans la version 19.04, La nouvelle option de refind demandant de ne pas "chatouiller le bios" a été positionnée sans succès.

Qid

geole a écritLa discussion est très longue.

J'avoue que de mon côté c'est pour ça que j'ai un peu abandonné : j'ai perdu le fil à un moment et depuis je suis perdu...

Pour moi vmlinuz c'est lié soit au kernel soit à "GRUB" (au démarreur)... Toujours est-il que avez vous essayé de l'installer manuellement ?

geole

Bonjour Qid
La version 19.04 avait été installée classiquement sauf que l'installation ne se terminait pas car stoppée au moment de la mise à jour du bios probablement sur le module shimx64.efi qui ne sert à rien lorsqu'on n'utilise pas le mode secure. Plusieurs tentatives de " holder " quelques modules n'ont rien donné. Sinon d'aggraver la situation.
Cependant on sait que le problème n'est pas totalement lié au bios puisque refind a pu être installé et fonctionne correctement.
Je ne peux que répéter mon conseil, Si on part à l'aventure d'un dual boot, la première des choses à faire est d'installer refind. Si refind ne peut pas s'installer ce n'est pas le grub qui sauvera. On aura gagné beaucoup de temps pour le diagnostic.

Le bios a été réinitialisé et tentative de booter avec la version 18.04
J'essaie de faire jouer ce scénario https://forum.ubuntu-fr.org/viewtopic.php?pid=22132632#p22132632 qui devrait au moins répondre quelque chose au moment de l'installation du grub. Sauf que la commande chroot se comporte mal.. ==> https://forum.ubuntu-fr.org/viewtopic.php?pid=22133216#p22133216

AJout: J'ai un peu bricolé mon UBUNTU 18.04 en enlevant pas mal de modules du grub x86_64

J'ai ce message d'erreur dont je me moque complètement puisque je boote avec refind

sudo grub-install --no-nvram -v
grub-install : information : executing modprobe efivars 2>/dev/null.
grub-install : information : Looking for /sys/firmware/efi ...
grub-install : information : ...found.
grub-install : information : ... but x86_64-efi platform not available.
grub-install : information : ... not found. Looking for /proc/device-tree ...
grub-install : information : ... not found.
Installation pour la plate-forme i386-pc.
grub-install : erreur : le périphérique d'installation n'est pas indiqué.

Je tiens à préciser que j'ai installé récemment Kubuntu18.04 Lubuntu19.04 et Ubuntu19.04 avec la technique ubiquity -b et que refind les détecte bien.

Psykopak

Salut à tous, l'installation a plantée dès le début :

 root@ubuntu:~# sudo apt-get install --no-install-recommends smartmontools 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  gsmartcontrol smart-notifier
Recommended packages:
  mailx | mailutils
The following NEW packages will be installed:
  smartmontools
0 upgraded, 1 newly installed, 0 to remove and 668 not upgraded.
Need to get 464 kB of archives.
After this operation, 1774 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 smartmontools amd64 6.5+svn4324-1 [464 kB]
Fetched 464 kB in 6s (80.5 kB/s)        
dpkg: error: corrupt info database format file '/var/lib/dpkg/info/format'
E: Sub-process /usr/bin/dpkg returned an error code (2)
root@ubuntu:~#

geole

Bonjour
Si ce boot était bien fait depuis la clé USB, il est préférable que tu achètes une clé de qualité et que tu réinstalles ubuntu sur la clé et que tu recommences la totalité de l'installation en la surveillant.

Psykopak

geole a écritBonjour
Si ce boot était bien fait depuis la clé USB, il est préférable que tu achètes une clé de qualité et que tu réinstalles ubuntu sur la clé et que tu recommences la totalité de l'installation en la surveillant.

Je ne suis pas sur la clé usb. Je retape ces deux commandes après avoir booter sur la clé ?

geole

Alors si tu étais mode chroot, on a une piste sur quelque chose de nouveau.

OUI.
Je te propose de faire la commande

shutdown

pour arrêter l'ordinateur et faire un boot standard avec le support d'installation
1) essayer ubuntu avant de l'installer
2) mettre le clavier en français
3) frapper les deux commandes
4) donner le retour de la seconde

NOTA: Voila ce qu'il devrait y avoir

cat /var/lib/dpkg/info/format
1

dans internets, ils proposent donc cette commande

sudo printf "1\n" > /var/lib/dpkg/info/format

Mais je crains que c'est masquer la cause du problème

« Page précédente Page suivante »