Vous n'êtes pas identifié(e).
Pages : 1
Firmware Bug
TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later) En attente de résolution.
Apparemment bug mineur... https://archived.forum.manjaro.org/t/em … ed/46069/7
Problème Boot win OK Boot lub impossible :
dependency failed for local filesystem Le mode restauration (seconde ligne de grub) est lui aussi défaillant...impossible de naviguer dans le menu de restauration,
Un lien qui parle de ntp serveur de temps, why not
https://unix.stackexchange.com/question … ing-debian
Manjaro ( images manquantes sur la page web)
https://archived.forum.manjaro.org/t/em … iled/46069
What I did was the long way around: sudo nano /etc/fstab. Change the line with your /home to have a 0 at the end instead of the 1 or 2. This will make it skip the fsck check at boot. Reboot into the OS. Run sudo fsck /dev/<home partition> and press yes to fix all errors. sudo nano /etc/fstab aga…
Un lien plus pertinent:
https://www.debian-fr.org/t/resolu-aie- … iled/75847
Contribution de PascalHambourg en particulier
grep “Dependency failed” /var/log/*.logVérification effectuées
Vérif fstab et blkid faite en chrootant...depuis live, Vérif arrêt complet de win 10
Depuis win10 gestion des disques
1/ Disque 0 partition 1 500 Mo récupération (en fait vide !!)
2/ Disque 0 partition 2 100 Mo EFI EFI{Boot Microsoft ubuntu}
3/ C Win 10
4/ Disque 0 partition 5 534 Mo récupération (Recovery/WindowsRE)
5/ Disque 0 partition 6 Lubuntu 18.04 avec home
6/ E: Data ntfs
7/ Disque 0 partition 8 data linux
PC livré avc WIN 10 Part win redimensionnée pour faire de la place à lubuntu
Lubuntu installé sans swap...et home non séparé.
Tout a bien fonctionné jusqu'à ce bug...
Il faudrait savoir précisément comment l' installeur Ubuntu voit les différentes partitions win.
Ou même gparted...
Le souci de dépendances (dependancy failed) est bien souvent un problème de partitions, soit qui se chevauchent, et donc créent la confusion dans la table de partitions et le système qui cherche des données qu'il ne trouve plus, l'une (comme un swap ou un home) disparaissant brusquement, ce qui fait que le boot devient impossible pour le système linux (lubuntu).
Nota: La vérif de disque depuis disk ( disques) sous ubuntu ne sait pas réparer les erreurs de fichiers ntfs.
Le fait de travailler sur de vieux disques peut être aussi générateur d' erreurs...
L'idéal est quand on peut, d'écrire des 0 et des 1 sur tout le DD, et de réinstaller proprement...
Redémarrage. Touche F12
USB Key: General
Sata 1 ST500DM002-1BD142 Windows Boot Manager / Ubuntu (donne accès à grub) /
Entrée 3 dans F12: Ubuntu non fonctionnel===> (Invalid signature deteted. Check Secure Boot Policy in Setup)
re tentative mode recovery non fonctionnel. CTRL+Alt+ Supp passe directement sur clé usb multisystem, mais
error: Secure Boot forbids loading module from (hd0,msdos1)/boot/grub/x86_64-efi/loopback.MOD.
error: no server is specified. unaligned ointer 0xc4ffb048 Aborted. Press any key to exit
Désactiver secure boot dans le bios EFI Réglages Bios:
Si CSM désactivé, c'est UEFI qui s'affiche en dessous sans possibilité de modifier. Cette option boote windows directement sans passer par grub.
CSM activé (permet de choisir la ligne du dessous: mode d'amorçage automatique/UEFI/ancien.
Mode Ancien ==> Ne fonctionne pas vu qu'Ubuntu est installé en mode UEFI (utilise la partition UEFI (ici sda2)
Mode UEFI ==> Boot direct sur win
Mode Automatique si validé, un nouveau choix apparaît en dessous= Priorité d'amorçage: ancien d' abord, et UEFI d'abord
ce choix fait, ancien d'abord boote encore sous win
le menu de grub semble perdu...
Redémarrer depuis win para récupération options avancées modifier param UEFI .
Vu que réglages UEFI d'abord ou pas ne changent rien, modifier d'autres options du BIOS
Avancé ligne deux Configuration de l' UC param optimisés: tout est activé par défaut, Ligne 4 Intet Smart Connect ==> désactivé!
EIST Speed Step Tech ajuste dyna tension et fréquence du proc activé ===> Désactivé !
Intel HT ==> x proc logiques d'un même coeur partagent les ressources ==> Désactivé !
Multitraitement des coeurs
Tech de virt ==> Désactivé !
Support C1E
Reboot Touche F12 Menu périph de dém sata 1 ==> Legacy et UEFI Windows Boot manager
Legacy ==> Reboote win
UEFI ==> idem
autres options du BIOS: Périphériques
Périph Unité ATA/ configurer SATA en mode [AHCI] ou [IDE]
autres options du BIOS: Sécurité
avant dernière ligne: Amorçage sécurisé désactivé (par défaut ?) ==> Le réactiver ?Oui ==> Sans effet sur grub !.
Réinitialiser le mode de configuration (fait passer le mode sécurisé en mode de conf ???
Contenu de grub.cfg ds ubuntu dans EFI
search.fs_uuid 984967d5- fef7-4d05-8ff3-851accdb56ac root hd0,gpt6
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg Ceci ne nous aide pas bcp.
Chrooter à nouveau: tenter de réparer grub:
sudo update-grub
sudo impossible de résoudre l' hôte ubuntu: Ressource temporairement non disponible ? le sudo est inutile puisque on est déjà root (#)
grub-install /dev/sda Installation pour la plateforme x86_64-efi erreur impossible de trouver le répertoire EFI La commande ci dessus ne fonctionne que pour des installations NON EFI !!
https://www.malekal.com/grub-reparer-du … uis_Ubuntu
Tester depuis le chroot: sans garantie quele retour soit bon !!
efibootmgr permet de manipuler les entrées du démarrage d'un BIOS UEFI. Pour lister les entrées de démarrage :
efibootmgr -v
BootCurrent: 0010
Timeout: 0 seconds
BootOrder: 000C,000D,000F,000E,0000,0001,000B,0010,0005,0004
Boot0000* Windows Boot Manager HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...1................
Boot0001* ubuntu HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0004* Generic Usb Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0005* CD/DVD Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot000B* ubuntu HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\Ubuntu\grubx64.efi)
Boot000C* HL-DT-ST DVD-RAM GHC0N BBS(CDROM,,0x0)..BO
Boot000D* ST500DM002-1BD142 BBS(HD,,0x0)..BO
Boot000E* Realtek PXE B02 D00 BBS(Network,,0x0)..BO
Boot000F* General BBS(HD,,0x0)..BO
Boot0010* UEFI: General PciRoot(0x0)/Pci(0x1a,0x0)/USB(1,0)/USB(2,0)/HD(1,MBR,0x3fb1f,0x800,0xef1000)..BO
root@ubuntu:/#
BootCurrent: 0010 UEFI: General PciRoot(0x0)/Pci(0x1a,0x0)/USB(1,0)/USB(2,0), cela ressemble bien à notre clé usb !! /HD(1,MBR,0x3fb1f,0x800,0xef1000)..BO
Or nous avons booté sur la clé multisystem avec F12 et lancé la clé en mode général et pas efi. La commande nous retourne peut être cet état de fait.
BootOrder: 000C,000D,000F,000E,0000,0001,000B,0010,0005,0004
00C correspond au boot DVD-RAM
00D ==> Disque dur ST500DM002
00F General BBS ??
00E Carte réseau...
Cet ordre ressemble bien par contre à celui qui a été configuré dansle "Bios EFI"
On peut indiquer l'ordre de démarrage par numéro
efibootmgr -o + numéro
efibootmgr -o 000x Mais nous avons deux entrées ubuntu !!
Boot0001* ubuntu HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\ubuntu\shimx64.efi)
et
Boot000B* ubuntu HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\Ubuntu\grubx64.efi)
la seule différence entre ces deux entrées est la suivante \shimx64.efi et \grubx64.efi ?
Cherchons avec leur UUID c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000
blkid donne pour sda2 (EFI) c79d02b0-bef6-4220-9941-9f341bf3bd17
Le chroot nous permet bien de modifier le système ciblé à réparer !
Le dossier EFI\ubuntu\ contient bien les deux fichiers shimx64.efi ET grubx64.efi
Mais alors lequel placer en premier ? Boot001 (shim) ou Boot000B (grub)...
Apparemment shim est lié à secure boot, grub est sans doute bien préférable SAUF si secure boot est activé !
https://www.gnu.org/software/grub/manua … -shim.html
The GRUB, except the chainloader command, works with the UEFI secure boot and the shim. This functionality is provided by the shim_lock verifier. It is built into the core.img and is registered if the UEFI secure boot is enabled.
https://askubuntu.com/questions/342365/ … nd-shimx64
Typically, EFI/ubuntu/grubx64.efi on the EFI System Partition (ESP) is the GRUB binary, and EFI/ubuntu/shimx64.efi is the binary for shim. The latter is a relatively simple program that provides a way to boot on a computer with Secure Boot active. On such a computer, an unsigned version of GRUB won't launch, and signing GRUB with Microsoft's keys is impossible, so shim bridges the gap and adds its own security tools that parallel those of Secure Boot. In practice, shim registers itself with the firmware and then launches a program called grubx64.efi in the directory from which it was launched, so on a computer without Secure Boot (such as a Mac), launching shimx64.efi is just like launching grubx64.efi. On a computer with Secure Boot active, launching shimx64.efi should result in GRUB starting up, whereas launching grubx64.efi directly probably won't work.
Action:
/# efibootmgr -o 000B,000D,0010,0004
BootCurrent: 0010
Timeout: 0 seconds
BootOrder: 000B,000D,0010,0004
Boot0000* Windows Boot Manager
Boot0001* ubuntu
Boot0004* Generic Usb Device
Boot0005* CD/DVD Device
Boot000B* ubuntu
Boot000C* HL-DT-ST DVD-RAM GHC0N
Boot000D* ST500DM002-1BD142
Boot000E* Realtek PXE B02 D00
Boot000F* General
Boot0010* UEFI: GeneralAu reboot le menu de grub est bien revenu, mais pas windows ( pas ajouté ci-dessus).
par contre l'erreur initiale est toujours présente Dependency failed for Local File Systems...
Il semble que le système se plaigne du manque de la partition data linux (qui ne contient pourtant pas home) !! ??
Même solution éditer fstab, commenter la ligne incriminée avec #
Message d'erreur ?
E325: ATTENTION
Found a swap file by the name "/etc/.fstab.swp"
owned by: root dated: Tue Aug 17 11:39:45 2021
file name: /etc/fstab
modified: YES
user name: root host name: ubuntu
process ID: 6230 (still running)
While opening file "/etc/fstab"
dated: Tue Aug 17 11:41:55 2021
NEWER than swap file!
(1) Another program may be editing the same file. If this is the case,
be careful not to end up with two different instances of the same
file when making changes. Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r /etc/fstab"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file "/etc/.fstab.swp"
to avoid this message.
"/etc/fstab" 21 lines, 1029 characters efibootmgr -v
BootCurrent: 000E
Timeout: 0 seconds
BootOrder: 000E,000B,000D,0012,000F,0010,0001,0013,0005,0004,0011
Boot0001* ubuntu HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0004* Generic Usb Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0005* CD/DVD Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot000B* ubuntu HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\Ubuntu\grubx64.efi)
Boot000C* HL-DT-ST DVD-RAM GHC0N BBS(CDROM,,0x0)..BO
Boot000D* ST500DM002-1BD142 BBS(HD,,0x0)..BO
Boot000E* HL-DT-ST DVD-RAM GHC0N BBS(CDROM,,0x0)..BO
Boot000F* Realtek PXE B02 D00 BBS(Network,,0x0)..BO
Boot0010* Windows Boot Manager HD(2,GPT,c79d02b0-bef6-4220-9941-9f341bf3bd17,0xfa000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0011* CD/DVD Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0012* General BBS(HD,,0x0)..BO
Boot0013* UEFI: General PciRoot(0x0)/Pci(0x1a,0x0)/USB(1,0)/USB(1,0)/HD(1,MBR,0x3fb1f,0x800,0xef1000)..BO
Nouvel ordre
root@ubuntu:/# efibootmgr -o 000B,0010,0013
Solutionné
A/ Le boot
Démarrage touche F12 ==> Legacy ==>grub ou
ou bien F12 ==>UEFI ==> Win
B/ Le démarrage Lubuntu
c'est de toute évidence la modification de fstab qui permet à présent à Lub de démarrer.
Le fstab contenait une entreé swap alors que pas de swap dans les partitions...
Le fstab contenait deux points de montage avec UUID inconnus et bien que les débuts de ligne commencent par # (donc en principe inactives), le fait que ces lignes comprennent le chemin /mnt/dossier_truc UUID à nouveau a pu perturber le système, car je ne sais pas si des commande sont interprétées au sein d'une ligne de commentaire, à priori ce serait fort possible.
Au reboot, le mode recovery est à présent pleinement fonctionnel. 334 Mo de mises à jour...
Hors ligne
Pages : 1