Reprise du message précédent :
 
 
En parlant dell, vu que j'en ai un mais avec la ubuntu fourni par dell (sans windows)
 

 
Je m'en doute mais je vais tout de même pas les essayer toutes jusqu'à trouver celle qui fonctionnera enfin out of the box.
Et bon 4 PC différents tout de même... donc idem pas question d'en acheter un 5ème.
 
Et si encore j'avais acheté du matériel réputé pour être exotique ou mal supporté. Mais même pas : processeur intel, et un PC Lenovo et un autre Dell
Il y a donc vraiment un souci. Surtout qu'il y a encore 4 ou 5 ans, je ne me posais même pas la question de savoir si tout allait fonctionner avec Ubuntu. Car c’était évident.

 
Merci je garde ton post sous le coude dès que j'aurais installé la 20.04 sur le Dell    

ça reste bizarre.
Après on n'est pas à l'abris d'un bios daubé ne respectant pas des standards mais quand même tu ne semble pas avoir eu de chance.
J'ai eu du msi (2 Pc portables), du asus (ux310ua à base intel),  du clevo (2 différents dont un avec optimus), j'ai du tuxedo (mon actuel), et le seul soucis que j'ai pu avoir c'est uniquement les gpu nvidia. (6600go/GTX250/960M Optimus ==> le pompon...)
Il me reste encore mon 2 ème msi (le premier à base de pentium M je l'ai donné à quelqu'un du forum), et ce pc à base de intel 720QM + 250Gts marche parfaitement sous MINT LMDE avec les pilotes nvidia.
LE seul soucis que j'ai avec les distribs récente étant donc la fin du support du gpu nvidia (pilote 340).
Qui fait que je passe d'un pc portable 100% fonctionnel à un pc portable qui freeze à cause de nouveau, ce qui condamne de ce fait ce pc portable à une mort certaine alors qu'il reste largement suffisant pour de la bureautique/surf...

 
Puisque tu parles d'un Bios daubé, une autre anecdote croustillante    
 
