Sommaire
- Le téléchargement d'un Windows 10…
- Copier l'ISO sur une clé USB
- Copier l'ISO sur une clé USB, bis
- Inversons l'ordre d'installation
- Retentative d'installation de Windows
- Rufus, projet libre indispensable…
- Conclusion pathétique à un triste journal
Bonjour bonjour
Aujourd'hui, mauvaise surprise : un ami se pointe avec un ordinateur portable «reconditionné» acheté à son travail, donc disque vierge de tout OS, et me demande d'y installer Windows, éventuellement Linux en dual boot… Bon. Ça me gonfle d'avoir une installation de Windows à faire, mais soit, je suis (trop) gentil, je devrais vraiment pas accepter ça mais j'accepte.
Puis c'est pas très compliqué : on télécharge l'ISO, on la copie sur clé USB avec dd, et le tour est joué…
Le téléchargement d'un Windows 10…
Microsoft, au moins jusqu'à Windows 10, mais probablement pareil pour le 11, ne fournit pas d'ISO hybride. C'est une ISO de CD à graver absolument sur DVD ou BD, ce n'est pas une table de partitions valide pour une clé USB. Donc vous pouvez faire dd, mais derrière le BIOS/UEFI va refuser le truc, méchamment.
C'est un piège connu, mais comme un bleu, je suis tombé dedans. (Et ça m'a pris quelques reboot)
Note : première copie de 5GB en USB…
Copier l'ISO sur une clé USB
Bon ben je formate ma clé USB, en FAT32, et je copie dedans les fichiers de l'ISO Windows préalablement montée.
Ha ben non, y'a un fichier de plus de 4GB pour l'installation, ça ne passe pas en FAT32.
Note : deuxième copie de 5GB en USB…
Copier l'ISO sur une clé USB, bis
Je formate ma clé USB en NTFS, je copie les fichiers de l'ISO.
Voilà, là ça devrait être enfin bon, non ?
Non
Du tout. Ça boote pas, le firmware n'affiche aucun message d'erreur, c'est comme si la clé était vide.
Note : troisième copie de 5GB en USB…
Inversons l'ordre d'installation
Puisque l'installeur Windows ne démarre pas pour une raison inconnue, autant installer d'abord un Linux pour que j'ai des éléments de diagnostic et d'analyse de la situation.
Là évidemment, pas grand chose à signaler (à part qu'une installation de Kubuntu par défaut sort des snap pour des applis comme Firefox, ce qui est horripilant et accroit considérablement le temps de démarrage de Firefox). Je laisse volontairement une partition vierge que je formaterai et monterai en NTFS après coup pour y copier l'ISO windows (gain de temps par rapport à l'USB).
Note : cette fois c'est seulement 3.5GB (wow ça a pris du poids ubuntu) copiés en USB
Retentative d'installation de Windows
Bon, j'ai un linux, efibootmgr, de quoi télécharger et déposer des fichiers localement. C'est plus confortable, ça devrait devenir facile.
Je tente de rajouter une entrée pointant vers la partition, avec le bot fichier .efi à booter. Échec, nada, quedal.
Je copie dans la partition ESP (/boot/efi) les fichiers efi et le dossier boot de l'ISO windows. Ça devrait lancer l'installeur et me permettre de lui dire où sont ses petits, non ?
Non ?
Non.
«Disque corrompu, fichiers introuvables»
Merci.
Je gromelle, je tape du poing sur la table, je mets un bandage sur ma main, et je me dis «bon, ben on va tenter le shell EFI»
Téléchargement depuis https://github.com/tianocore/edk2/releases, copie dans /boot/efi, ajout d'une entrée de boot pour ça, redémarrage…
Hoo, il ne voit que la partition /boot/efi, les autres sont vues mais pas «montées».
Listons les pilotes avec la commande EFI drivers :
Mais… il n'y a que FAT ? Pas NTFS, pas ISO, pas UDF… ??
Ben non.
Du coup, si on veut booter l'installation de Windows sur une telle machine, comment est-on supposé faire ?
Rufus, projet libre indispensable…
C'est là qu'arrive un projet libre indispensable, https://rufus.ie/en/ (et ses projets liés)
C'est avant tout un utilitaire Windows pour écrire des ISOs sur des CD/DVD/BD/clé USB, mais avec quelques options très intéressantes comme «permettre de démarrer l'installeur Windows même si l'UEFI ne gère pas NTFS».
Ce qui m'arrange moins, c'est que c'est un utilitaire Windows, donc je vais devoir prendre les différents éléments utiles et les déposer dans le /boot/efi du Linux.
Les éléments en question sont :
- UEFI:NTFS : un bootloader (une application UEFI quoi) qui va chercher le pilote NTFS, une partition NTFS et démarrer l'exécutable /efi/boot/boot$arch.efi dedans
- un port de ntfs-3g en EFI OU un port des systèmes de fichiers de grub
Quoi ? Comment ça «OU» ? Apprenons une puputerie de Microsoft à l'occasion : pour valider secure boot, il faut que tous les composants soient signés. Et la signature de Microsoft est la seule reconnue dans tous les UEFI. Donc il faut demander (poliment) à Microsoft de signer l'exécutable. Or… a priori Microsoft refuse de signer des exécutables sous licence GPL3. Du coup, vous pouvez utiliser le pilote ntfs.efi derivé de ntfs-3g en licence GPL2, ou utiliser un ntfs.efi dérivé de Grub, en GPL3, donc qui ne peut être signé par Microsoft.
Bref. Je pose les bons fichiers, je démarre le shell EFI, je lance uefi:ntfs… Et alleluia, l'installeur Windows démarre !
Conclusion pathétique à un triste journal
L'installation de Windows est en plusieurs étapes, avec quelques redémarrages. S'ils veulent après tout, tant que ça marche… Au deuxième ou troisième redémarrage, j'ai été accueilli par un merveilleux écran Windows pour la création de compte, avec comme titre :
«Bienvenue chez $CORP
Pour vous authentifier, veuillez saisir votre adresse mail @$CORP.COM»
Voilà. Le reconditionnement d'un PC pro, c'est pas juste formater le disque, c'est aussi supprimer des variables EFI qui me sont inconnues ! Ou des éléments dans la puce TPM qui sait…
Ayant pris la machine en choppé une grippe, j'ai pas regardé encore comment rattraper ça. Mais le prochain que j'entends me dire qu'installer Linux ou même FreeBSD c'est compliqué, je lui fais manger un clavier.
# Outil de création de clé USB
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Microsoft ne fournit Windows sous forme d’iso DVD mais fournit aussi un outil pour transformer l’iso en clé USB bootable. Mais pour cela il te faut déjà un Windows en plus de l’iso et de la clé USB.
Ce que tu peux faire c’est d’installer un Windows avec l’iso dans une machine virtuelle, une fois ceci fait, tu montes la clé USB dans la machine virtuelle, tu utilises l’outil qui va formater et préparer la clé USB, et voilà ! Tu as une clé USB d’installation de Windows. C’est chiant mais ça marche. Et une fois que tu as fait cette clé USB d’installation Windows, tu la copie avec
dd
quelque part pour pouvoir faire d’autres clés si besoin avecdd
à nouveau, (et ça, ça marche bien) !Mais sinon, à propos d’UEFI, je ne comprend pas pourquoi par défaut l’installation UEFI n’est pas portable (sans modifier une mémoire sur la carte-mère ou je-sais-pas-quoi) c’est super chiant et une énorme régression à mes yeux. Maintenant j’installe mes Linux avec l’option
--removable
degrub-install
, car si une machine tombe en panne, je veux pouvoir déplacer les disques dans la machine d’à côté et booter sans autre configuration.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Outil de création de clé USB
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 3.
Avec 2 clefs USB tu aurais pu t'en sortir, une en fat32 ou tu copies le répertoire boot et tout ce qui est UEFI, et l'autre en NTFS où tu copies l'intégralité de l'iso. Tu bootes sur celle en fat32 et une fois l'environnement de démarrage chargé tu échanges les clefs
# Je ne me casse plus les pieds
Posté par Laurent Mouillart . Évalué à 10.
J'utilise Ventoy avec des ISO d'arch, fedora, opensuse, windows, sur une clé USB de 64Go y a de quoi faire même si on la blinde d'ISO.
Je boot sur arch je nettoie tout : les partitions, l'efi…
Puis je redémarre et j’installe l'OS que je veux.
[^] # Re: Je ne me casse plus les pieds
Posté par Xavier Teyssier (site web personnel) . Évalué à 10.
J'approuve. Fonctionne aussi avec des ISO FreeBSD ou Proxmox.
Voilà des mois que je me dis qu'il faudrait que je ponde une petite news Ventoy pour Linuxfr, pour permettre à ce produit d'être un peu plus connu…
[^] # Re: Je ne me casse plus les pieds
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 3.
J'ai un PC portable Lenovo qui ne veut absolument pas booter avec une clé USB Ventoy, mais fonctionne avec une clé Ubuntu ou Debian.
Il faut dire qu'il a aussi un petit trou sur le côté pour mettre un trombone et accéder au démarrage car la touche F12 (?) ne fonctionne pas à tous les coups…
Je n'ai jamais essayé d'installer Windows dessus, mais ça devrait être folklorique, semble-t-il.
[^] # Re: Je ne me casse plus les pieds
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
Ah ?
J'ai installé une dizaine de portables Lenovo sans soucis, avec du Windows (10) ou du Linux (Fedora), et toujours avec Ventoy.
Par contre, me souviens plus si j'ai dû désactiver le secure boot dans le BIOS comme proposé par quelqu'un en dessous. Pas exclu.
[^] # Re: Je ne me casse plus les pieds
Posté par Laurent Mouillart . Évalué à 2.
Il y a différente façon de faire une clé ventoy : BIOS, EFI avec secureboot on/off, partitions MBR/GPT. Peut-être que le démarrage proposé n'était pas le bon.
# plouf plouf
Posté par pipo_molo . Évalué à 4.
pour booter l'iso sur une clé usb :
https://www.msnloop.com/installer-windows-10-cle-usb-uefi-wim-4-go/
pour la création de compte, il suffit de ne pas brancher la machine au réseau
[^] # Re: plouf plouf
Posté par Pinaraf . Évalué à 4.
La machine se considère encore comme appartenant à l'entreprise. Donc là c'est juste pas une option, une machine reconditionnée n'est pas supposée vouloir rejoindre le domaine de son ancienne entreprise.
[^] # Re: plouf plouf
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 2.
Il me semble plutôt que c'est lié à autopilot, et effectivement en faisant le premier démarrage sans réseau ça devrait fonctionner.
[^] # Re: plouf plouf
Posté par Stinouff . Évalué à 4.
Sur Windows 11, j'ai été surpris…d'être obligé de me connecter au réseau sur la version "Home".
L'interface ne propose plus de se connecter plus tard ou de dire "Je n'ai pas Internet". Un contournement est possible en bidouillant un peu (soit par l'interpréteur de commandes, soit peut-être par le gestionnaire de tâches), mais j'ai failli y laisser des plumes.
# Linuxiens unissez vous via une base de donnée UEFI !
Posté par eastwind☯ . Évalué à 10. Dernière modification le 21 juin 2022 à 21:43.
J'ai eu le même problème avec des ordinateurs à reconditionné de marque Lenovo , j'avais évoqué dans le journal présentant la dernière version d'Emmabuntus (voir mon commentaire en dessous du journal )
et j'avais suggeré qu'étant donné que la communauté Emmabuntus (j'utilise cette distro dans certain reconditionnement) devait faire pas mal de reconditionnement , d'avoir une base de données pour ne pas perdre l'expérience à propos de l'UEFI sur les différents configurations qu'ils ont recontré :
https://linuxfr.org/news/une-nouvelle-mise-jour-de-la-cle-usb-de-reemploi-emmabuntus
Bon après j'ai pas eu beaucoup de retour du coup le problème reste le même hélas.
Sinon les efforts vont resté dupliqués ce qui n'est pas très efficaces et à terme démotive pour faire passer du Linux (ce qui est le but de l'UEFI et du soi disant "Trusting computing" en général )
[^] # Re: Linuxiens unissez vous via une base de donnée UEFI !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
Avec ce journal, c'est plus démotivant pour du windaube
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Linuxiens unissez vous via une base de donnée UEFI !
Posté par FDF (site web personnel) . Évalué à 5.
Pour rester dans du construit, argumenté et syntaxiquement neutre, on pourrait ajouter.
Les utilisateurs de Linux ne veulent pas aller sur Windows, donc le problème ne se présente pas et l’influence de UEFI est bien donc dans un seul sens.
[^] # Re: Linuxiens unissez vous via une base de donnée UEFI !
Posté par freem . Évalué à 4.
Ben, et BSD alors? /me ->[]
[^] # Re: Linuxiens unissez vous via une base de donnée UEFI !
Posté par eastwind☯ . Évalué à 3. Dernière modification le 23 juin 2022 à 09:35.
tout à fait quid de tous les autres systèmes d'exploitation alternatifs ?
(ex: ReactOS, Haiku, Visopsys, MikeOS, KolibriOS, SkyOS, AmigaOS, AROS, MorphOS, BeOS…. )
# Si c’est de l’UEFI
Posté par PR . Évalué à 3.
Tu dois pouvoir triturer les données.
Le kernel linux monte un pseudo-système de fichier pour lire et écrire les données UEFI.
The module will be called efivarfs.
Avec un peu de chance ton noyau a le module, à activer donc.
Ensuite regarde du côté de paquets du style
efivar
ou plus généralement tout ce qui contient efi. Tu devrais pouvoir explorer un peu tout ça pour confirmer ton hypothèse.C’est ce que j’ai fait pour enregistrer le noyau linux direct dans l’UEFI : aucun bootloader requis, ma carte mère démarre direct le binaire du kernel qui se trouve sur une partition fat32.
Si une signature est requise, ce n’est ni de la faute à UEFI, ni celle de Microsoft. C’est la carte mère qui implémente UEFI ; c’est le fabriquant de la carte mère à qui il faut s’en prendre. Point.
Après, en fonction du domaine d’activité de l’entreprise, ce serait pas déconnant non plus de mettre en place certaines sécurités sur le matos…
Mort aux cons !
[^] # Re: Si c’est de l’UEFI
Posté par Pinaraf . Évalué à 5.
C'est hélas pas parce que tu as la liste des variables que tu sais laquelle doit être écrasée pour retirer l'association entre la machine et son ancien propriétaire… Elles n'ont pas de nom évident en tout cas, et un strings sur les valeurs n'a rien donné pour le moment.
# Désolé mais non
Posté par gUI (Mastodon) . Évalué à 10.
Je crie à tous vents que "on n'est jamais trop gentils". Dans la vie on peut être trop naïfs, trop influençables ou trop timides certes, mais la gentillesse, elle, n'a pas de limites.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Oui mais non
Posté par AlexTérieur . Évalué à 8. Dernière modification le 21 juin 2022 à 22:26.
On peut tromper 1000 fois une personne, mais on peut tromper une fois mille personnes… raaah zuuut…
[^] # Re: Oui mais non
Posté par FantastIX . Évalué à 1.
Un chewing-gum?
# ou sinon woeusb
Posté par solsTiCe (site web personnel) . Évalué à 6.
il y a ventoy qui a déjà été mentionné
mais aussi woeusb-ng https://github.com/WoeUSB/WoeUSB-ng
Ca doit faire la même que rufus mais sous linux (en mieux ?)
[^] # Re: ou sinon woeusb
Posté par ElVirolo (site web personnel) . Évalué à 3.
Je confirme que, dans mon cas, WoeUSB-ng a toujours très bien fonctionné.
[^] # Re: ou sinon woeusb
Posté par chuchunain (site web personnel) . Évalué à 2.
Je plussoie, outil sous Linux parfait !
T'as le bonjour de JavaScript !
# joli message d'ubuntu
Posté par MicP . Évalué à 1. Dernière modification le 22 juin 2022 à 01:02.
Bonjour
Sur une machine (ThinkPad T450 reconditionné) démarrant en mode 'legacy' <=> pas en UEFI
et sur un disque partitionné en mode msdos <=> pas GPT
sur lequel était installé un système Windows 10 quand j'ai acheté la machine,
et auquel j'ai ajouté en multiboot un système debian,
j'essaye maintenant d'y ajouter un système Ubuntu 22.04 LTS.
Après avoir refusé le choix par défaut : partitionnement automatique,
je créé une partition formatée en ext4 pour mon futur système Ubuntu,
puis, après avoir confirmé le partitionnement, voilà le message qui s'affiche :
https://i.ibb.co/dMFB6JQ/Capture-d-cran-2022-06-10-01-43-20.png
Pas très rassurant, mais au lieu d'accepter le choix proposé par défaut qui est : Revenir en arrière
je clique sur le bouton Continuer.
L'installation s'est terminée sans aucun problème et le système Ubuntu fonctionne.
# au boulot l'IT
Posté par Arvil . Évalué à 10.
Nettoyer le pc de toutes les traces de l'ancienne boîte lors du reconditionnement c'est le boulot de L'IT, c'est sûr que pour nous forcer à installer 200
spywareslogiciels de protection et pour t'empêcher d'installer gimp sans autorisation administrateur là y'a du monde par contre.# Tout est dans la façon de présenter
Posté par Zenitram (site web personnel) . Évalué à -10.
Tiens, je me demandais ce que Microsoft avait encore fait… Et en fait, pas grand chose, c'est juste un désaccord entre 2 entités mais autant ne pas perdre d'occasion pour cracher sur une entité qu'on n'aime pas et défendre une autre qu'on aime, l'objectivité n'est pas une truc agréable…
On pourrait aussi dire que c'est une puputerie de Grub à l'occasion qui utilise une licence foireuse alors qu'ils auraient pu rester en GPLv2.
Ou alors juste qu'il y a un désaccord, et qu'une entité n'a aucun intérêt (rien à gagner) à se faire chier avec une licence qui peut se retourner contre elle (tout à perdre) et que donc on peut comprendre la position, alors que ton besoin pourrait être rempli si l'autre entité avait simplement gardé sa précédente licence pour répondre aux critères (elle a choisi de prioriser son dogmatisme sur simplifier ta vie, c'est son choix, elle est libre de le faire et l'a fait).
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
J'ajouterais que c'est normal qu'ils ne veuillent pas signer d'exécutable sous GPL-3, parce que ce serait aider à effectuer une violation de cette licence.
En effet, la GPL impose au distributeur du binaire de proposer aussi le code source, accompagné des « informations d'installation », c'est à dire de quoi permettre de le faire tourner, ce qui inclut explicitement les éventuelles clefs d'autorisations.
Si Microsoft acceptaient de signer un binaire sous GPL-3, celui qui distribuerait ce binaire serait bien incapable de fournir la clef de signature de Microsoft, et violerait donc la GPL-3. Microsoft sont parfaitement conscient de cela, et n'ont aucun intérêt à aider les gens à violer la GPL-3, ça risquerait de se retourner contre eux.
La GPL-3 a du sens, un logiciel qu'on peut modifier, mais qu'on n'a aucun moyen d'exécuter une fois modifié, c'est une restriction des libertés de l'utilisateur assez sévère pour qu'on puisse la juger critique et empêcher qu'elle se produise.
D'ailleurs, le fait que GRUB soit sous GPL-3 a bien porté du fruit : Microsoft ne peuvent pas le signer, mais ça a dû les motiver pour accepter de signer un chargeur minimaliste, le shim, qui permet de charger des binaires de GRUB signés par la distribution ou par l'utilisateur.
[^] # Re: Tout est dans la façon de présenter
Posté par freem . Évalué à 10.
D'ailleurs au final… c'est pas la faute d'UEFi ça. Il suffit de désactiver le secure boot, qui est certes une fonctionnalité d'UEFI mais le standard n'interdit pas, à ma connaissance, d'implémenter sa désactivation.
Par conséquent, plutôt que taper sur microsoft ou la norme UEFI, ne serait-il pas plus pertinent de taper sur le fournisseur de firmware, que ce journal ne fait même pas semblant de citer?
Parce que les firmware pourris, c'est pas une invention qui découle d'UEFI hein, qui n'a jamais eu de BIOS sur lesquels on galère a faire quoique ce soit?
D'ailleurs, l'histoire de nom de domaine de l'entreprise stocké dans UEFI, c'est encore un problème qui n'est pas la faute ni d'UEFI ni de microsoft, mais bien celui de l'entreprise, non citée, qui n'a pas fait son boulot (ou du presta qui a fait le ménage, pas plus cité). Et s'il est difficile de réinitialiser l'UEFI, c'est, encore, la faute du fournisseur du firmware.
Moi, j'aime bien UEFI.
Grâce à UEFI:
Oui, vraiment, moi j'aime UEFI.
La signature des noyaux et boot loaders? C'est une fonctionnalité dont je n'ai pas besoin perso. L'utilisateur final ici en a-t-il réellement besoin, d'ailleurs?
Si Windows le requiert, alors ça serait bien la leur seul tort pour le coup (et c'est discutable en plus).
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ça va plus loin, la certification « compatible Windows », ou un truc comme ça, implique, sur plate-forme PC, que le SecureBoot soit désactivable. En tout cas, c'était le cas il y a quelques années.
[^] # Re: Tout est dans la façon de présenter
Posté par freem . Évalué à 3.
Intéressant, je l'ignorais. Comme quoi… (d'un autre côté j'ignore beaucoup de choses sur UEFI, donc c'est pas surprenant)
[^] # Re: Tout est dans la façon de présenter
Posté par Pinaraf . Évalué à 7.
En vrac, ce que j'ai déjà eu comme horreurs sur de l'UEFI :
- UEFI 32 bits vs OS 64 bits. Une purge qui n'a pas été supportée avant un certain temps par Linux
- Implémentations complètement à la ramasse. Un BIOS buggué ça existait évidemment, mais avec un volume de code supérieur au noyau Linux, l'UEFI a nécessairement beaucoup plus de bugs possibles, et avec les mises à jour par les fabricants on est bien partis.
- La non conservation des variables à la mise à jour, en particulier des entrées de boot. À nouveau, ça dépend de l'implémentation (sur des Lenovo c'est les entrées de boot, sur mon PC perso c'est les flags du CPU comme l'activation de SVM), mais j'ai vu ça sur plus d'une machine, et donc si le grub n'est pas installé en «removable» (ce qui n'est pas par défaut sur Debian), tu l'as dans l'os. Si tu veux avoir plusieurs OS et choisir au boot d'ailleurs, tu l'as dans l'os aussi.
Quand on n'a jamais vu la lumière des autres firmwares, je peux comprendre l'attrait d'UEFI :) Mais si je pouvais avoir du OpenFirmware avec un Petitboot sur mon PC je ferais la transition immédiatement. (J'ai une machine ARM64/Petitboot à la maison, je suis ravi qu'ils aient fait ce choix plutôt qu'UEFI)
Windows 11 le requiert, Windows 10 le suggère cordialement.
Au passage, dans les pré-requis de Microsoft pour le matériel «Windows certified» depuis Windows 8 :
- UEFI x86/amd64 : Secure Boot doit être désactivable,
- UEFI arm : Secure Boot non désactivable.
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Pour aller dans le sens des défauts de l'UEFI :
[^] # Re: Tout est dans la façon de présenter
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 23 juin 2022 à 10:48.
Peux-tu définir ce que tu entends par "grosse manipulation"?
Il me semble que tous les firmares UEFI du marché vont scanner les disques attachés au démarrage de la machine pour chercher les partitions EFI disponibles. C'est comme ça qu'on boot sur une carte flash ou stick USB.
Du coup perdre l'information, ça ne te fait perdre que des trucs bénins comme le système sur lequel tu vas booter par défaut si tu en as plus d'un sur tes disques disponibles.
Je ne comprends même pas le titre de ce journal qui sous-entends que UEFI rend la tâche difficile aux linuxiens alors que c'est plutôt le contraire.
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6. Dernière modification le 23 juin 2022 à 11:31.
Démarrer depuis une clef USB, monter quelque part le système installé, y bind-monter
/dev
, et peut-être/proc
et/sys
, chrooter dedans et lancergrub-install /dev/sdX
pour rétablir l'entrée de démarrage.Ou alors, démarrer un GRUB depuis une clef USB, et l'utiliser pour chainloader celui du disque dur. Ou encore, démarrer un GRUB depuis une clef USB, puis l'utiliser pour démarrer manuellement le noyau Linux, l'initrd et les bonnes options pour lancer le système d'exploitation installé. Puis réinstaller GRUB pour rétablir l'entrée de démarrage..
En effet, mais c'est particulier. Intel se doutaient bien que, pour démarrer sur un support amovible, la carte mère n'aurait pas d'entrée de démarrage prédéfinie pour préciser le chemin de l'exécutable EFI à lancer. Du coup, le cas des périphériques amovibles est particulier : le firmware est censé y chercher un
/efi/boot/boot<arch>.efi
, donc le plus souvent un/efi/boot/bootx64.efi
.Pour un prériphérique non amovible, rien de tel. Le firmware affiche une entrée de démarrage s'il en a une, qui précise le fichier à exécuter. S'l n'y a pas d'entrée de démarrage enregistrée pour ton disque dur fixe, tu n'as pas d'option pour démarrer dessus, un point c'est tout.
Négatif. Perde l'information, par épuisement de la pile de la carte mère hors alimentation, ça rend le système impossible à démarrer sans passer par une étape de récupération. Je le sais, je l'ai expérimenté.
Je suis plutôt d'accord sur ce point. Mais ça ne m'empêche pas de voir de gros défauts à UEFI.
[^] # Re: Tout est dans la façon de présenter
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 23 juin 2022 à 12:10.
Hmmm, ça ne semble concerner que des implémentations très très mal foutues dans ce cas.
Sur mon thinkpad je peux supprimer un entrée EFI mais aussi en ajouter à la main depuis le firmware, et il me propose ce qu'il trouve de disponible.
Pour avoir une idée du mécanisme tu peux installer une VM dans virt-manager et choisir un firmware UEFI qui utilise tianocore à la place du bios. Installes ta distro favorite, reboote, appuie sur ESC pour arriver dans la gestion du boot manager UEFI, supprime l'entrée. Tu verras qu'il reconnait de toute manière tes partitions et il bootera quand même sur ta distro. Et si tu en as plusieurs sur le disque tu peux recréer des entrées à la popogne directement depuis le firmware. Ben là c'est sur du virtualisé donc il n'est pas question de pile mais les thinkpads et surement plein d'autres modèles fonctionnent pareil.
Un défaut d'une implémentation particulière n'en fait pas un défaut de spec.
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 23 juin 2022 à 12:41.
Ça, c'est top en effet.
Et comment devine-t-il qu'il est censé exécuter
/efi/debian/grubx64.efi
, au juste ? Il a une liste hardcodée de chemins connus pour être utilisés par les distributions majeures ? C'est le genre de truc pratique qu'on peut s'attendre à voir dans une implémentation libre, en effet, mais aucune chance de voir ça dans les implémentation des fabricants de cartes mères.Le fait que la configuration soit stockée dans une mémoire vive maintenue par l'alimentation électrique et une pile est un défaut d'implémentation, en effet. Le fait qu'un firmware UEFI ne soit censé aller chercher dans
/efi/boot/boot<arch>.efi
que pour les supports amovibles est un défaut de spec.[^] # Re: Tout est dans la façon de présenter
Posté par Frédéric Massot (site web personnel) . Évalué à 5.
Pour éviter ce problème, je créer un dossier "/efi/boot" et je copie tout le contenu du dossier "debian" dans le dossier "boot". Puis dans le dossier "boot", je copie le fichier "grubx64.efi" en "bootx64.efi".
De cette façon, le firmware UEFI trouve toujours un fichier "/efi/boot/bootx64.efi", qui est en fait Grub.
Sur un RAID logiciel, je fait cette manip sur tous les disques.
[^] # Re: Tout est dans la façon de présenter
Posté par Pinaraf . Évalué à 6.
Sur debian, tu peux gérer ça comme ça :
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ah, merci. Je viens de regarder, c'est une variable de debconf qui est utilisée dans le script de postinst du paquet grub-efi-amd64, et qui a pour effet de passer l'option
--force-extra-removable
àgrub-install
.[^] # Re: Tout est dans la façon de présenter
Posté par freem . Évalué à 2.
Je serais curieux de voir le source d'un firmware UEFI? Peut-être qu'il y a une implémentation libre qui te sers de référence ici?
Sinon, j'ai eu a traiter avec UBoot moi. Ben j'aurai préféré UEFI, et pourtant il y a bien moins de lignes de code que pour le noyau je pense (facile a vérifier, c'est libre dans les deux cas).
Je pense qu'à l'heure actuelle j'ai du avoir a traiter avec une 10aine de firmwares UEFI différents, de constructeurs aléatoires. J'ai aussi eu ma part, comme tout le monde ici, de BIOS. Et j'ai eu un cas de UBoot, aussi.
Du coup, avec mon expérience certes limitée (il en existe bien d'autres, j'en suis conscient) UEFI est loin d'être le pire.
Oui, certains été buggués, notamment celui de la CM mano842, mais ce n'était clairement pas des bugs d'UEFI (quand même pas la faute a UEFI si les types sont infoutus de faire une interface non-mensongère!). Et les gens avec qui j'ai traités (c'était pour le taf) étaient d'une compétence douteuse (plusieurs mois pour leur faire comprendre que leur système est buggué, photos et vidéos à l'appui, dans un cas j'ai même du leur envoyer les plans corrects pour faire les câbles dont nous avions besoin et qu'ils étaient censés nous fournir sans efforts de notre part).
Mais bon, pour moi, ce n'est pas UEFI le problème, ici.
UEFI, à la différence des firmwares non normés, permets (en théorie) de garantir un certain nombre de fonctionnalités sans avoir à se palucher la doc, en espérant que l'information soit écrite dedans, ce qui n'est pas garantit. Quand il y a une doc.
Merci de l'info.
[^] # Re: Tout est dans la façon de présenter
Posté par Pinaraf . Évalué à 6.
On pourrait avoir un long, long, très long débat sur ce sujet. «Doit-on imputer aux implémentations les conséquences d'une spécification trop complexe ?» vous avez 2H…
De mémoire, sur les trois couches de l'EFI, c'est la DXE qui fait la taille d'un noyau Linux (hors drivers, surtout quand on voit la taille des pilotes DRM), et quand on voit ce qu'elle doit implémenter de toute façon, c'est compréhensible.
Rappel sur les trois couches : en anglais, https://trmm.net/LinuxBoot_34c3/, sinon en résumé franchouillard d'un journal précédent
D'ailleurs pour rechercher des infos pour ce commentaire, je suis retombé sur ce qui est sûrement le meilleur bug d'UEFI qui ait existé : https://mjg59.dreamwidth.org/20187.html
[^] # Re: Tout est dans la façon de présenter
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tiens, OpenFirmware. J'ai dû y toucher une fois, ça m'a paru plus abscons que tout ce que j'avais pu voir. Mais c'est sans doute très bien, il faut juste s'y habituer parce que c'est très, très étrange.
# Même chose pour moi hier…
Posté par ttamttam . Évalué à 9.
Ça m’a pris 5 h avant de trouver la solution pour créer une clé USB d’installation de windows 10 qui fonctionne en UEFI (je sais, je suis lent !)…
La solution est bien décrite ici.
1/ Partitionner la clé en GPT ;
2/ Y créer une partition FAT32 ;
3/ Monter l’ISO sous Linux ;
4/ Tout copier sur la clé sauf le fameux fichier
sources/install.wim
dont la taille dépasse 4 Gio5/ Utiliser l’utilitaire
wimlib-imagex
(paquetwimtools
), et l’utiliser pour séparerinstall.wim
eninstall.swm
etinstall2.swm
. Copier ces deux fichiers sur la clé, danssources/
.OUF !
[^] # Re: Même chose pour moi hier…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Je ne vois pas d'étape visant à donner à la partition de la clef USB le type de partition système EFI, donc je dirais que tu as de la chance d'être tombé sur une carte mère qui va chercher de quoi démarrer dans une partition qui n'a pas ce type.
# Non
Posté par David Demelier (site web personnel) . Évalué à 6.
Si.
J'ai réinstallé Windows 11 sur mon ordi du travail suite à un changement de SSD et j'ai aussi une fois fait temporairement un dual boot sur mon thinkpad (Windows 10) et j'ai aucun lecteur CD. Et évidemment je l'ai fait avec un simple
dd
.D'ailleurs c'est écrit sur la page officielle que tu peux l'utiliser sur une clé USB.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Non
Posté par freem . Évalué à 2.
Et au pire rien n'empêche de se préparer une clé avec syslinux pour booter l'iso, si?
[^] # Re: Non
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Lancer un noyau, c'est bien, mais si le système que tu démarres a besoin de fichiers, ce qui est certainement le cas, et ne sait aller les chercher que sur un lecteur de disques optiques, ça n'ira pas bien loin.
Ça me rappelle Unetbootin, ça. De quoi transformer un live-CD en clef USB… si le système en question est prévu pour, sinon ça donnera juste un truc qui fera un kernel panic ou équivalent.
# Fichier trop gros
Posté par barmic 🦦 . Évalué à 6.
Tu peux simplement le découper, c'est documenté.
Et oui tu as accès à l'outillage sous linux : wimlib-imagex-split.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fichier trop gros
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Vous croyez que ça fait quelque chose de plus que
split(1)
, à part nommer les fichiers d'une façon particulière ?[^] # Re: Fichier trop gros
Posté par barmic 🦦 . Évalué à 3.
Je me suis posé la question mais je n'ai pas vérifié et je n'ai pas tenté le diable quand j'en ai eu besoin
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Des étapes inutiles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ça se comprend. Il n'y a pas de table de partition MBR avec secteur de démarrage, ni de GPT avec une partition système EFI. La carte mère ne trouve donc rien à démarrer là-dessus.
Ben non, évidemment. Ce n'était même pas la peine d'essayer : pour que la carte mère puisse démarrer quelque chose, il faut qu'elle trouve quelque chose à démarrer, soit dans un MBR, soit dans une partition système EFI. Or là, tu as une clef USB avec, selon ce que tu as fait :
/efi/boot/bootx64.efi
, il n'y a rien à démarrer.C'est surtout comme si elle ne contenait rien à démarrer, ce qui est le cas.
Il n'y a pas de magie, copier des fichiers dans une clef USB ne la rendra pas démarrable, tu aurais pu t'économiser ce temps puisque ça ne pouvait juste pas marcher.
[^] # Re: Des étapes inutiles
Posté par Pinaraf . Évalué à 4.
Je n'ai jamais vu de carte mère qui contrôle le type de partition sur une clé USB. À chaque fois ce fichier sur une partition FAT a été pris immédiatement.
[^] # Re: Des étapes inutiles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Au fait, l'UEFI a bon dos, pour faire un titre pareil :
Ce serait pareil avec un BIOS : l'image de DVD d'installation que tu as téléchargée n'est pas utilisable comme support de démarrage non optique. Elle ne contient pas de table de partition MBR ni GPT, et tu aurais eu exactement le même problème avec un BIOS.
D'ailleurs, tu as probablement un BIOS, ou un émulateur de BIOS, sur la carte mère, donc si à un moment, tu t'étais retrouvé avec un truc démarrable par un BIOS, tu aurais pu continuer. (Jusqu'à un certain point : l'installation d'un système d'exploitation censé être démarré par UEFI implique, à un moment ou à un autre, d'enregistrer son chargeur de démarrage dans les réglages de la carte mère, ce qui se fait avec un protocole issu de l'UEFI, et non disponible si tu as démarré en mode BIOS.)
[^] # Re: Des étapes inutiles
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 22 juin 2022 à 14:12.
Ouais bcp de gens confondent la norme (qui est très bien, il n'y a pas vraiment de débat là-dessus) et l'implémentation (souvent partielle, voire hors norme) des OEMs.
Je profite pour mettre ici LE site qui m'a permis de comprendre (et de plus trop gueuler) : http://www.rodsbooks.com/linux-uefi/
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Pas EFI mais AzureAD / Autopilot
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 9.
Pour la partie "$corp" le soucis vient probablement d'une précédente gestion cloud de la machine, le poste à du contacter AzureAD ou windows autopilot pour et la machine s'est automatiquement reauthentifiée de part des identifiants matériels:
https://superuser.com/questions/1700523/why-does-the-company-name-and-domain-show-up-login-on-windows-10-installer
# Désactiver le SecureBoot
Posté par Shunesburg69 . Évalué à 2. Dernière modification le 26 juin 2022 à 09:31.
Pour Linux, la plupart du temps, on peut rien faire, si on est pas allé dans l'UEFI désactiver le Secure Boot.
Les PC pro ou semi-pro ont souvent la possibilité de passer en Legacy (en Mode Bios au lieu d'UEFI).
Pour l’installation de Windows, c'est pas compliqué faut juste télécharger l'application de Gros$oft, qui s'appelle Windows Media Creation Tool, qui permet de soit télécharger l'ISO soit de faire une clé bootable.
Attention de bien installer Windows avant Linux pour un Dual-boot, sinon Windows ne propose pas le démarrage sur l'autre système.
Pour Info, même Windows ne démarre pas après certains clonage de disque si le Secure Boot est activé.
[^] # Re: Désactiver le SecureBoot
Posté par FantastIX . Évalué à 3.
J'ignore si mon cas est une généralité mais j'ai acheté récemment un Slimbook et il n'est pas possible de désactiver Secureboot. Ou alors c'est moi qui n'ai rien compris mais je n'ai en effet pas trouvé le moyen de le faire et, si j'ai bonne mémoire, le support technique m'a même dit que ça n'était pas possible.
# Clef USB Windows 10 sous GNU/Linux
Posté par Megagolgoth . Évalué à 1.
Bonjour,
Cela faisait un moment que j'avais à l'arracha un petit lot de commande tournant autour de "wimsplit", pour me faire une clef USB d'installation de Windows 10. J'en ai fait un post dans mon blog, pour l'avoir au propre, et éventuellement partager. Voici donc le post :
"Téléchargez la dernière realese de W10, sur le site de Microsoft.
Dans l'exemple $USER=jean-kevin, et l'on est sous Ubuntu. Pour les saveurs "chapeau rouge" (CentOS, Red Hat, Fedora, etc…) voyez yum à la place d'apt.
Nous aurons besoin de wimsplit, contenus dans le paquet wimtools :
-# apt install wimtools
Préparez la clef :
-# sgdisk -og /dev/sdb
-# cfdisk /dev/sdb
Faites une partition de 8Gio, type : espace de stockage Microsoft.
Ensuite, formatez :
-# mkfs.vfat -F 32 -n W10 /dev/sdb1
Retirez/insérez la clef, pour le montage automatique.
Montez l'image W10 sur /mnt :
-# mount -o loop Win10_1909_French_x64.iso /mnt
Copiez tout sauf install.wim, qui ne peut tenir sur la clef, car faisant plus de 4Go (limite de taille de fichier en FAT32).
-# rsync --exclude=install.wim -aP /mnt/ /media/jean-kevin/W10/
Saucissonnez install.wim à l'aide de wimsplit, que l'on mettra directement sur la clef :
-# wimsplit /mnt/sources/install.wim /media/jean-kevin/W10/sources/install.swm 2800
La clef est prête, en boot UEFI uniquement."
Dites moi ce que vous en pensez !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.