récupérer l'espace non alloué sur une clé usb bootable

[donalduck]

bonjour,

j'ai (au moins) une clé usb qui m'a servi a installer linux mint avec énormement d'espace libre - apparement non formaté - que j'aimerais bien récupérer.

problème gparted me dis que toute la clé est occupée quand gisk (gnome-disk) y voit une partition libre d'environ 14 Go !!!
en ligne de commande j'ai par ailleurs:

Code: Select all

/dev/sdc1             1,9G  1,9G     0 100% /media/nahan/Linux Mint 19.1 MATE 32-bit

qui a raison ? est-ce que je peux utiliser disk sans risques pour formater l'espace libre et garder toujours une clé bootable ?

[Laurent85]

est-ce que je peux utiliser disk sans risques pour formater l'espace libre et garder toujours une clé bootable ?

Disk va retourner une erreur, c'est lié au format de l'image iso sur la clé usb. Si tu as Windows crée ta clé usb LM avec Rufus https://rufus.ie, il va créer une clé usb bootable avec tout l'espace en FAT32.

[jjcojax]

Bonjour,

Autre options ...

Avec Unetbootin (au départ de Win comme de Linux)

Compter l'espace nécessaire pour pouvoir mettre l'image du fichier .iso et le fichier de persistance " casper-rw " (fichier que linux considère comme une partition EXT2) (casper-rw ne peut pas dépasser les 4 GB puisque c'est un fichier sur du FAT32)

Faire une première partition de par ex. de 6.3 GB (si 4 GB de persistance) et laisser le reste inoccupé (attention que Win7 ne reconnaît que la 1ere partition d'une clé USB)(Win10 voit mieux )

Faire sa clé comme comme il le propose dans la partition 1

pareil avec Live-usb-install

Quand la clé fonctionne, depuis Linux, il est possible le faire d'autres partitions sur l'espace libre de la clé.
----
et, à partir d'un PC récent, (type UEFI) il existe mkusb -> demande à google "mkusb guidus"

Le mode d'emploi le plus facile à lire me semble être celui - ci -> http://www.wubijacq.com/rwd/mkusb-guidu ... idus/1.png

Moi je l'ai fais sur une clé de 32 GB -> vue

Un vieux PC vois en début de disque ce qui ressemble à une table de partition (image grub) et peut accéder à la partition /dev/sdb1 (en NTFS)
Un PC UEFI retrouve une partition EFI sur /dev/sdb3 et peut donc démarrer en mode efi
La partition casper-rw est en EXT4 (pas de limite à 4 GB)
Le reste de la clé est en NTFS

Au démarrage, on peut choisir de démarrer en mode live (le fichier .iso) ou en mode avec persistance.

Si on fait une bêtise et casse le démarrage en mode persistance, le mode live reste accessible (le mode qui utilise l'image d'un DVD d'install)

Quand la clé d'install est faite, elle permet d'installer une version 64 bits sur un PC UEFI (après 2013) et/ou BIOS (avant 2013)

jjcojax

[donalduck]

vu laurent merci pour le conseil, du coup je vais sans doute en profiter pour préparer une clé avec la distrib 19.2
je me rappelle aujourd'hui pourquoi je n'avais pas utilisé rufus pour cette clé: en effet il faut opérer sur un poste windows avec une connection au reseau des reseaux, ce que je n'ai pas sous la main. Pour une raison X ou Y rufus requiert le telechargement de fichiers syslinux très récents au moment du "gravage".
Ca va rallonger la manoeuvre dans mon cas ...

jjcojax je viens de voir ton commentaire; ça m'a l'air bien compliqué surtout que je me fiche de la persistance ou que la clé soit lisible par windows,
(pour moi il s'agit juste de pouvoir stocker quelques gros fichiers a coté de la distrib linux live sans que ça la gene), mais je vais y réfléchir. Par ailleurs le multiboot peut m'interesser si c'est possible et facile a faire.

[donalduck]

bon finalement j'ai pu faire facilement la gravure de cette clé avec rufus hors-ligne, il suffisait de copier les fichiers syslinux-6.03 du repertoire rufus_files que j'avais toujours dans un coin de l'ordi lors d'une precedente manip avec rufus "portable".

mais il y a un hic lorsque je boote avec cette clé sur l'ordi cible, l'ecran de l'ordi s'eteint apres quelques secondes, apparement au chargement de l'initram (et il ne se passe plus rien même apres plusieurs minutes).

j'ai essayé plusieurs ports usb c'est pareil, pourtant la clé avec 19.1 MATE fonctionnait bien.

seul le mode de compatibilité semble fonctionner mais c'est loin d'etre satisfaisant (la resolution de l'ecran qui est selectionnée est mauvaise !!!).

PS: j'avais bien sur vérifié l'image iso, puis aussi noté que la gravure avec rufus s'etait déroulé sans erreurs, puis aussi testé avec succès l'integrité de la clé (dans le menu de la distrib live) et aussi démarrer avec succès la distrib live sur un autre ordi. la clé usb n'est donc pas le probleme.

le noyau retenu pour cette distrib live 4.15.0-54 ne semble pas non plus en cause, car j'ai utilisé ce noyau sur l'ordi cible pendant presque un mois.

j'ai l'impression qu'il y a plutot un souci au niveau des firmwares sélectionnés pour le live, mais comment diagnostiquer vraiment ce probleme ?
je me vois mal faire une installation a partir du mode de compatibilité

[Laurent85]

Tu devrais obtenir le même comportement de la cle usb crée avec Rufus ou l'outil classique https://linuxmint-installation-guide.re ... /burn.html
C'est pas le cas ?

[donalduck]

C'est pas le cas ?

euh je n'en sais rien il faudrait que je prepare une autre clé. ce que je sais c'est que je n'avais pas de pb avec cette clé qui fonctionnait avant avec linux mint 19.1 mate. La nouvelle clé rufus+mate 19.2 fonctionne aussi tres bien sur un autre ordi.
par contre sur l'ordi que je cible (fonctionnant actuellement bien avec mate 19.1) visiblement il y a un pb lié à l'ecran et/ou au chipset video integré (Intel 4 Series Integrated Graphics vendor: Gigabyte driver: i915).
j'oubliais j'ai aussi essayé avec l'option nomodeset a la place de quiet splash, ça fonctionne mais la resolution chosie est mauvaise comme dans le mode de compatibilité 1600*1200 au lieu de 1920*1080.

les messages d'erreurs semblent assez explicites dans Xorg.log:

Code: Select all

[    26.441] (EE) open /dev/dri/card0: No such file or directory
[    26.441] (EE) open /dev/dri/card0: No such file or directory
[    26.456] (EE) open /dev/fb0: No such file or directory
[    26.456] (EE) open /dev/fb0: No such file or directory
[    26.456] (EE) Screen 0 deleted because of no matching config section.
[    26.456] (EE) Screen 0 deleted because of no matching config section.
[    26.592] (EE) AIGLX: reverting to software rendering

rem la derniere erreur s'est aussi produite dans le mode de compatibilité.

est-ce que je dois ajouter/mettre a jour le firmware et les pilotes qui vont bien lors de la session live avant d'installer sur le disque ?

[Laurent85]

Il y a peut-être un paramètre de démarrage à ajouter. Ceux par défaut fonctionnent mal avec "ce" pc.
C'est quoi le retour de :

Code: Select all

inxi -Fxxz

[donalduck]

peut-être un paramètre de démarrage à ajouter

ça serait genial ! mais je pense que le pb est plus profond et vient du choix des paquets dans la distrib live.

en comparant avec dpkg les paquets sur le pc mate 19.1 qui fonctionne bien et sur le pc avec le live mate 19.2,
j'ai constaté qu'il manquait intel-microcode dans la distrib Tina live
et il y a par ailleurs des paquets en plus sur le live notamment i965-va-driver:i386

sinon voici le resumé inxi pour d'une part le pc 19.1 et d'autre part le live 19.2 qui tourne cahin-caha

Code: Select all

Graphics:  Device-1: Intel 4 Series Integrated Graphics vendor: Gigabyte driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2e32 
           Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa compositor: marco v: 1.20.1 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel G41 x86/MMX/SSE2 v: 2.1 Mesa 18.2.8 direct render: Yes 

Code: Select all

System:    Host: mint Kernel: 4.15.0-54-generic i686 bits: 32 compiler: gcc v: 7.4.0 Desktop: MATE 1.22.0 info: mate-panel 
           wm: marco 1.22.2 dm: LightDM 1.26.0 Distro: Linux Mint 19.2 Tina base: Ubuntu 18.04 bionic 
Graphics:  Device-1: Intel 4 Series Integrated Graphics vendor: Gigabyte driver: N/A bus ID: 00:02.0 chip ID: 8086:2e32 
           Display: x11 server: X.Org 1.19.6 driver: vesa unloaded: fbdev,modesetting compositor: marco v: 1.22.2 
           resolution: 1600x1200~N/A 
           OpenGL: renderer: llvmpipe (LLVM 8.0 128 bits) v: 3.3 Mesa 19.0.2 compat-v: 3.1 direct render: Yes 

tout semble pointer vers un pb de pilote i915 qui manque a l'appel.

[Laurent85]

j'ai constaté qu'il manquait intel-microcode dans la distrib Tina live

C'est pas lié au souci en tout cas.

tout semble pointer vers un pb de pilote i915 qui manque a l'appel.

Il est disponible et pas chargé, pourquoi ? vérifie :

Code: Select all

lspci -nnk| grep -i -A3 vga
sudo modprobe -v i915
journalctl -b | grep -i -e vga -e i915 -e cmdline

Donne les logs de Xorg :

Code: Select all

cat /var/log/Xorg.0.log

[donalduck]

la commande sudo modprobe de provoque apparemment rien, ni code ou message d'erreur ni changement des options de display.

quand aux autres voici dans l'ordre le resultat de lspci, journactl et Xorg.0.log

Code: Select all

00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e32] (rev 03)
	Subsystem: Gigabyte Technology Co., Ltd 4 Series Chipset Integrated Graphics Controller [1458:d000]
	Kernel modules: i915
00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 01)

Code: Select all

Nov 18 17:37:12 mint kernel: Console: colour VGA+ 80x25
Nov 18 17:37:12 mint kernel: pci 0000:00:02.0: vgaarb: setting as boot VGA device
Nov 18 17:37:12 mint kernel: pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
Nov 18 17:37:12 mint kernel: pci 0000:00:02.0: vgaarb: bridge control possible
Nov 18 17:37:12 mint kernel: vgaarb: loaded
Nov 18 17:41:54 mint sudo[2449]:     mint : TTY=pts/0 ; PWD=/home/mint ; USER=root ; COMMAND=/sbin/modprobe -v i915

mate192-Xorg.log.gz

(9.46 KiB) Downloaded 32 times

ps: je l'ai zipé c'etait trop gros comme attachment.

[Laurent85]

Il y a rien dans les logs, il faudrait démarrer sans nomodeset et comme sans ça démarre pas. L'iso n'est pas modifiable ça limite les possibilités de solution pour une utilisation en Live.

Sans nomodeset ni quiet splash il y a un message à l'écran ?

[donalduck]

Il y a rien dans les logs, il faudrait démarrer sans nomodeset et comme sans ça démarre pas

effectivement c'est le coeur de problème, pas de logs, pas vraiment moyen de s'avoir ce qui se passe

Sans nomodeset ni quiet splash il y a un message à l'écran

en mode normal ou "automatique" il y a un prompt clignotant pendant environ 5 secondes en haut a gauche puis l'affichage bascule
(ça se traduit chez moi par une notification "auto adjust" en bas a droite du moniteur)
ensuite l’écran reste noir (mais pas éteint) et visiblement le pc n'a plus d'activité.
au bout de dix minutes j'ai essayé de basculer sur une session console: pas de réaction.
par contre la séquence magic sysrq [Alt]+[ImprEcran]+B a bien provoqué le reboot de la machine,
ça semble indiquer que le chargement du système est bien allé jusqu'a un point assez avancé.

finalement je crois bien que je vais rester avec Tessa 19.1 le plus longtemps possible
et abandonner l'idée d'upgrade 19.2 disfonctionnel dès le départ pour ma config...

dans tous les cas merci pour ton aide, je crois qu'il faut mieux cloturer le sujet on commence à s'écarter du pb original

ps: au fait j'ai le même résultat avec mintstick l'outil de création de clé usb intégré a Mint,
sauf que contrairement a rufus il ne laisse pas d'espace libre dans la clé,
ça confirme le fait que j'avais bien crée la première clé avec cet outil. Ce serait bien d'améliorer ça à l'avenir !

[wubijacq]

Je voudrais signaler que mon site a perdu son www. (voir le lien plus haut)
C' est pour le tuto à https://wubijacq.com/rwd/mkusb-guidus.php
Ma clé USB contenant Ubuntu Budgie 64bit créée avec Mkusb, quand je choisis l' option Live arec persistance elle ne démarre pas sur un de mes ordi. Cela provient probablement de NVidia. Avec Ubuntu Budgie 32 bit elle démarre sans aucun problème avec cette option de boot.