Presse-papier dans linux mint

Il semblerait que beaucoup de personne se plaigne de l'absence d'un presse-papier dans Linux Mint Cinnamon.

Pourtant il existe l'applet gpaste rechargé qui nécessite évidemment que soit installé gpaste. Le problème est que l'applet continue à réclamer sont installation alors que gpaste est déjà installé. 

En fait il faut installer aussi gir1.2-gpaste et puis ça fonctionne.

Comme Linux Mint est basé sur Ubuntu, dans Ubuntu Cinnamon, ça se règle de la même façon.

Pour Fedora Cinnamon, pas de gir1.2-gpaste, mais on essaie quand même.

Catastrophe: Cinnamon se plante dès l'instant où on insère l'applet gpaste rechargé dans le tableau de bord. On tombe alors dans un mode de secours, où la possibilité est offerte de désactiver les applets. On refuse. Dans le mode de secours, le tableau de bord a disparu. On peut cependant faire apparaître des menus dans la partie supérieure gauche de l'écran. Il est alors possible de se déconnecter. A la reconnexion, miracle: tout fonctionne:

Disque externe bootable legacy et uefi

J'ai un disque dur externe usb que j'ai formaté de manière à ce qu'il puisse booter aussi bien de manière traditionnelle (legacy)  que en mode uefi:

toto@aldebaran:~$ sudo fdisk -l /dev/sda

[sudo] Mot de passe de toto: 

Disque /dev/sda : 447,13 GiB, 480103981056 octets, 937703088 secteurs

Disk model: 80G2G0A-00JH30  

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 4096 octets

taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Type d'étiquette de disque : gpt

Identifiant de disque : 6B6A3B5A-81C8-479D-B261-B4733B4D0D70

Périphérique     Début       Fin  Secteurs Taille Type

/dev/sda1         2048      4095      2048     1M Amorçage BIOS

/dev/sda2         4096   2101247   2097152     1G Système EFI

/dev/sda3      2101248  18878463  16777216     8G Partition d'échange Linux

/dev/sda4     18878464 102764543  83886080    40G Système de fichiers Linux

/dev/sda5    102764544 186650623  83886080    40G Système de fichiers Linux

/dev/sda6    186650624 937701375 751050752 358,1G Système de fichiers Linux

michel@pc-linuxshop-A7K57UJU:~$ 

Grub s'installe dans sda1 dans le cas d'un amorçage en mode traditionnel, sda2 est monté dans /boot/efi pour un amorçage en mode UEFI.

J'ai installé un système linux (linux mint)  sur ce disque USB, à partir d'un laptop dont le boot est legacy.

Pas de souci lorsqu'il est branché sur un ordinateur qui s'amorce à l'ancienne. Par contre si ce disque dur externe est branché sur un ordinateur dont l'amorçage est UEFI, il n’apparaît pas dans la liste des périphériques sur les quels on peut booter.

Depuis un ordinateur UEFI où est installé Ubuntu (22.04), je lance les commandes suivantes:

sudo mount /dev/sda4 /mnt

sudo mount /dev/sda2 /mnt/boot/efi 

for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt/$i; done  

sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars

sudo chroot /mnt

grub-install 

update-grub

exit  

sudo umount /dev/sda2

sudo umount /dev/sda4

(/dev/sda4 contient la racine de linx mint avec lequel je veux démarrer mon disque USB.)

Mais déception: ça ne fonctionne pas.

Le disque possède le drapeau pmbr_boot, ce qui pose problème.

Il faut enlever ce drapeau:

toto@aldebaran:~$ sudo parted /dev/sda

(parted) disk_set pmbr_boot off

(parted) quit

Et voilà, le problème est résolu. 

Blscfg et Fedora

Fedora utilise par défaut BLSCFG (Boot Loader Specification Configuration) comme on peut le vérifier dans le fichier /etc/defaults/grub qui contient GRUB_ENABLE_BLSCFG=true. De ce fait /boot/grub2/grub.cfg ne contient aucune entrée menuentry pour Fedora, mais seulement des entrées pour les autres systèmes d'exploitation.

Par contre on y trouve: 

insmod

blscfg

La commande blscfg ajoute des entrées au menu en se basant sur le contenu du dossier /boot/loader/entries. Ici le dossier contient 4 fichiers:

[toto@fedora ~]$ sudo ls -1 /boot/loader/entries 

7753b84a2ac148e7894de73d56d9be39-0-rescue.conf

7753b84a2ac148e7894de73d56d9be39-6.4.11-200.fc38.x86_64.conf

7753b84a2ac148e7894de73d56d9be39-6.4.12-200.fc38.x86_64.conf

7753b84a2ac148e7894de73d56d9be39-6.4.9-200.fc38.x86_64.conf

J'examine le contenu d'un des fichiers:

[toto@fedora ~]$ sudo -i

[sudo] Mot de passe de toto : 

[root@fedora ~]# cd /boot/loader/entries

[root@fedora entries]# cat 7753b84a2ac148e7894de73d56d9be39-6.4.12-200.fc38.x86_64.conf 

title Fedora Linux (6.4.12-200.fc38.x86_64) 38 (Workstation Edition)

version 6.4.12-200.fc38.x86_64

linux /boot/vmlinuz-6.4.12-200.fc38.x86_64

initrd /boot/initramfs-6.4.12-200.fc38.x86_64.img

options root=UUID=a7465ac8-7427-4c7b-a2f4-3b6dcb9fcfae ro resume=UUID=f17ebeb2-0767-4f7c-ba74-5ba3ed6acb92 rhgb quiet 

grub_users $grub_users

grub_arg --unrestricted

grub_class fedora

[root@fedora entries]# 

Pour une raison ou une autre, je veux ne pas utiliser blscfg. Donc dans /etc/defaults/grub je mets:

GRUB_ENABLE_BLSCFG=false

Ensuite je regénère grub.cfg avec la commande

[toto@fedora ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Tout va bien jusqu'au prochain changement de noyau:

catastrophe: kernel panic

Il faut alors booter sur le noyau précédent pour réparer les dégâts. Si j’examine grub.cfg, je constate que dans la commande linux qui permet de booter sur le nouveau noyau se trouve:

root=/dev/sdb5 (dans mon cas) au lieu de root=UUID=.....

Pour régler le problème, il suffit de régénérer grub.cfg comme précédemment. Il n'est même pas nécessaire de rebooter: on peut procéder dès que l'update est terminé.