En 2014 j'ai acheté un PC portable Toshiba.
C'était le début des Bios EFI et celui de ce PC en particulier était bien pourri.
Pour résumer : après avoir désactivé le secure boot ( obligatoire sur cette machine pour autre chose qu'un Windows ) si tu installais Ubuntu en dual boot et en EFI le PC refusait de démarrer sur grub
Il démarrait systématiquement sur Windows.
 
Pour arriver enfin à faire démarrer le PC sur le Grub, il fallait modifier dans fichiers dans la partition EFI, cad :
 

 
Ça fonctionnait au poil !  
 
Et bien devine quoi ? j'ai ressayé récemment la manip, cela ne fonctionne plus    
Le Bios n'a pourtant pas changé depuis, c'est le même.  
Encore un coup des martiens ?  

Qu'un workaround ne fonctionne plus ça ne reste pas déconnant en soit.
A partir du moment ou tu bidouilles pour que ça passe, tu sais que ça peut ne plus marcher du jour au lendemain.

 
Oui mais tu remarqueras que la bidouille était obligatoire.
Et la question de base reste posée : le Bios n'a pas changé, la gestion du démarrage se fait toujours via la partition EFI
Pourquoi diable cette manip qui consistait à remplacer ni vu ni connu bootx64.efi par grubx64.efi ne fonctionne plus ?
 
Fort heureusement, il reste encore la possibilité de faire basculer le PC en mode Legacy  

Non mais pour le coup c'est "normal".
A partir du moment ou tu fais une bidouille, ce n'est pas prévu de base.
Ok ça marche parce que quelqu'un a trouvé l'astuce pour le faire, mais à tout moment le dev et l'évolution du programme peut faire que la chose ne marche plus.

Le bios n'a pas changé, mais le support de efi et grub si. Or si tu bidouilles tu sors du cadre normal, les devs ne vont pas s'amuser à tester ce cas voir s'il y a des régressions (ils ne sont même pas forcément au courant que quelqu'un s'en sort en faisant ça), et faire en sorte que ça marche toujours, surtout si pour supporter la norme ou de nouvelles choses ça va à l'encontre de ça.

Pour le coup c'est juste normal.
Il y a peut-être une nouvelle astuce pour le faire avec ce qui est récent.

Les régressions tu les tests sur la norme et le standard, si pour faire marcher un matériel spécifique tu as du faire une bidouille ne respectant pas la norme et posant problème sur d'autre matériel récent qui eux respectent la norme, ben forcément ton support va sauter.

C'est tout le problème du dev et des machines qui ne respectent pas les normes.

Voila, on est bien d'accord. C'est exactement ce que je voulais montrer.  
En gros cela condamne celui qui n'a acheté du matos correctement supporté à constamment chercher une nouvelle solution.
Conserver la même -> on oublie  
edit : et si j'avais conservé Ubuntu en dual boot pendant des années sur ce PC, au bout d'un moment ( au hasard une mise à jour de Grub ) -> paf plus rien ne démarre.
Faut penser à faire des sauvegardes  

Ben non c'est l'inverse que je dis justement.

C'est celui qui a du matos qui ne respecte pas la norme, ou qui est obligé de bidouiller à moment donné pour le faire supporté qui se retrouve en galère.
Mais pour moi c'est normal.

Et en l’occurrence comme évoqué, le dev n'a pas forcément connaissance que quelqu'un est obligé de bidouiller comme ça pour que ça passe.
Le seul moyen pour corriger/régler ça étant de trouver une astuce pour TON CAS.
Si tu remontes au dev, il le fera peut-être mais rien ne le garantie, la personne qui a donné l'astuce initialement n'a peut-être rien à avoir avec le dev qui lui n'a jamais eu l'information.

EN fait, le problème initial c'est quoi? Le non support d'une norme et ou un tatouage par hp.
Quelqu'un sympa t'as trouvé une astuce avec l'existant. Mais en temps normal ça ne marche pas ben ça ne marche pas.
Si tu prends la même logique sous windows, ton portable ne marche pas ben, tu te démerdes, microsoft ne vas pas chercher une astuce pour toi avec l'existant. Et en fait c'est justement ça que tu reproches à linux... Le fait que quelqu'un ait fait cet effort là moment donné pour que tu puisses quand même t'en servir et passer outre ce bug du constructeur...
Tu ne peux pas leur reprocher ensuite que ça ne fonctionne pas sur le long terme. Parce que ça restait une astuce.

Sous windows la question ne se pose pas:
Si ça ne passe pas, ça ne passe pas, personne chez microsoft ne va t'aider à trouver une astuce ou un détournement. ILs t'enverront vers le constructeur.
Exemple le support des mac sous windows via bootcamp. (il se trouve qu'apple a fait le nécessaire niveau pilote etc, mais au tout début tu as pu avoir pas mal de merde niveau réseau etc des coupures aléatoires etc).
J'ai eu le cas avec un utilisateur qui voulait à tous prix un mac parce que c'est "zoli" mais qui voulait windows dessus parce que taf oblige... JE te raconte pas les merdes et déboires.

En fait, là ce que tu es en train de critiquer, c'est justement le fait que les gens se mettent en 4 pour essayer de trouver des solutions de contournement, au lieu de t'envoyer péter avec un "ça marche pas voyez avec votre constructeur" et que la solution ne contournement ne fonctionne pas sur le très long terme.
Le fait d'avoir des pcs qui ne marchent pas sur la durée, ce n'est pas une généralité, la preuve, TOUS mes pcs ont fonctionné durant plus de 10 ans sous linux sans soucis. (sauf les gpu nvidia faute de pilote...)
JE ne dis pas que ça sera le cas de tout le monde, jusque ce n'est pas non plus une généralité.

Maintenant, il ne faut pas mélanger ce qui dépend de bidouille de véritables régressions.
La grosse différence entre windows et linux, c'est que les pilotes sont fait par les constructeurs sous windows, alors que c'est en majorité fait par des gens pour linux. Donc si personne n'a ton matériel, personne ne peut tester.
La seule solution serait d'utiliser du matériel certifié linux sous la distrib certifié. (exemple SUSE etc).

Et encore une fois, la qualité d'une distrib dépend aussi des choix des logiciels, si tu prends du récent, tu auras forcément plus de chance d'avoir des régressions. C'est naturel et normal le temps que ça soit réglé/corrigé.
Et c'est là aussi la grosse force de linux, on teste, on voit un bug on remonte.

TOut n'est pas parfait, mais on est quand même très loin du tableau que tu dépeins.
Après ubuntu c'est ubuntu, ça n'est pas une référence en stabilité sur le long terme non plus. Des phases ou ce n'est pas stable parce qu'il faut sortir à une date X, c'est courant chez eux...

EDIT, il manquait un "pas" dans ton propos, mais ça ne change pas ce que je dis, oui c'est normal, à partir du moment ou tu bidouilles, rien ne garantie que ça continuera à marcher, c'est normal.
Si tu veux que ça continue à marcher, il faut remonter les pbs au dev et voir s'il a d'autres idées d'astuces ou s'il peut continuer à faire marcher cette astuce sans que ça ne le gêne dans le support de matériel qui respecte la norme ou pour de nouvelles normes.
C'est juste normal...

 
 
ça c'est parceque bootx64.efi c'est fait pour les disques amovibles, donc l'UEFI cherche en premier les fichiers bootx64.efi dans les partitions qui sont déclarées comme étant des partitions EFI, et si tu l'as quelque part sur le disque fixe, alors ça bootera toujours dessus.
 

Normalement dans le bios uefi tu peux ouvrir un menu qui te permet de choisir sur quoi booter.
Après la difficilté c'est qu'il se base sur ce qui est inscrit dans son firmware.

Pour le modifier manuellement il faut utiliser efibootmgr dans linux.

Donc le plus important c'est surtout d'avoir un live cd/usb qui justement bootera toujours automatiquement car le bios trouvera un boot64.efi quelque part dessus.

Le problème à l'heure actuelle vient surtout de Ubuntu qui voulant absolument être compatible secure boot, met d'office un  shim64.efi signé par microsoft, et grub64.efi signé par canonical dans le dossier EFI/ubuntu/ ce qui complique la création de multiboot, car grub64.efi étant un binaire fournit tel quel, il n'est pas régénéré avec les infos permettant par exemple de lancer un EFI/ubuntu-numero2/grub.cfg .

Si on fait en sorte de créér un EFI/ubuntu-numero2/grubx64.efi alors il pointera toujours sur EFI/ubuntu/grub.cfg parcequ'il est copié tel quel, puisque si on le régnère à chaque fois, alors il sera pas signé par canonical, et donc il sera pas secure, ne pourra pas être lancé par shim64.efi .

Donc la solution c'est de désactiver secure boot, et de copier /boot/grub/x86_64/grubx64.efi dans EFI/ubuntu-numero2/grubx64.efi .

J'ai pas trouvé de moyen pour que ubuntu le fasse automatiquement quand elle fait un update-grub.

 
J'avoue ne pas trop comprendre ta remarque.
 
Si je prend l'exemple de mon PC portable Lenovo ( qui lui a un Bios EFI plus récent qui respecte les standards )
Si je vais jeter un œil dans /boot/efi/EFI/ je trouve 2 dossiers :
 

 
Si j'ouvre le dossier boot je trouve bien le fichier bootx64.efi
 

 
Et si j'ouvre le dossier Manjaro je trouve bien le fichier grubx64.efi
 

 
Le tout avec un secure boot désactivé.
 
Bref, la même chose que sur mon PC portable Toshiba.
Mais celle fois ci comme le Bios EFI n'est pas daubé, il démarre bien sur grubx64.efi, et j'ai donc le Grub au démarrage ( alors que le Toshiba ne veut rien savoir )
Par contre sur le Toshiba, si depuis Windows je vais dans récupération -> redémarrage avancé alors je peux retrouver l'entrée EFI d'Ubuntu ( qui s'appelle Ubuntu tout simplement ) et qui permet d'accéder au Grub. Mais celle ci n'est pas accessible directement au démarrage en fait ( sauf avec mon ancienne magouille qui ne fonctionne plus )
 
edit : le Bios du Toshiba en plus d'être daubé est archi simpliste comme souvent sur les PC portables -> on ne peut rien paramétrer

Sinon petit retour de l'installation d'Ubuntu 20.04 lts ( version normale cad gnome ) sur mon Dell Inspiron de 2011
 
Les plus :
- c'est rapide comme il faut ( je ne vois plus l’intérêt d'une variante légère comme Mate ou Xfce, c'est pas plus véloce )
- détection/configuration d'un appareil Bluetooth et de l'imprimante réseau HP -> génial rien à redire. Tout aussi bien voir mieux que W10, et surtout mieux que Ubuntu Mate ou Manjaro
Les moins :
- luminosité de l'écran pas prise en charge par défaut, comme je le craignais après mon essai en session live ( ça se corrige )
- j'ai installé gnome-tweak ( ajustement ) pour mettre tout cela en accord avec les goûts de Madame, vu que c'est son PC, mais si je met les boutons de fenêtre à gauche comme avant avec Unity ça fait buguer certaines fenêtres. Dommage. Mais bon Gnome Shell n'a jamais été réputé pour aimer la personnalisation donc...
 
Je tiendrais au courant des bugs et si il n'y en a pas, c'est que cette version LTS est la seule recommandable pour tous et que je me fourvoyais à utiliser les dernières versions. Pour l'instant tout est OK  

Un truc étonnant tout de même : Ubuntu s'est installé en EFI et avec une partition étendue !  
 
Pourtant ce PC n'est pas compatible UEFI
 
Peut être parce que j'ai utilisé Ventoy sur ma clé USB ? en tout cas j'avais bien installé avec l'option par défaut " effacer le disque et installer Ubuntu"
 

 
edit : visiblement le résultat de cette commande montre qu'il est installé en mode classique legacy
 

 
Du coup je ne comprend pas vraiment la présence de cette partition EFI

 
Il y a deux choses dans l'efi.
1/ la partition /EFI en fat32 et flaguée uefi, qui contient des dossiers et des bootloader uefi tels que /EFI/${vendor}/*.efi  qui sont en fait des binaires stage2, c'est un peu similaire au fonctionnement du bios pour ça.
 
Le stage 2 est en fait un binaire d'amorçage plus élaboré qui contient des drivers plus avancés pour lire périphériques ou systèmes de fichiers qu'on ne pourrait pas maintenir dans le firmware du bios ou de l'uefi, comme LVM, NTFS, ZFS, BTRFS.
Le stage 2 va ensuite soit lancer un autre stage 2, ça s'appelle chainload, soit il peut lancer directement un kernel.
 
Par défaut dans Ubuntu c'est comme ça :
1 ->/EFI/ubuntu/shimx64.efi
2 -> chainload /EFI/ubuntu/grubx64.efi donc grub
3 -> qui va charger /EFI/ubuntu/grub.cfg
4 -> qui contient une commande "configfile /boot/grub/grub.cfg" permettant de charger ce dernier fichier,
5 -> qui contient les commandes qui lancent les kernels.
 
C'est donc un pseudo chainload, car en fait ce qu'on peut faire aussi c'est :
->/EFI/ubuntu/shimx64.efi
-> chainload /EFI/ubuntu/grubx64.efi donc grub
-> chainloader /boot/grub/x86_64/core.efi  
-> core.efi contient en fait une copie de /boot/grub/grub.cfg
-> le grub.cfg de core.efi lance les kernels
 
2/ des entrées dans le firmware EFI, qui pointent vers /EFI/${vendor}/*.efi et qui permettent d'avoir une forme de multiboot selectionnable au niveau des menus de l'EFI
Elle se créent avec efibootmgt sous linux.
 
Si tu mets ton disque dur dans une nouvelle machine, alors au démarage, elle ne sait pas quel /EFI/${vendor}/*.efi lancer, et donc tu auras un système imbootable.
Dans ce que j'ai compris, le bootx64.efi par standard sera cherché par l'uefi pour le démarrer, et je pense qu'il les prend dans l'ordre des disques qu'il détecte, et probablement il a un moyen qui par défaut met les périphériques amovible devant, mais ça peut se changer dans l'uefi.
Un live CD contient je pense un bootx64 quelque part, qui dit ou trouver
 
 
Je suis pas totalement certain, mais je pense que l'efi peut lancer un kernel directement, si on le met dans /EFI/ et qu'on créé une entrée dans le firmware UEFI avec efibootmgr.
Mais si tu voulais le faire avec secure boot, ça vaudrait dire que ton kernel devrait être signé par microsoft eux mêmes, sauf que ton kernel ça évolue tout le temps, donc laisse tomber.
C'est pour cette raison que Ubuntu a fait signer shim64 par microsoft, et que ce truc ne change jamais car il faut payer pour le faire signer.
Son seul role c'est de lancer un grux64.efi qui est lui signé par canonical et donné tel quel, mais ils le mettent à jour de temps en temps suivant les releases.
 
Pour ma part j'ai résolu cradement un probleme en copiant /boot/grub/x86_64/core.efi dans /EFI/gorilla/core.efi, et j'ai créé une entrée dans le firmware du bios pour qu'il lance directement /EFI/gorilla/core.efi
Je referais un truc plus propre par la suite, maintenant que j'ai compris le bordel.
 
 
Voilà pour ton problème je sais pas, mais il y assez de détail pour tenter de comprendre ce qui va pas sur ton PC.
Il y a probablement une config qui a sauté quelque part, peut être à cause de Ubuntu Windows ou autre.

Ok merci pour tes précisions.
Tout cela reste diablement compliqué... et limite incompréhensible comme dans le cas que je viens de montrer plus haut, car je me retrouve avec une partition EFI de boot sur un PC qui ne gère pas ce système.
C'est la première fois que j'observe ça sur mon Dell en tout cas. Quelqu'un sait si c'est normal ? une nouveauté ?
 
edit : ce n'est pas pour moi un problème, le PC Dell démarre rapidement ( même plus rapidement qu'avant ) donc je vais tout laisser en l'état.
Et si tu parles du problème du Toshiba, à l'avenir si je veux réinstaller un Ubuntu je le ferais en mode Legacy puisque le Bios le permet et que c'est largement moins le bordel  

D'ailleurs d'ici quelques mois je réinstallerai certainement un Linux sur le Toshiba car W10 gère le wifi comme un abruti sur cette machine et visiblement c'est impossible à corriger ( alors que Linux pas de souci )

Et pourquoi ne pas prendre une autre distribution (genre Fedora ou openSUSE) plutôt que Windows 10?
Ça serait étonnant que l'un de ces deux distributions ne puisse bien gérer ton matériel.
À moins de préférer Windows à Linux bien entendu.
 
Mon exemple perso : je viens de prendre un nouveau portable (AMD Rysen 4500U, SSD etc ...) et tout fonctionne parfaitement via openSUSE Tumbleweed. Le boot est en UEFI, fastboot actif etc ...
Évidemment, j'ai viré direct Windows, je ne tenais pas à m'embêter pour rien.

Pour le Toshiba aucune distribution ne pourra corriger le Bios EFI moisi malheureusement ( et vu que le PC est de 2014 et que le Bios n'a jamais été mis à jour c'est mort de chez mort )
Mais ce n'est pas bien grave, le mode Legacy est dispo.
W10 je ne fais pas une fixette dessus, je suis pragmatique et j'utilise ce qui fonctionne le mieux.
 
Pour l'instant la situation est la suivante ( désolé je sais qu'il faut suivre, je suis un peu girouette )
- PC fixe avec W10, je virtualise des Linux dessus -> aucun intérêt de faire un dual boot vu comme Linux fonctionne déjà dans VMware  
- PC portable Dell de 2011 -> Ubuntu 20.04 lts. Pour l'instant tout est nickel, si cette version lts est aussi stable sur le long terme qu'elle l'est depuis que je l'ai installé il restera ainsi jusqu'à la 22.04 lts
- PC portable Toshiba sur W10. Pour l'instant je ne touche à rien mais je pense qu'il basculera sur un Linux dans quelques mois. Je ne suis pas pressé, ce n'est pas un PC très agréable au quotidien ( processeur qui chauffe de façon excessive et clavier moisi )
- PC portable Lenovo sur Manjaro Gnome. Je touche du bois, rien ne part en vrille depuis que je l'ai installé le 15 mai    
Mais c'est mon PC de test, donc je me réserve le droit de tout changer selon mes lubies    
 
Donc je ne suis pas un anti Linux finalement. Pour l'instant chez moi c'est du 50/50  

Par contre c'est clair que je suis en 100 % Intel et que c'est un gros inconvénient finalement. Surtout que AMD a l'air de faire du très bon travail sous Linux.

Il vaut mieux avoir la partition uefi, pour pouvoir migrer le disque vers une machine uefi.
Ça coûte pas grand chose en place.
Tu peux aussi faire des trucs sympa avec une partoche un peu plus grande je pense que tu peux y coller un live cd qui peut servir pour bricoler les merdes.

Je crois que gpt n’est nécessaire que au delà de 2To ou 1To, je ne sais plus.
De plus c’est possible que tu sois en partitionnement hybride msdos/gpt et que gparted ne sache pas l’afficher.

Essaye avec gdisk -l

Ça fait longtemps que je me suis pas pris la tête avec ça.
J’ai un ssd à passer vers de 500 vers un 750.
Il y a un dualboot Windows Linux dessus, j’ai pas le courage

C'est un SSD de 500 Go sur le Dell et je suis bien en partitionnement MBR    
 

 
En comparaison voici le résultat de la même commande sudo parted -l sur mon PC Lenovo qui est bien en GPT et EFI :
 

ne serait il pas possible de mettre à jour un bios sous linux ?
 
A moins que la machine accepte de le mettre à jours

Normalement, les BIOS ont leur propre mécanisme de mise à jour.
 
Oui, tu peux mettre à jour le BIOS depuis un Windows, mais bon, c'est juste une facilité mise au point par les fabricants/assembleurs (HP, Dell, etc ...).
 
Sur ma carte mère X570 (récente donc), je passe par la clé USB et le lancement de l'outil de flashing intégré au BIOS

Bonjour,

Peut-on mettre à jour un bios sous linux?
- oui ==> Il existe différentes méthodes.
Et même certains constructeurs le permettent d'une manière totalement intégrée, ça marche pour dell/lenovo par exemple. Tu récupères les majs de bios via le gestionnaire de mise à jour de linux.
Si ça vous intéresse, creuser le sujet "fwupd"

Même sans ça de nombreuses carte mère permettent le flashage depuis un périphérique usb, il suffit juste d'avoir le bios sur une partition fat32 sur clef usb pour pouvoir le flasher.

Mais le fait de pouvoir, ne veut pas dire qu'il existe un bios qui règle ton soucis.  EN l’occurrence même s'il pouvait flasher depuis linux, s'il n'existe pas de bios plus récent, il ne peut rien faire.

c'est le cas de mon dell, fwupd le met a jour sans problème très souvent (vu le nombre de faille intel a fixer chaque fois)

Et la mise a jour apparait automatiquement dans ubuntu software onglet mise a jour, et il ne l'installe pas seul, il faut cliquer sur intaller.

edit;  justement j'en ai une

Bon j'ai l'imprimante des parents qui ne fonctionne plus et j'ai aucune idée de pourquoi.
 
J'avais déjà eu le cas il y a quelques semaines et j'avais trouvé une solution à base de purge cups-browsed, mais impossible de retrouver le lien
 
Ils sont sous Ubuntu 20.04 et à jour, branché en ethernet.
L'imprimante est un HP OfficeJet 3831 connectée en wifi. J'ai déjà essayé la technique windaube de redémarrer l'un, puis l'autre, puis les deux, sans succès.
 
Si je vais dans paramètres->imprimantes, elle apparaît (ou non si je viens de la supprimer ) et voulant l'ajouter manuellement il me la trouve mais impossible d'interagir avec.
J'ai utilisé la fonction débogage qui m'a sortit ça à la fin:
 

 
Sauf que je suis incapable de voir ce qui ne va pas (oui y'a bien le client-rror-not-found, mais pendant le debug il me l'a trouvé, je suis donc perdu )

Le service CUPS est bien démarré ?
 
L’imprimante utilise bien une IP sur le réseau local (192.168… ou 10…), qui ne soit pas déjà utilisée par un autre appareil, et pas un truc à la 168… ?

Yep elle est en 192.168.1.2  et rien d'autres sur la même ip.

Et cups est, à priori, bien démarré (sauf si cups-config est perçu comme un autre programme ? Dans ce cas il faudra que je vérifie en rentrant)

Quand je lis ça, je me dit que j'ai bien fait de rester en legacy sur toutes mes installations. C'est pas aussi souple mais au moins c'est pas compliqué et surtout ça fonctionne à tous les coups  

Début de l'UEFI en 2014 ? J'ai un HP de 2009 qui en a un aussi. Et le comble c'est qu'ils recommandent de ne pas l'activer car y'aurait potentiellement des risques de sécurité   Savaient-ils que c'était de la daube dès le départ ?  

 
Non ça ne prouve rien, je parle de partionnement hybride.

Bon de toute façon ça marche, donc je vais pas faire une enquête approfondie pour savoir pourquoi Ubuntu 20.04 lts m'a collé une partition EFI sur un PC qui est juste en Bios classique    
 
Dans les mystères d'Ubuntu, vu ce matin justement sur le Dell.
J'imprime sur mon imprimante réseau HP Envy 5020 ( qui a été détectée et installée automatiquement depuis belle lurette )
 
Première page imprimée -> aucun souci.
Deuxième page quelques minutes après -> plus moyen ( message d'erreur Cups bidule en anglais incompréhensible )
Je désinstalle l'imprimante dans les paramètres -> elle est à nouveau détectée et installée -> l'impression fonctionne à nouveau.
 
Qu'est que c'est stable une LTS  
 
edit : même ma compagne en rigole  

Pour ton EFI, lors de l'install au moment de partitionner les disques, le choix BIOS ou EFI se trouve au dessus du tableau des partitions
 
(j'ai dû gérer la chose sur le PC portable du taf en UEFI)

Je n'ai rien partitionné, j'ai juste coché la case " effacer tout et installé Ubuntu"    
Il s'est fait automatiquement.

Bonjour,
 
J'aimerais installer Ubuntu en dualboot sur un SSD NVMe, j'ai du abandonner ma première tentative hier soir en constatant lors de la création de la partition système qu'il ne détectait pas mon disque système (SSD NVMe) mais uniquement le SSD SATA du PC.
 
En faisant quelques recherches, il semblerait que l'une des solutions soit de désactiver l'option "fast boot" mais je n'ai rien trouvé de tel en parcourant l'UEFI de ma carte mère (B450 Tomahawk MAX).  
Une autre cause possible serait que le SSD soit en RAID plutôt qu'en AHCI. Je ne sais pas exactement ce qu'implique ces 2 termes, mais j'ai lu qu'il était possible d'effectuer le passage de l'un à l'autre sans forcément réinstaller Windows. https://askubuntu.com/questions/963 [...] nd-raid-on
Cependant, je ne suis pas certains de ce que ce changement implique concrètement ? Puis-je effectuer une telle manœuvre sans risquer quoi que ce soit ?
 
D'avance merci pour votre aide  

Alors RAID et AHCI c'est, en gros et sans rentrer dans les détailes, 2 modes de fonctionnement des disques dur.
 
J'ai effectivement dû faire la même manip que toi sur un de mes laptop que j'ai acheté sans OS  et où je voulais installer Linux. Le RAID il aime pas faut mettre le nvme en AHCI.
 
Ce que tu peux faire pour voir si c'est ça qui bloque, tu vas dans le BIOS, t'actives le mode AHCI à la place du RAID (c'est spécifique à ta carte mère je peux pas te donner les détails faut chercher un peu), tu reboot et tu met ton iso Ubuntu en lançant l'installeur pour voir si cette fois-ci il te trouve ton disque nvme. T'installe pas, tu regardes juste si l'installeur détecte ton disque. Si c'est ça, ben tu remets en RAID dans le BIOS pour pouvoir redémarre Windows et tu suis les instructions donné sur la page que t'as mis en lien pour que Windows demarre avec le mode AHCI cette fois. Puis t'installe Ubuntu.  
 
Voilà ce que je ferai.
 
Après c'est pas des manip' évidentes quand on sait pas trop ce qu'on fait ni qu'on a pas trop l'habitude d'installer des systèmes d'exploitation, donc avant de faire quoi que ce soit fait des sauvegardes et dit toi que c'est pas impossible que t'ai à réinstaller Windows malgré toutes tes précautions parce que ça a foiré quelque part.
 
Un dernier conseil c'est de faire de la place pour Ubuntu directement sous Windows avant de l'installer dans le cas où ton nvme est entièrement partitionné. Moi j'ai personnellement pas confiance en ces outils de l'installeur Ubuntu, pas à cause de ce dernier mais plutôt de Windows qui peut mal réagir à un redimensionnement dans son dos. Après d'autres peuvent pas être d'accord avec moi mais c'est ce que je ferai.

Salut,
 
j'utilise l'extension Panel OSD pour choisir l'emplacement des notifications Ubuntu.
 
Je cherche maintenant à pouvoir agrandir le texte des notifications car je suis passé sur un 34" wide et ca fait petit !

Je suis embêté avec mon nouvel écran ... quand je verrouille ma session avec SUPER+L les écrans passent noir - hors signal - jusque là d'accord, meme si dans tous les parametres je mets "jamais" pour extinction d'écran... mais le problème est quand je veux les réveiller... mes 2 22" s'allument, mais le 34" reste éteint, et quand je vais dans les paramètres d'affichage Ubuntu, il est désactivé, je dois le réactiver, ce qui implique aussi de re régler le positionnement multi moniteurs et définir l'écran principal, bref ingérable à faire à chaque verrouillage de session.

Comment faire pour que cet écran se réveille normalement dès que je retouche le clavier ou alors l'empêcher complètement de s'éteindre ?!

Je suis sous Ubuntu 20.04.2 LTS sous X11.

EDIT: solution ! grâce à cette extension Gnome, les écrans ne s'éteignent plus avec le verrouillage. Dommage pour la planète, mais je vois pas d'autre solution dans l'immédiat. C'était pas le fait que l'écran s'éteigne qui me gène mais qu'il se désactive dans Gnome et ne se réveille pas du coup !
https://github.com/sunwxg/gnome-shell-extension-unblank

Afficher une image constante sur un écran ce n'est jamais une bonne chose.
Il vaut mieux trouver pourquoi ton écran ne se réveille pas en sortie de veille.

Dites, je me suis pris sur Dealabs un bon vieux Lenovo ThinkPad X250.  
Je compte y mettre un bon Ubuntu. Sur les derniers commentaires, il semblerait que la version 20.04 soit la plus stable, c'est bien ça? J'avais téléchargé la version 21.04 et je l'ai installée sans trop de soucis mais...  
Un truc qui m'a étonné : on n'a plus le choix, c'est KDE d'office? Ou vous changeriez pour un autre environnement?  
 
Merci de vos retours