Notes › _DIFFUSION

Cette conversation a été générée avec Duck.ai (https://duck.ai) à l’aide du modèle GPT-5.6 Luna d’OpenAI. Les chats IA peuvent afficher des informations inexactes ou offensantes (voir https://duckduckgo.com/duckai/privacy-terms pour en savoir plus).

====================

Message 1 sur 5 de l’utilisateur - 18/09/2026 16:26:56:

cachyos boot est corrompu J'ai booté sur un live, monté la partition /dev/sda1 sur /boot et passé en chroot omment régénérer le boot

Si tu as monté /dev/sda1 directement sur /boot, ta partition EFI est probablement déjà au bon endroit pour CachyOS. Il faut d’abord identifier le bootloader utilisé : GRUB, systemd-boot ou Limine.

Depuis le live, vérifie d’abord le mode de démarrage :

ls /sys/firmware/efi

Si le dossier existe, le live a démarré en UEFI. Sinon, redémarre le live en choisissant l’entrée UEFI: ... dans le firmware.

1. Monter correctement le système

Remplace /dev/sda2 par ta partition racine si nécessaire :

mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot

mount --rbind /dev  /mnt/dev
mount --make-rslave /mnt/dev
mount --rbind /proc /mnt/proc
mount --make-rslave /mnt/proc
mount --rbind /sys  /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /run  /mnt/run
mount --make-rslave /mnt/run

chroot /mnt /bin/bash

Si ton système est en Btrfs avec des sous-volumes CachyOS, il faut monter le sous-volume racine, par exemple :

mount -o subvol=@ /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot

Vérifie ensuite :

ls /boot

Tu devrais voir notamment vmlinuz... et des fichiers initramfs....

2. Régénérer le noyau et les initramfs

Dans le chroot :

pacman -Syu linux-cachyos mkinitcpio
mkinitcpio -P

Si tu utilises plusieurs noyaux, réinstalle-les également, par exemple :

pacman -S linux-cachyos linux-cachyos-lts
mkinitcpio -P

3. Réinstaller le bootloader

Cas A — systemd-boot

C’est le cas fréquent si /boot est directement la partition EFI :

bootctl --path=/boot install

Puis régénère les entrées CachyOS :

sdboot-manage gen

Si sdboot-manage n’existe pas :

mkinitcpio -P

Contrôle :

bootctl status
ls -l /boot/EFI
ls -l /boot/loader/entries

Cas B — GRUB

Si tu as /boot/grub/grub.cfg ou si tu sais que GRUB était utilisé :

pacman -S grub efibootmgr
grub-install \
  --target=x86_64-efi \
  --efi-directory=/boot \
  --bootloader-id=CachyOS \
  --recheck
grub-mkconfig -o /boot/grub/grub.cfg

Pour un système en mode BIOS/Legacy, la commande est différente :

grub-install --target=i386-pc /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

Ne mets pas /dev/sda1 dans la commande BIOS : il faut utiliser le disque entier, /dev/sda.

Cas C — Limine

Si tu avais Limine :

pacman -S limine
limine-install
limine-mkinitcpio

4. Régénérer les entrées EFI et redémarrer

Pour vérifier que l’entrée EFI existe :

efibootmgr -v

Puis quitte et démonte proprement :

exit
umount -R /mnt
reboot

Retire la clé USB au redémarrage.

La combinaison la plus probable dans ton cas est :

bootctl --path=/boot install
mkinitcpio -P
sdboot-manage gen

Si tu vois plutôt un dossier /boot/grub, utilise la procédure GRUB. Les commandes officielles CachyOS distinguent bien GRUB, systemd-boot et Limine, et indiquent bootctl install pour systemd-boot et grub-install pour GRUB. [1]

Message 2 sur 5 de l’utilisateur - 18/09/2026 16:32:03:

EFI ? [root@CachyOS /]# ls /boot initramfs-linux-cachyos-lts.img intel-ucode.img vmlinuz-linux-cachyos initramfs-linux-cachyos.img loader vmlinuz-linux-cachyos-lts Oui : le contenu de `/boot` indique très probablement que **systemd-boot** est utilisé, car tu as un dossier `loader/` et aucun dossier `grub/`.

Vérifie que /boot est bien la partition EFI :

findmnt /boot
ls -la /boot
ls -la /boot/EFI

Si /boot correspond bien à /dev/sda1, reste dans le chroot et exécute :

pacman -Syu systemd linux-cachyos linux-cachyos-lts
mkinitcpio -P
bootctl --path=/boot install

Puis vérifie les entrées :

ls -la /boot/loader
ls -la /boot/loader/entries
bootctl status

Tu devrais avoir au moins un fichier dans :

/boot/loader/entries/

Sur CachyOS, régénère ensuite les entrées avec :

sdboot-manage gen

Si la commande n’existe pas :

pacman -Ss sdboot

et installe le paquet correspondant, ou régénère simplement les initramfs avec :

mkinitcpio -P

Vérifie également que le firmware EFI possède une entrée de démarrage :

efibootmgr -v

Si bootctl install renvoie une erreur indiquant que le système n’est pas démarré en EFI, quitte le chroot et redémarre le live en choisissant explicitement l’entrée UEFI de la clé USB. Tu peux le vérifier avec :

ls /sys/firmware/efi

Enfin :

exit
umount -R /mnt
reboot

Dans ton cas, les commandes essentielles sont probablement :

mkinitcpio -P
bootctl --path=/boot install
sdboot-manage gen

Ne lance pas grub-install : rien dans le contenu affiché ne suggère que GRUB est utilisé.

Message 3 sur 5 de l’utilisateur - 18/09/2026 16:32:45:

[root@CachyOS /]# findmnt /boot ls -la /boot ls -la /boot/EFI TARGET SOURCE FSTYPE OPTIONS /boot /dev/sda1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shor total 107548 drwxr-xr-x 3 root root 4096 Jan 1 1970 . dr-xr-xr-x 18 root root 4096 Sep 18 16:30 .. -rwxr-xr-x 1 root root 30146125 Sep 18 15:09 initramfs-linux-cachyos-lts.img -rwxr-xr-x 1 root root 29975017 Sep 18 15:09 initramfs-linux-cachyos.img -rwxr-xr-x 1 root root 15265792 Aug 13 00:04 intel-ucode.img drwxr-xr-x 4 root root 4096 Sep 18 15:10 loader -rwxr-xr-x 1 root root 16994304 Aug 15 18:28 vmlinuz-linux-cachyos -rwxr-xr-x 1 root root 17728000 Aug 11 15:38 vmlinuz-linux-cachyos-lts ls: cannot access '/boot/EFI': No such file or directory

C’est cohérent : /dev/sda1 est bien ta partition EFI, montée sur /boot, et la présence de /boot/loader confirme l’utilisation de systemd-boot.

Le dossier /boot/EFI n’est pas obligatoire. Il sera recréé par bootctl install si nécessaire.

Dans le chroot, exécute :

bootctl --path=/boot install

Puis régénère les initramfs :

mkinitcpio -P

Affiche ensuite les entrées systemd-boot :

find /boot/loader -maxdepth 2 -type f -print -exec sed -n '1,12p' {} \;

Tu devrais normalement voir un ou plusieurs fichiers dans :

/boot/loader/entries/

Régénère les entrées CachyOS :

sdboot-manage gen

Si sdboot-manage n’existe pas, affiche le contenu actuel :

find /boot/loader -type f -maxdepth 3 -print

et vérifie l’installation EFI :

bootctl status
efibootmgr -v

Après cela :

exit
umount -R /mnt
reboot

Si bootctl --path=/boot install affiche une erreur concernant les variables EFI, vérifie depuis le chroot :

ls /sys/firmware/efi/efivars

Si ce dossier n’existe pas ou est vide, le live a été démarré en mode Legacy/BIOS. Il faut redémarrer la clé USB en choisissant son entrée UEFI, puis refaire le montage et le chroot.

Message 4 sur 5 de l’utilisateur - 18/09/2026 16:35:20:

[root@CachyOS /]# bootctl --path=/boot install Running in a chroot, enabling --graceful. Created directory "/boot/EFI". Created directory "/boot/EFI/systemd". Created directory "/boot/EFI/BOOT". Created directory "/boot/loader". Created directory "/boot/loader/keys". Created directory "/boot/loader". Created directory "/boot/loader/entries". Created directory "/boot/EFI". Created directory "/boot/EFI/Linux". Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi". Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI". ⚠️ Mount point '/boot' which backs the random seed file is world accessible, which is a security hole! ⚠️ ⚠️ Random seed file '/boot/loader/random-seed' is world accessible, which is a security hole! ⚠️ Random seed file /boot/loader/random-seed successfully refreshed (32 bytes). Not booted with EFI or running in a container, skipping EFI variable modifications. [root@CachyOS /]# mkinitcpio -P ==> Building image from preset: /etc/mkinitcpio.d/linux-cachyos-lts.preset: 'default' ==> Using default configuration file: '/etc/mkinitcpio.conf' -> -k /boot/vmlinuz-linux-cachyos-lts -g /boot/initramfs-linux-cachyos-lts.img ==> Starting build: '6.18.42-1-cachyos-lts' -> Running build hook: [base] -> Running build hook: [systemd] -> Running build hook: [autodetect] -> Running build hook: [microcode] -> Running build hook: [kms] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [keyboard] -> Running build hook: [sd-vconsole] -> Running build hook: [plymouth] -> Running build hook: [sd-encrypt] ==> WARNING: Possibly missing firmware for module: 'qat_6xxx' -> Running build hook: [filesystems] -> Running build hook: [fsck] ==> Generating module dependencies ==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-cachyos-lts.img' -> Early uncompressed CPIO image generation successful ==> Initcpio image generation successful ==> Building image from preset: /etc/mkinitcpio.d/linux-cachyos.preset: 'default' ==> Using default configuration file: '/etc/mkinitcpio.conf' -> -k /boot/vmlinuz-linux-cachyos -g /boot/initramfs-linux-cachyos.img ==> ERROR: Invalid option -g -- '/boot/initramfs-linux-cachyos.img' must be writable

systemd-boot a bien été réinstallé. Le message concernant l’absence d’EFI signifie seulement qu’il n’a pas pu créer/modifier l’entrée NVRAM depuis le chroot ; le fichier de secours /boot/EFI/BOOT/BOOTX64.EFI a tout de même été installé.

L’erreur restante concerne uniquement l’image initramfs du noyau principal :

/boot/initramfs-linux-cachyos.img must be writable

Vérifie d’abord l’espace disponible et les attributs du fichier :

df -h /boot
stat /boot/initramfs-linux-cachyos.img
ls -l /boot/initramfs-linux-cachyos.img

Puis supprime uniquement cette image et recrée-la :

rm -f /boot/initramfs-linux-cachyos.img
mkinitcpio -p linux-cachyos

Si cela fonctionne, vérifie les deux images :

ls -lh /boot/*initramfs*

Tu dois obtenir notamment :

/boot/initramfs-linux-cachyos.img
/boot/initramfs-linux-cachyos-lts.img

Le warning :

Possibly missing firmware for module: 'qat_6xxx'

n’est généralement pas bloquant ; il concerne le firmware d’un module matériel Intel QAT et peut être ignoré si tu n’utilises pas ce matériel.

Ensuite, vérifie les entrées systemd-boot :

find /boot/loader -type f -maxdepth 3 -print
bootctl --path=/boot status

Si sdboot-manage est disponible :

sdboot-manage gen

Enfin, comme ton live n’a pas été démarré en mode EFI, démarre-le à nouveau en mode UEFI, remonte le système, puis exécute éventuellement :

bootctl --path=/boot install
efibootmgr -v

Cela créera l’entrée NVRAM CachyOS. Toutefois, comme BOOTX64.EFI existe maintenant, le firmware peut souvent démarrer directement même sans cette entrée.

Message 5 sur 5 de l’utilisateur - 18/09/2026 16:36:53:

[root@CachyOS /]# rm -f /boot/initramfs-linux-cachyos.img mkinitcpio -p linux-cachyos rm: cannot remove '/boot/initramfs-linux-cachyos.img': Read-only file system ==> Building image from preset: /etc/mkinitcpio.d/linux-cachyos.preset: 'default' ==> Using default configuration file: '/etc/mkinitcpio.conf' -> -k /boot/vmlinuz-linux-cachyos -g /boot/initramfs-linux-cachyos.img ==> ERROR: Invalid option -g -- '/boot/initramfs-linux-cachyos.img' must be writable

La partition EFI est maintenant remontée en lecture seule. C’est la cause de l’échec. Le système de fichiers FAT a probablement détecté une erreur et s’est protégé.

Dans le chroot, vérifie :

findmnt /boot
mount | grep ' /boot '

Essaie d’abord de la remonter en lecture-écriture :

mount -o remount,rw /boot
findmnt /boot

Si elle apparaît bien en rw, recrée l’image :

rm -f /boot/initramfs-linux-cachyos.img
mkinitcpio -p linux-cachyos

Si le remount échoue ou si /boot repasse immédiatement en ro, il faut réparer la partition FAT avec fsck.fat. Il faut d’abord sortir du chroot et démonter /boot :

exit
umount /mnt/boot
fsck.fat -av /dev/sda1

Réponds y aux corrections proposées. Si fsck.fat n’existe pas dans le live :

pacman -S dosfstools

Puis remonte et retourne dans le chroot :

mount /dev/sda1 /mnt/boot
chroot /mnt /bin/bash

Vérifie que la partition est en écriture :

findmnt /boot
touch /boot/test-ecriture
rm /boot/test-ecriture

Puis régénère :

mkinitcpio -P

Tu peux contrôler l’état du système de fichiers avant réparation avec :

fsck.fat -n /dev/sda1

Ne lance pas fsck.fat tant que /dev/sda1 est montée. Le warning qat_6xxx n’est pas la cause du problème ; le vrai problème est bien le passage de /boot en lecture seule.