La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: vivien le 27 avril 2018 à 13:50:53
-
Ubuntu 18.04 LTS est sorti
C'est une version LTS : il y a donc un support de 5 ans, jusqu'en avril 2023.
Par défaut les boutons pour minimiser, agrandir et fermer une fenêtre repassent à droite :
(https://lafibre.info/testdebit/ubuntu/201804_ubuntu_1804_bienvenue_1.png)
(https://lafibre.info/testdebit/ubuntu/201804_ubuntu_1804_bienvenue_2.png)
Au programme :
- noyau Linux 4.15 : c'est le premier Kernel qui a eu nativement la correction concernant Spectre et Meltdown
- GNOME 3.28 comme environnement de bureau par défaut à la place de Unity 7 qui est toujours disponible
- KDE Plasma 5.12 l’environnement de Kubuntu
- LibreOffice 6 avec possibilité de chiffrer tous les documents ODT avec une clé OpenPGP
- Mesa 3D 18 (bibliothèque graphique libre, qui fournit une implèmentation générique d'OpenGL)
- systemd 237
- Python 3.6.5
- OpenJDK 10
Compilation : (De nouvelles options de compilation liées à la sécurité ont été activées par défaut permettant une meilleur distribution aléatoire de l'espace d'adressage pour rendre plus difficile l'exploitation d’éventuelles failles de sécurité)
- GCC 7.3. GCC 7.3 inclut également des options de génération de code pour atténuer la variante 2 de la vulnérabilité Spectre
- LLVM/Clang 6 inclut également des options de génération de code pour atténuer la variante 2 de la vulnérabilité Spectre
- Glibc 2.27 la bibliothèque standard C
- Qt 5.9.4 qui intègre HSTS (HTTP strict transport security, qui empêche les changements intempestifs de certificat)
Web :
- Apache 2.4.29 avec prise en charge de HTTP/2
- ngix 1.14.0 avec HTTP/2 push
- PHP 7.2
- PostgreSQL 10
Virtualisation :
- QEMU 2.11.1
- LXD 3.0
- Open vSwitch 2.9
Vieux PC :
Il n'y a plus de fichier .iso pour une installation 32bits : les 64 bits est obligatoire pour une nouvelle installation d'Ubuntu ou Ubuntu serveur.
Pour un vieux PC vous pouvez toujours faire une mise à jour, la preuve :
(https://lafibre.info/testdebit/ubuntu/201804_ubuntu_1804_unity_xorg.png)
Sinon, il faudra se tourner vers Xubuntu ou Lubuntu qui existent en version 32bits.
Lubuntu es l’environnement de Bureau qui consomme le moins de ressources. Toutes les petites options sympa qui consomment de la ressource mémoire ou CPU sont supprimés.
Pour les PC avec moins de 700 Mo de RAM, il existe une ISO de Lubuntu "alternate" qui permet une installation en mode texte. Lubuntu 18.04 fonctionnera ensuite parfaitement, avec une interface graphique, mais ne pensez pas démarrer plusieurs programmes simultanèment.
-
Les versions LTS d'Ubuntu sont les plus utilisées, comme le montre ces statistiques du serveur de mise à jour pour la France : http://fr.archive.ubuntu.com/stats/
Les statistiques des 730 000 ordinateurs qui ont rélaisé sune mise à jour le 25 avril 2018 (veille de sorite d'Ubuntu 18.04 LTS) : Les 3 versions d'Ubuntu les plus utilisées sont en gras et sont toutes des LTS
- Ubuntu 18.04 : 1.122% (8190 separate computers)
- Ubuntu 17.10 : 5.592% (40790 separate computers)
- Ubuntu 17.04 : 2.295% (16744 separate computers)
- Ubuntu 16.10 : 1.297% (9462 separate computers)
- Ubuntu 16.04 LTS: 61.453% (448198 separate computers)
- Ubuntu 15.10 : .655% (4780 separate computers)
- Ubuntu 15.04 : .976% (7119 separate computers)
- Ubuntu 14.10 : .159% (1160 separate computers)
- Ubuntu 14.04 LTS: 18.288% (133382 separate computers)
- Ubuntu 13.10 : .279% (2035 separate computers)
- Ubuntu 13.04 : .189% (1380 separate computers)
- Ubuntu 12.10 : .150% (1096 separate computers)
- Ubuntu 12.04 LTS: 5.974% (43573 separate computers)
- Ubuntu 11.10 : .156% (1142 separate computers)
- Ubuntu 11.04 : .133% (977 separate computers)
- Ubuntu 10.10 : .053% (389 separate computers)
- Ubuntu 10.04 LTS: .972% (7096 separate computers)
- Ubuntu 9.10 : .045% (334 separate computers)
- Ubuntu 9.04 : .029% (212 separate computers)
- Ubuntu 8.10 : .006% (44 separate computers)
- Ubuntu 8.04 LTS: .146% (1066 separate computers)
- Ubuntu 7.10 : .002% (18 separate computers)
- Ubuntu 7.04 : .002% (17 separate computers)
- Ubuntu 6.10 : .001% (9 separate computers)
- Ubuntu 6.06 LTS: .015% (112 separate computers)
- Ubuntu 5.10 : 0% (3 separate computers)
- Ubuntu 5.04 : 0% (1 separate computers)
- Ubuntu 4.10 : 0% (0 separate computers)
-
730000 c'est un chiffre mondial?
Sinon en 16.04LTS, ça vaut le coup de changer?
-
La plus grosse nouveauté pour nous ici c’est que la gestion réseau se fait avec Netplan, personnellement je n’aime pas du tout, un yaml pour la conf réseau c’est infâme...
La disparition des post-up me gave au plus haut point, je ne sais pas encore comment je vais gérer ça sur les quelques ubuntu qui en ont.
Sinon c’est déjà dispo sur les VM MilkyWan, on a préparé les images cloudinit et bêta testé ça depuis quelques mois :)
-
730000 c'est un chiffre mondial?
Juste en France je pense
-
730000 c'est un chiffre mondial?
Pour une partie de la France.
C'est le chiffre qui concerne le serveur miroir par défaut pour la France ( http://fr.archive.ubuntu.com/ ) sachant qu'il est possible d'en choisir un autre manuellement et que certains hébergeurs et grande entreprises prépositionnent leur propre serveur miroir par défaut sur leur installation. On peut citer le cas des hébergeurs Français OVH, Ikoula, PlusServer et ServerLoft qui mettent leur miroir par défaut sur les installations réalisés par leur outil. Coté entreprise, la gendarmerie, avec 100 000 PC Ubuntu a très probablement son propre serveur miroir en interne.
Inversement, il me semble que les serveurs Online utilisent fr.archive.ubuntu.com par défaut.
Hors de France ce serveur est presque pas utilisé. Par exemple en Belgique, c'est le serveur be.archive.ubuntu.com qui est par défaut...
Sinon en 16.04LTS, ça vaut le coup de changer?
Oui, mais si tu souhaites être sur de ne pas avoir de bug, tu peux attendre quelques mois, le temps que les bug qui seront remontés seront corrigés.
La migration ne sera proposé aux clients 16.04 qu'a partir du mois d'aout 2018 pour cette raison.
-
Oui, mais si tu souhaites être sur de ne pas avoir de bug, tu peux attendre quelques mois, le temps que les bug qui seront remontés seront corrigés.
Dans le genre bug "drôle" mais pas vraiment gênant y'a par exemple les vu-mètres de pavucontrol qui ne vont pas jusqu'à 0dB, si on monte le volume ça s’arrête au tiers à peu près.
-
Le combo PulseAudio + Ubuntu es toujours aussi pourri à ce que je vois :D
-
Inversement, il me semble que les serveurs Online utilisent fr.archive.ubuntu.com par défaut.
C'est aussi en interne :)
Chez MilkyWan, on a un proxy APT, pas encore de miroir :)
-
La migration ne sera proposé aux clients 16.04 qu'a partir du mois d'aout 2018 pour cette raison.
Merci Vivien, je vais laisser couler jusqu'à la proposition de mise à jour.
-
La plus grosse nouveauté pour nous ici c’est que la gestion réseau se fait avec Netplan, personnellement je n’aime pas du tout, un yaml pour la conf réseau c’est infâme...
La disparition des post-up me gave au plus haut point, je ne sais pas encore comment je vais gérer ça sur les quelques ubuntu qui en ont.
Il n'y a plus moyen d'installer le package ifupdown pour revenir au fichier /etc/network/interfaces ? Ou c'est à éviter car 'deprecated' ?
C'est vrai que cela apparait un peu pénible..
-
Faut aller modifier tes arguments au boot, c'est assez relou à faire...
-
Le combo PulseAudio + Ubuntu es toujours aussi pourri à ce que je vois :D
Je viens de faire une install de l'iso finale en VM et le problème semble avoir été réglé. Après c'est peut-être un soucis avec mon PC... car ça ne m'a jamais fait ça avant. Faudrait que je réinstalle proprement pour voir.
EDIT : réinstallation "physique" faite, les vu-mètres sont de retour ;)
-
Faut aller modifier tes arguments au boot, c'est assez relou à faire...
Effectivement, comme Netplan est utilisé à l'installation...
Edit the /etc/default/grub file
sudo nano /etc/default/grub
Add the following line
GRUB_CMDLINE_LINUX="netcfg/do_not_use_netplan=true"
http://www.ubuntugeek.com/disable-netplan-on-ubuntu-17-10.html
J'ai l'impression que c'est encore systemd qui s'infiltre un peu plus dans le système...
-
Oui plutôt d'accord...
-
(https://pix.milkywan.fr/XbWk82Is.gif)
-
Netplan, cela n'impacte que ceux qui ont configuré /etc/netwok/interfaces à la main : dans 99,99% des cas des version serveur (sans interface graphique)
La plus grosse nouveauté pour nous ici c’est que la gestion réseau se fait avec Netplan, personnellement je n’aime pas du tout, un yaml pour la conf réseau c’est infâme...
Tu as déjà fait une migration ? Il te crée un conf à partir de ton fichier /etc/netwok/interface ?
Le /etc/netwok/interfaces est tout simplement ignoré ?
La doc pour Netplan : https://netplan.io/
/etc/resolved.conf est remplacé par systemd-resolved : https://www.freedesktop.org/software/systemd/man/resolved.conf.html
-
Tu as déjà fait une migration ? Il te crée un conf à partir de ton fichier /etc/netwok/interface ?
Alors @GaetanF t'en dira des nouvelles. Cet outil a (avait?) la particularité de sortir des configurations invalides.
/etc/resolved.conf est remplacé par systemd-resolved : https://www.freedesktop.org/software/systemd/man/resolved.conf.html
ça c'est vraiment infect, resolv.conf c'est juste méga pratique, là ça met un foutoir, aucune idée de comment on le gère (j'invoque Gaëtan encore une fois)
-
Tu as déjà fait une migration ? Il te crée un conf à partir de ton fichier /etc/netwok/interface ?
Le /etc/netwok/interfaces est tout simplement ignoré ?
Pour l'instant, je l'ai géré en "from scratch".
Résultat, plus rien dans network/interfaces, tout dans netplan.
Côté resolv, la même chose, géré par systemd-resolve avec la conf DNS en fixe et la conf DNS via les int. (Me reste à faire l'intégration dans Ansible :) ).
On peut même plus toucher le resolv.conf, systemd écrase la conf avec la sienne derrière.
-
On peut même plus toucher le resolv.conf, systemd écrase la conf avec la sienne derrière.
Oh avant que t'arrive, je gérais ça via un joli chattr +i, mais sur 18.04 ça ne marche plus :(
-
Oh avant que t'arrive, je gérais ça via un joli chattr +i, mais sur 18.04 ça ne marche plus :(
Mais ca, c'était avant systemd
-
j'en reviens a regretter resolvconf (et pas resolv.conf!) c'est dire... :(
-
Bonjour,
Qu'en est-il de la gestion matérielle des derniers processeurs AMD RYZEN ? ou des derniers processeurs INTEL COFFEE LAKE ?
-
Mais ca, c'était avant systemd
Ah toi aussi, le monde merveilleux de Lennart Poettering te gave ?
(https://pix.milkywan.fr/1FlbtbcG.jpg)
;D
-
Bonjour,
Qu'en est-il de la gestion matérielle des derniers processeurs AMD RYZEN ? ou des derniers processeurs INTEL COFFEE LAKE ?
Le support des nouveaux matériels est un point fort d'Ubuntu par rapport à d'autres distribution et surtout FreeBSD.
AMD Ryzen et la 8ème génération d'Intel Core était déjà supporté par Ubuntu 16.04 avec le HWE Kernel (Linux 4.13) et même probablement avant.
Avec Ubuntu 18.05, on est sur un Kernel 4.15 qui intègre "Backport improved support for Intel hardware from Linux 4.16"
-
ça c'est vraiment infect, resolv.conf c'est juste méga pratique, là ça met un foutoir, aucune idée de comment on le gère (j'invoque Gaëtan encore une fois)
Est-il prévu que ces changements arrivent sur debian ou c'est spécifique à ubuntu ? Si sur les postes clients je m'en fou, sur serveur, moi aussi ça va bien me faire **** :'(
Déjà que j'arrive pas à me faire aux noms des interfaces, qu'est-ce que c'est indigeste... en plus je me goure toujours, je sais jamais si c'est enp2s0 ou enp0s2 ::)
Ce que je n'arrive pas à comprendre par contre c'est que lors d'une upgrade debian 8 > 9 les noms classiques sont conservés, j'ai toujours eth0,1,2... Donc en quoi est-il indispensable d'avoir ces noms à coucher dehors ?
-
Je préférais Unity personnellement :-[
La tout est plus difficile d'accès, exemple pour se connecter au wifi il faut cliquer en haut a droite puis sur wifi avant il y avait une icone directe pour cela. Pleins de petit trucs dans le même genre me gènes, seul bon point j'ai l'impression que l'autonomie de mon portable à gagné un quart d'heure (on passer d'1h15 a 1h30, c'est un "vieux" PC faut l’excuser)
Bref, je vais en profiter pour faire une pause d'Ubuntu stock et repasser sous Elementary OS
-
Ce que je n'arrive pas à comprendre par contre c'est que lors d'une upgrade debian 8 > 9 les noms classiques sont conservés, j'ai toujours eth0,1,2... Donc en quoi est-il indispensable d'avoir ces noms à coucher dehors ?
tout simplement parce que le fichier /etc/udev/rules.d/70-persistent-net.rules est conservé lors d'une upgrade. et tant que ça fonctionne, c'est de lui qu'on peut se servir pour renommer les interfaces ... enfin la je parle sous debian, mais ça doit être pareil sous Ubuntu.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="b0:48:7a:89:86:91", NAME="wlan1"
ici je me sers des MAC pour reconnaître les cartes, mais on peut se servir de plein d'autres trucs le vendorID, le productID etc etc
Jerem
-
Pourquoi ne pas virer simplement et rapidement l'ensemble des ces délires ?
Je m'en porte très bien.
aptitude purge systemd dbus network-manager avahi-daemon
14% [jack:~]grep "^GRUB_CMDLINE_LINUX_DEFAULT=" /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0 i915.enable_rc6=0"
-
Donc en quoi est-il indispensable d'avoir ces noms à coucher dehors ?
L'idée c'est d'avoir des noms prévisibles "Predictable Interface Names".
C'est vraiment un plus quand ta machine a beaucoup de cartes réseaux.
Au lieu de prendre Eth5, nom qui ne rime à rien, tu vas prendre la carte qui est sur le PCI 2 => enp2 port 0 => s0f0
Ce qui donne le nom enp2s0f0.
En regardant un graphe tu sais tout de suite de quel carte / port on parle :
(https://lafibre.info/images/stats/201802_ubuntu_if.png)
Maintenant, pour une machine avec deux cartes réseaux, c'est complétement inutile.
-
L'idée c'est d'avoir des noms prévisibles "Predictable Interface Names".
Officiellement, oui
Cela n'explique pas pourquoi il faut renommer: heureusement, il est possible et commun de changer un algorithme sans changer l'interface utilisateur
De plus, c'est une features complétement buggé: je me souviens d'Antho, par exemple, qui, malgré l'utilisation de tout ça, a déjà eu la bonne surprise de voir son mapping changé au reboot
Bref, c'est dla shit
-
Pourquoi ne pas virer simplement et rapidement l'ensemble des ces délires ?
Je m'en porte très bien.
aptitude purge systemd dbus network-manager avahi-daemon
14% [jack:~]grep "^GRUB_CMDLINE_LINUX_DEFAULT=" /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0 i915.enable_rc6=0"
Parce que c'est Legacy, autant vivre avec son temps.
-
C'est vraiment un plus quand ta machine a beaucoup de cartes réseaux.
j'ai arrêté de croire a cet argument le jour où systemd m'a renommé ma carte interne quand j'ai rajouté une carte 4*1G.
-
Parce que c'est Legacy, autant vivre avec son temps.
Oui.
systemd est né du fait que personne ne voulait continuer à maintenir les briques disparates que sont ConsoleKit,Polkit et consort.
-
Au lieu de prendre Eth5, nom qui ne rime à rien, tu vas prendre la carte qui est sur le PCI 2 => enp2 port 0 => s0f0
Ce qui donne le nom enp2s0f0.
Lol, ca c'est la théorie.
En pratique, voici un serveur avec 3 cartes réseau :
(https://pix.milkywan.fr/z3TDi11h.png)
eno{1-4} : ce sont bien les ports internes, pas de souci.
enp6s0f0 : premier port de la carte 4*1G
enp6s0f1 : second port de la carte 4*1G
enp7s0f0 : troisième port de la carte 4*1G (vous commencez a voir la blague?)
enp7s0f1 : quatrième port de la carte 4*1G (predictible my ass)
enp8s0f0 : premier port de la carte 2*10G (pourquoi pas)
enp8s0f1 : second port de la carte 2*10G
Un autre exemple :
(https://pix.milkywan.fr/agcrIgja.png)
enp5s0 : port interne (!?!) qui a été renommé, s'appelait avant enp4s0
enp4s4f0 : premier port de la carte 4*1G (on apprécie la prédictibilité)
enp4s4f1 : second port de la carte 4*1G
enp4s6f0 : troisième port de la carte 4*1G (pourquoi 6 ? allez savoir...)
enp4s6f1 : quatrième port de la carte 4*1G
Non franchement, l'idée est excellente, mais c'est un raté complet.
-
Parce que c'est Legacy, autant vivre avec son temps.
Virer un truc fonctionnel sous pretexte que "c'est vieux" pour le remplacer par un tas de merde qui lui, "est encore frais", voila bien une pratique que je ne valide pas :)
Oui.
systemd est né du fait que personne ne voulait continuer à maintenir les briques disparates que sont ConsoleKit,Polkit et consort.
Marrant, c'est fait par les mêmes mecs.
Ils ont fait une belle merde, et plutôt que de maintenir / fix, hop, yaka mettre à la poubelle et refaire un nouveau délire.
Finalement, c'est très classique du dev nodejs lambda: affligeant;
j'ai arrêté de croire a cet argument le jour où systemd m'a renommé ma carte interne quand j'ai rajouté une carte 4*1G.
Bawi
De même que le tracking de processus, l'un des gros trucs qui a servi à vendre systemd ("ouais mais avec bash tu peux 'perdre' des processus alors que systemd, ben avec les cgroups, ben tu ne peux pas ! t'es certain qu'un machin qui est stop est vraiment stop") ne fonctionne tout simplement pas: entre "sisi le process est running, voila son PID" (et le process en question est mort depuis longtemps, donc systemd attends de kill un process déjà mort #genius) et le "sisi, j'ai vérifié, le process mysql est mort !" (et quand tu te connectes en SQL sur le serveur, visiblement quelqu'un répond, et visiblement c'est un serveur SQL, NOT SO DEAD NOW HUM ?")
Bref, dla shit à tout les étages, les virer est toujours la bonne pratique.
-
Virer un truc fonctionnel sous pretexte que "c'est vieux" pour le remplacer par un tas de merde qui lui, "est encore frais", voila bien une pratique que je ne valide pas :)
Le truc fonctionnel ne le sera bientôt plus, ce n'est pas un choix, le supprimer n'est pas (bientôt plus pour être exact) une option.
-
Le truc fonctionnel ne le sera bientôt plus, ce n'est pas un choix, le supprimer n'est pas (bientôt plus pour être exact) une option.
De quoi parles-tu, précisement ? le yaml d'ubuntu ?
-
utiliser sysvinit ou consorts à la place de systemd.
-
utiliser sysvinit ou consorts à la place de systemd.
Source ?
-
internet...
-
Oki :p
-
eno{1-4} : ce sont bien les ports internes, pas de souci.
enp6s0f0 : premier port de la carte 4*1G
enp6s0f1 : second port de la carte 4*1G
enp7s0f0 : troisième port de la carte 4*1G (vous commencez a voir la blague?)
enp7s0f1 : quatrième port de la carte 4*1G (predictible my ass)
enp8s0f0 : premier port de la carte 2*10G (pourquoi pas)
enp8s0f1 : second port de la carte 2*10G
En vrai c'est pas surprenant, c'est numéroté en fonction des bus PCI-E, pas d'un emplacement physique.
Après si le BIOS change les bus quand tu ajoutes/retires des cartes...
-
@jack, tu peux encore utiliser Devuan ou Slackware si tu n'aimes pas systemd.
Mais il ne te reste pas longtemps à vivre :-\
-
tout simplement parce que le fichier /etc/udev/rules.d/70-persistent-net.rules est conservé lors d'une upgrade. et tant que ça fonctionne, c'est de lui qu'on peut se servir pour renommer les interfaces ... enfin la je parle sous debian, mais ça doit être pareil sous Ubuntu.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="b0:48:7a:89:86:91", NAME="wlan1"
ici je me sers des MAC pour reconnaître les cartes, mais on peut se servir de plein d'autres trucs le vendorID, le productID etc etc
C'est bon à savoir. Je viens de tester sur Xubuntu 18.04 : ça fonctionne encore :D
Par contre ça modifie les ipv6, aussi bien la locale que les globales.
-
@jack, tu peux encore utiliser Devuan ou Slackware si tu n'aimes pas systemd.
Mais il ne te reste pas longtemps à vivre :-\
Non merci, j'utilise Debian qui est très bien :p
D'ailleurs, pour la route: https://www.debian.org/vote/2014/vote_003
-
Résultat, plus rien dans network/interfaces, tout dans netplan.
Côté resolv, la même chose, géré par systemd-resolve avec la conf DNS en fixe et la conf DNS via les int. (Me reste à faire l'intégration dans Ansible :) ).
On peut même plus toucher le resolv.conf, systemd écrase la conf avec la sienne derrière.
A noter que pour une mise à jour, netplan n'est pas utilisé.
C'est toujours le fichier /etc/network/interfaces qui est utilisé.
Effectivement, comme Netplan est utilisé à l'installation...
Edit the /etc/default/grub file
sudo nano /etc/default/grub
Add the following line
GRUB_CMDLINE_LINUX="netcfg/do_not_use_netplan=true"
http://www.ubuntugeek.com/disable-netplan-on-ubuntu-17-10.html
J'ai l'impression que c'est encore systemd qui s'infiltre un peu plus dans le système...
Mon serveur mis à jour vers Ubuntu 18.04 n'utilise pas netplan et rien n'a été rajouté dans /etc/default/grub :
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"