GRUB ne démarre pas de manière persistante - "hd0,4 introuvable"
J'essaie de créer un lecteur flash USB persistant d'Ubuntu 17.04 avec mkusb (dus). J'ai suivi explicitement les instructions sur le site Web mkusb et j'ai essayé la plupart des variantes auxquelles je peux penser, toutes sans joie. Lorsque je sélectionne la clé USB persistante dans le BIOS, grub s’amorce à partir de cette clé; Je choisis Ubuntu persistant; grub objets avec hd0,4 non trouvé. Je cherche une solution en ligne depuis plusieurs jours.
Certaines des choses que j'ai essayées: - Créer le lecteur persistant sur un deuxième lecteur flash alors qu'il était démarré à partir d'un lecteur flash USB en direct; - Toutes les combinaisons du mode hérité du BIOS et de l’amorçage sécurisé sont activées et désactivées; - les tables de partitions msdos et gpt sur le lecteur cible; - différents lecteurs flash; - différentes quantités de mémoire persistante; - etc.
Toutes les suggestions seront grandement appréciées.
Mon système: ordinateur portable HP avec quad core AMD64, 16 Go de mémoire, démarrage (généralement) en mode sécurisé UEFI. Le BIOS est le dernier. Le système d'exploitation installé est Ubuntu 17.04.
Merci!! -Garenne
Modifier # 1 pour ajouter:
Après une enquête plus poussée, il semble que grub se charge depuis le lecteur flash en tant que hd2, et non hd0. Ceci est probablement dû au fait que les deux disques durs internes sont découverts en premier par le BIOS et qu’ils sont reconnus comme étant hd0 et hd1. Comment obtenir grub sur un lecteur flash persistant pour reconnaître qu’il a été chargé à partir de hd2 et non hd0 est actuellement au-dessus de ma classe salariale.
Modifier # 2 à ajouter:
@ sudodus- merci pour l'aide. Certaines des informations demandées:
Les composants mkusb et dus sont tous chargés à partir du ppa et sont en version 12.0.9. Le BIOS a le mode hérité désactivé et l’amorçage sécurisé activé. J'ai essayé d'éditer les commandes grub ("e") et de changer hd0 en hd2. Ça marche! Le lecteur flash persistant démarre comme prévu. (Je me demande pourquoi grub ne se contente pas de définir root sur le disque sur lequel il a été chargé ...?)
Sortie des commandes--
warren@warren-laptop:~$ Sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT NAME SIZE OWNER GROUP MODE
sda sda 953.9G root disk brw-rw----
├─sda1 vfat 1168-7BED /boot/efi ├─sda1 256M root disk brw-rw----
├─sda2 ext4 182d8f07-567e-4514-9f99-49b78767f195 / ├─sda2 921.6G root disk brw-rw----
└─sda3 swap 8187044e-0939-4868-b81a-b5bc64bd9e7c [SWAP] └─sda3 32G root disk brw-rw----
sdb sdb 698.7G root disk brw-rw----
└─sdb1 ext4 devel 27a0c109-82be-4ceb-b572-dedbeb412744 /home/warren/devel └─sdb1 698.6G root disk brw-rw----
sdc sdc 14.5G root disk brw-rw----
├─sdc1 ntfs usbdata 134E2DAF76E6A9A4 /media/warren/usbdata ├─sdc1 3.2G root disk brw-rw----
├─sdc2 ├─sdc2 1M root disk brw-rw----
├─sdc3 vfat usbboot 2EA6-44A9 ├─sdc3 122M root disk brw-rw----
├─sdc4 iso9660 Ubuntu 17.04 AMD64 2017-04-12-03-44-04-00 /media/warren/Ubuntu 17.04 AMD64 ├─sdc4 1.5G root disk brw-rw----
└─sdc5 ext4 casper-rw 8a27c645-3e5c-4e7f-bf92-eb51dc0bd19f /media/warren/casper-rw └─sdc5 9.6G root disk brw-rw----
warren@warren-laptop:~$ Sudo parted -ls
Model: ATA SanDisk SD8SB8U1 (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 269MB 268MB fat32 efi boot, esp
2 269MB 990GB 990GB ext4
3 990GB 1024GB 34.4GB linux-swap(v1)
Model: ATA ST750LX003-1AC15 (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 16.8MB 750GB 750GB ext4 devel
Model: Patriot Memory (scsi)
Disk /dev/sdc: 15.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
2 1049kB 2097kB 1049kB primary bios_grub
3 2097kB 130MB 128MB fat32 primary boot, esp
4 130MB 1759MB 1629MB primary
5 1759MB 12.1GB 10.3GB ext2 primary
1 12.1GB 15.5GB 3436MB ntfs primary msftdata
warren@warren-laptop:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 7776108 0 7776108 0% /dev
tmpfs 1559788 10204 1549584 1% /run
/dev/sda2 951092244 187079792 715676736 21% /
tmpfs 7798928 12 7798916 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 7798928 0 7798928 0% /sys/fs/cgroup
/dev/sda1 258095 3496 254599 2% /boot/efi
/dev/sdb1 720011344 242201684 441165412 36% /home/warren/devel
tmpfs 1559784 168 1559616 1% /run/user/1000
/dev/sdc4 1571328 1571328 0 100% /media/warren/Ubuntu 17.04 AMD64
/dev/sdc1 3355644 17388 3338256 1% /media/warren/usbdata
/dev/sdc5 9909328 36912 9352660 1% /media/warren/casper-rw
warren@warren-laptop:~$
Merci!!
Essayer de trouver un correctif général
Normalement, l'ordinateur identifiera le lecteur de démarrage comme étant hd0, mais ce n'est pas le cas sur votre ordinateur. Je vais essayer de trouver un moyen de résoudre ce problème. J'ai testé avec Lubuntu 17.04 dans mon ordinateur portable Toshiba en mode UEFI et ne pouvais pas reproduire le bogue. J'aurai donc besoin de votre aide pour tester le correctif que je peux trouver.
Edit : J'ai modifié le shellscript dus-persistent de mkusb et téléchargé la nouvelle version 12.1.1 au PPA instable. Les principales améliorations concernent un changement de la structure de démarrage d'Ubuntu 17.04 et le fait que votre ordinateur ne démarre pas à partir de hd0. La principale différence concerne l’identification de la partition n ° 4 avec l’image du fichier iso (le système de fichiers iso9660),
search --set=root --fs-uuid <the-UUID-of-partition-no-4>
et cela se fait automatiquement par mkusb-dus. S'il vous plaît tester si cela résout le problème! Vous obtenez la nouvelle version en fonction de ce lien,
help.ubuntu.com/community/mkusb/gui#from_the_unstable_PPA
La version unstable est toujours développée et déboguée. Il est disponible à partir de ppa:mkusb/unstable via les lignes de commande suivantes.
Sudo add-apt-repository universe # this line only for standard Ubuntu
Sudo add-apt-repository ppa:mkusb/unstable
Sudo apt-get update
Sudo apt-get install mkusb # install
# Sudo apt-get dist-upgrade # upgrade to current version (with all other upgrades), only for installed systems
Sudo apt-get install mkusb guidus dus mkusb-common
# upgrade all mkusb basic components including dus
# for persistent live drives that work in UEFI and BIOS mode with 32-bit iso files, add
Sudo apt-get install usb-pack-efi
Solution de contournement - correction de bug dans votre cas
Merci pour les commentaires (que vous avez modifiés dans la question initiale). Cela facilite l’aide.
"J'ai essayé de modifier les commandes grub (" e ") et de changer
hd0enhd2. Cela fonctionne! Le lecteur flash persistant démarre comme prévu. (Je me demande pourquoi grub ne définit pas uniquement la racine il a été chargé depuis ...? "
Je suggérerais de modifier le fichier grub.cfg dans la partition n ° 3 de la clé USB 'persistante' (la partition 'usbboot'). Cela devrait rendre le bug persistant dans votre clé USB. Mais cela ne fonctionnerait pas sur d'autres ordinateurs, qui se comportent comme mes ordinateurs.
$ ls -l /media/lubuntu/usbboot/boot/grub/grub.cfg
-rw-r--r-- 1 lubuntu lubuntu 1312 Apr 29 06:31 /media/lubuntu/usbboot/boot/grub/grub.cfg
grub.cfg a le contenu suivant, dans lequel vous modifiez hd0,4 en hd2,4. (Vous pouvez également modifier hd0,3 en hd2,3, mais Memtest86 + ne fonctionnera de toute façon pas en mode UEFI.)
Dans votre cas, vous pouvez vous attendre à "Ubuntu" au lieu de "Lubuntu", mais sinon, le résultat serait le même.
set timeout=10
set default=0
menuentry "Lubuntu-17.04-desktop-AMD64.iso - persistent live" {
set root=(hd0,4)
linux ($root)/casper/vmlinuz.efi boot=casper quiet splash persistent --
initrd ($root)/casper/initrd.lz
}
menuentry "Lubuntu-17.04-desktop-AMD64.iso - persistent live to RAM" {
set root=(hd0,4)
linux ($root)/casper/vmlinuz.efi boot=casper quiet splash toram persistent --
initrd ($root)/casper/initrd.lz
}
menuentry "Lubuntu-17.04-desktop-AMD64.iso - live" {
set root=(hd0,4)
linux ($root)/casper/vmlinuz.efi boot=casper quiet splash --
initrd ($root)/casper/initrd.lz
}
menuentry "Lubuntu-17.04-desktop-AMD64.iso - recovery mode" {
set root=(hd0,4)
linux ($root)/casper/vmlinuz.efi boot=casper ro recovery nomodeset
initrd ($root)/casper/initrd.lz
}
submenu "Memory test" {
menuentry "Memtest86+ works in BIOS alias CSM mode, but not in efi (UEFI) mode"{
echo "${grub_platform} mode; (memtest86+ does not work with efi (UEFI) mode)"
}
menuentry "Memtest86+ 4.20" {
set root=(hd0,3)
echo "${grub_platform} mode; (memtest86+ does not work with efi (UEFI) mode)"
linux16 /boot/memtest/memtest.bin
}
menuentry "Memtest86+-5.01" {
set root=(hd0,3)
echo "${grub_platform} mode; (memtest86+ does not work with efi (UEFI) mode)"
linux16 /boot/memtest/memtest86+-5.01.bin
}
}
Alternative
Une autre solution consiste à copier les entrées de menu de grub.cfg et à en modifier l’une pour disposer de deux alternatives permettant au lecteur flash USB de démarrer facilement sur différents ordinateurs.
...
menuentry "Ubuntu-17.04-desktop-AMD64.iso - persistent live (hd2,4)" {
set root=(hd2,4)
linux ($root)/casper/vmlinuz.efi boot=casper quiet splash persistent --
initrd ($root)/casper/initrd.lz
}
menuentry "Ubuntu-17.04-desktop-AMD64.iso - persistent live (hd0,4)" {
set root=(hd0,4)
linux ($root)/casper/vmlinuz.efi boot=casper quiet splash persistent --
initrd ($root)/casper/initrd.lz
}
...
En supposant que vous démarrez avec grub (mode UEFI) et non syslinux (mode hérité), vous pouvez simplement modifier les commandes grub à partir de l’écran du menu grub en tapant "e", puis en utilisant les touches fléchées pour passer à hd0 et le changer en hd2. . Instructions en bas de l’écran de menu, contrôlez X ou F10 pour démarrer.
Si les modifications fonctionnent, essayez de les modifier dans le fichier grub.cfg. Sudodus a raison, update-grub ne fonctionnera pas dans ce cas.
Je vais laisser la discussion sur mkusb au sudodus, je devenais confus en regardant une très vieille clé USB créée par une version plus ancienne.