Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#51 Le 11/11/2018, à 23:36

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Est-ce qu'il peut être intéressant/inutile de tenter de forcer vers la génération de noyau suivante (4.18) ?

Hors ligne

#52 Le 12/11/2018, à 07:50

moko138

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Depuis 18.04, quel est le retour de

echo; echo 'Gestionnaire(s) de connexion installé(s) :'; which gdm gdm3 kdm lightdm lxdm mdm sddm slim wdm xdm ; echo; echo 'Et le gestionnaire de connexion par défaut est :' ; cat /etc/X11/default-display-manager

?

  - -

En #41, Hieldayn a écrit :

je suis allé voir comment mon bios détecte mes disques
    - Ch0 : c'est mon vieux disque IDE sur lequel j'ai mis les partitions swap, /tmp et /var/log de ma 18.04, que le bios doit voir comme hd0

Hou là ! Ça en fait des pistes !
- Le mélange IDE / Sata
j'ai un vague et vieux souvenir que ça nécessitait je ne sais plus quel réglage (d'AHCI ?) pour éviter les ennuis ;


- Utiliser une partition swap plutôt qu'un fichier swap,
dans 18.04, je ne suis pas sûr que ce soit encore le meilleur choix ;


- Utiliser une partition /tmp sur un disque différent de celui accueillant la racine,
j'en vois encore moins l'intérêt. /tmp sert peu (sauf si on passe son temps à ouvrir de grosses archives). Par contre, (du moins dans ma 14.04) le dossier /tmp/ héberge dès le démarrage deux éléments de l'affichage (le dossier .X11-unix et le fichier .X0-lock). Or c'est l'affichage qui merdoie.


- De plus, voici le fstab de 18.04 :

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdc1 during installation
UUID=1330d914-0909-4402-8aea-a4af18c13486 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sdc2 during installation
UUID=2cb66d54-667a-40ac-a897-53dce05a45c6 /home           ext4    defaults        0       2
# /tmp was on /dev/sda1 during installation
UUID=1d80d655-1f4d-4256-af83-c4e75299064c /tmp            ext4    defaults        0       2
# /var/log was on /dev/sda2 during installation
UUID=0f4758f2-8c63-405e-8be5-fbdb4a89afed /var/log        ext4    defaults        0       2
# swap was on /dev/sda3 during installation
UUID=b28adb70-f1d4-4a00-be08-5b8e6eea1bfc none            swap    sw              0       0

# Disque de Données (était /dev/sdd1)
UUID=3b3b9d07-7bdd-4b91-8433-c836521be4a1 /media/data       ext4    defaults        0       2

Il ne comprend aucun nofail. On pourrait pourtant mettre l'option nofail à toutes les partitions autres que la racine.
A fortiori avec des partitions déportées sur un autre disque que celui de la racine.
A fortiori si ce disque est IDE au sein d'un mélange IDE/Sata.


- Enfin, on sait que les vieux bios peuvent intervertir facilement les disques. Alors peut-être cela nécessite-t-il une précaution ? Peut-être introduire du "rootdelay" ?


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#53 Le 12/11/2018, à 11:42

Babdu89

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Bonjour.
@moko138.
Rappel quand même.
La 18.04 démarre et fonctionne bien lancée depuis le menu Grub de la 16.04, depuis son disque d'installation.
Depuis le menu Grub de la 18.04 lancée depuis son disque d'installation Elle démarre fonctionne jusqu’à ce qu'une application soit lancée, là çà ,freez.

Il me semble quand même que le fstab de la 18.04 est utilisé aussi bien lancée, depuis la 16.04 ou la 18.04 ?.

Inversion des disques.
lancement depuis la 16.04 , quel que soit le /dev/sd*1, çà fonctionne; alors ?.

@+.    Babdu89   .

Dernière modification par Babdu89 (Le 12/11/2018, à 11:43)


J'ai découvert Ubuntu avec la 07.10.... Et alors?!...  Depuis je regarde de temps en temps si Windows marche toujours....

Hors ligne

#54 Le 12/11/2018, à 19:06

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Salut,

Badbu89 : j'allais dire la même chose, comme pour le fait d'installer les drivers : j'ai un cas qui, quand lancé depuis le GRUB de la 16.04, fonctionne parfaitement, ... Mais c'est bien la 18.04 qui est lancée, avec son FSTAB, son montage, ses drivers pas installés, etc ...
J'aurais pas ce démarrage nickel dans ce cas, j'aurais tenté plein de trucs, mais là, ça me fait vraiment hésiter, parce que ça risquerait même de faire sauter ce qui marche...

[HS] : Au fait Badbu 89, avant que j'oublie : même si tu sèche, j'apprécie tes efforts, tes tests et tes idées, et je t'en remercie chaleureusement cool [/HS]

@moko138

Quoi qu'il arrive, il y a des trucs qui m'intéressent vachement dans ce que tu dis :

Déjà :

hieldayn@bureau:~$ echo; echo 'Gestionnaire(s) de connexion installé(s) :'; which gdm gdm3 kdm lightdm lxdm mdm sddm slim wdm xdm ; echo; echo 'Et le gestionnaire de connexion par défaut est :' ; cat /etc/X11/default-display-manager

Gestionnaire(s) de connexion installé(s) :
/usr/sbin/gdm3

Et le gestionnaire de connexion par défaut est :
/usr/sbin/gdm3
hieldayn@bureau:~$ 

Donc j'ai pas dis de connerie sur ce point pour le moment big_smile

moko138 a écrit :

- Utiliser une partition swap plutôt qu'un fichier swap,
dans 18.04, je ne suis pas sûr que ce soit encore le meilleur choix ;

J'ai lu ça aussi, récemment, même si j'ai fait mon install avant de le lire.
Au pire ça se modifie, c'est pas trop le problème...
Cependant, j'ai une vieille machine, avec seulement 4 Go de RAM, et je tiens à préserver mon SSD système (des vieux disques, à la limite, j'en ai suffisamment pour en cramer si besoin).
Ça serait quoi ton conseil alternatif ? (je sais que les avis divergent, mais ton opinion m'intéresse, après, je ferai mon choix comme un grand)

moko138 a écrit :

- Utiliser une partition /tmp sur un disque différent de celui accueillant la racine,
j'en vois encore moins l'intérêt. /tmp sert peu (sauf si on passe son temps à ouvrir de grosses archives). [...]

J'ai peut-être trop l'expérience de Windows au boulot et pas assez regardé comment moulinait Linux, mais je croyais que tout ce qui se charge pendant l'utilisation d'un programme se faisait pas mal en temporaire, jusqu'à ce qu'on sauvegarde (grosso-modo, et pour rester simpliste), genre ce qu'on fait en traitement de texte, tableur, firefox, etc... et qu'à la sauvegarde on écrit en "dur" pour remplacer le fichier... Ce qui alors fait pas mal d'écriture, et je voulais préserver le SSD de ça (sans pour autant le mettre en RAM et risquer de tout perdre en cas de plantage).

Si tu veux bien me fournir de l'info (un lien vers de la doc, par exemple), je serai ravi de revoir ma copie.

moko138 a écrit :

[...] Par contre, (du moins dans ma 14.04) le dossier /tmp/ héberge dès le démarrage deux éléments de l'affichage (le dossier .X11-unix et le fichier .X0-lock). Or c'est l'affichage qui merdoie.

Je vois bien le dossier ".X11-unix" et dedans éventuellement j'ai bien un fichier "X0" et un autre "X1" mais pas de ".X0-lock (et je suis actuellement en 18.04, quand elle fonctionne)


Après, quitte à de toute façon avoir une partoche à part pour /var/log, autant coller par là aussi tout ce qui peut faire de l'écriture inutile au SSD...?

moko138 a écrit :

- Enfin, on sait que les vieux bios peuvent intervertir facilement les disques. Alors peut-être cela nécessite-t-il une précaution ? Peut-être introduire du "rootdelay" ?

Ben j'ai vu que les UUID pour le démarrage, FSTAB et autre, ça fait bien son boulot, et faut savoir que quand j'ai installé, j'ai démarré sur le Live (qui a eu à ce moment la détection des disques que j'ai en ce moment, j'ai encore rien changé), et le démarrage depuis la 16.04 fonctionne, alors qu'à son époque il n'a jamais eu le disque que j'ai utilisé pour la 18.04...

Donc récemment j'ai fait un "update-grub" dans la 16.04, il m'a détecté la 18.04, mais il n'y a eu aucune inversion des disques depuis le début de l'histoire de la 18.04 (début Août, si je dis pas d'ânerie)... Alors que la 16.04, elle, elle a vu disqparaître le disque de l'UbuntuStudio 16.04, apparaître celui de la 18.04; et elle me la démarre bien...

Dernière modification par Hieldayn (Le 12/11/2018, à 19:18)

Hors ligne

#55 Le 13/11/2018, à 23:49

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Bonsoir,

Pour continuer de creuser avec ma maigre compréhension de tout ça, j'ai essayé de comprendre au moins quoi chercher et où chercher.

Pour générer le fichier /boot/grub/grub.cfg, ça part des fichiers dans /etc/grub.d, j'ai feuilleté celui qui aurait mis ma 18.04 en tête, c'est à dire "10_linux"

Je n'ai trouvé que ce passage avec pour cause "recordfail" :

if [ "\${recordfail}" != 1 ]; then
  if [ -e \${prefix}/gfxblacklist.txt ]; then
    if hwmatch \${prefix}/gfxblacklist.txt 3; then
      if [ \${match} = 0 ]; then
        set linux_gfx_mode=keep
      else
        set linux_gfx_mode=text
      fi
    else
      set linux_gfx_mode=text
    fi
  else
    set linux_gfx_mode=keep
  fi
else
  set linux_gfx_mode=text
fi
EOF
fi

Donc en cherchant autour de ça ("linux_gfx_mode", le fait que quand ça marche j'ai un affichage plutôt "texte" et quand ça marche pas le texte qui défile a l'air plus "sexy" graphiquement comme si utilisant des ressources de gestion graphique plus performantes), je suis passé par des sites intéressant, dont celui-ci (qui date un peu mais qui est super intéressant sans trop entrer dans le détail), et dans lequel ça parle d'emplacements de fichiers pour d'autres paramétrages dans /usr/share/grub/

Sauf qu'en allant voir ça par curiosité, je vois qu'il existe une autre dossier :/usr/share/grub-gfxpayload-lists/blacklist/

Je suis allé voir le contenu des fichiers, et dans "00_header", je lis ça :

#[...] If you need to disable
# gfxpayload=keep on your system, just add this line (uncommented) to
# /etc/default/grub:
#
#   GRUB_GFXPAYLOAD_LINUX=text

Donc ne prenant pas trop de risque, j'ai tenté d'éditer /etc/default/grub, d'enlever "nomodeset" et d'ajouter cette ligne => update-grub => redémarrage sur le disque de la 18.04...

=> Bon, sans "nomodeset", ça a quand même pas démarré, donc redémarrage et ajout temporaire en éditant la ligne.

ça démarre, mais soucieux de corriger mon erreur, j'édite toute de suite /etc/default/grub et je remets "nomodeset" => update-grub
=> par contre, à ce moment précis le système a basculé tout seul sur le terminal virtuel 1 et au lieu d'y trouver GDM j'y ai trouvé du texte avec entre autre sur la dernière ligne un message (que je n'ai bêtement pas pris le temps de recopier) mais qui parlait d'un "HALD until boot finished"... et un curseu clignotant
=> Mais le retour en session graphique sur le VT2 fonctionne très bien... Donc j'ai vu que l'update-grub était fini, j'ai redémarré.

Donc avec "nomodeset" et avec "GRUB_GFXPAYLOAD_LINUX=text" dans /etc/default/grub
=> Démarrage OK (gros caractères)
=> ça ne freeze pas en lançant FIREFOX
=> J'ai bien GDM en VT1 et je passe bien sur VT2 sans soucis...
=> Tout paraît comme quand je boot depuis la 16.04

Avec 1 démarrage OK juste après un espèce d'échec, je redémarre
=> OK

Je recommence
=> OK
    Par contre, là, j'ai vu des lignes de texte apparaître très rapidement, j'ai eu le temps de lire un truc du genre

[FAILED] Failed to mount gtk-common-themes ... 

Mais pas pu lire plus et ça a fini de démarrer...

=> Malgré ça, c'est OK : je suis dessus en ce moment...

Hors ligne

#56 Le 14/11/2018, à 19:22

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Encore ce soir, je démarre dessus sans problème.

Donc :
    - avec "nomodeset" pour pouvoir démarrer tout court
    - Et avec cette ligne  "GRUB_GFXPAYLOAD_LINUX=text" dans /etc/default/grub pour que ça ne freeze pas après démarrage...


Donc j'en conclue (ce qui n'engage que moi) qu'il y a bien une manière de passer des paramètres entre GRUB et la distrib...
Et que c'est géré différemment entre le GRUB (selon la version) de la 16.04 et celui de la 18.04...
Et que cela va au-delà du simple démarrage : cela peut avoir des conséquences sur le système une fois démarré...

Mais j'aimerais bien savoir pourquoi, et si ça va pouvoir éventuellement se résoudre ou non avec le déploiement du noyau 4.18 (et une nouvelle version de GRUB ??) lors de la release de la 18.04.2 en février 2019...

Hors ligne

#57 Le 14/11/2018, à 19:38

moko138

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Hieldayn a écrit :

Donc j'en conclus (...) qu'il y a bien une manière de passer des paramètres entre GRUB et la distrib...
Et que cela va au-delà du simple démarrage : cela peut avoir des conséquences sur le système une fois démarré...

Certes ! Chaque fois qu'on a besoin de "nomodeset" ou de "blacklist-trucmuche", ça l'illustre.
Mais ceci :

Et que c'est géré différemment entre le GRUB (selon la version) de la 16.04 et celui de la 18.04...

est une nouveauté. Et tu me l'apprends.


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#58 Le 14/11/2018, à 20:19

moko138

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

J'avais commencé une réponse ce matin, la voici terminée :

a) Ta 18.04 a un seul gestionnaire de connexion installé, c'est bon.


b) Limiter l'utilisation de la swap
J'espère que ton swappiness (cf. §"Améliorer l'utilisation du fichier d'échange (swap)") est réglé aux alentours de 5.

c)

Ça serait quoi ton conseil alternatif ?

Ce que je t'ai dit :
- nofail partout (sauf pour la racine) ;
- pas de /tmp séparé. (Pour être fixé, tu n'as qu'à surveiller l'évolution de son poids et des dates de modif').
Donc

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdc1 during installation
UUID=1330d914-0909-4402-8aea-a4af18c13486 /            ext4    errors=remount-ro  0  1
# /home was on /dev/sdc2 during installation
UUID=2cb66d54-667a-40ac-a897-53dce05a45c6 /home         ext4    defaults,nofail  0  2
# /tmp was on /dev/sda1 during installation
### UUID=1d80d655-1f4d-4256-af83-c4e75299064c /tmp      ext4    defaults,nofail  0  2
# /var/log was on /dev/sda2 during installation
UUID=0f4758f2-8c63-405e-8be5-fbdb4a89afed /var/log      ext4    defaults,nofail  0  2
# swap was on /dev/sda3 during installation
UUID=b28adb70-f1d4-4a00-be08-5b8e6eea1bfc none           swap    sw,nofail      0  0

# Disque de Données (était /dev/sdd1)
UUID=3b3b9d07-7bdd-4b91-8433-c836521be4a1 /media/data     ext4    defaults,nofail   0  2

De plus, je n'y avais pas songé avant, mais les options "defaults" (c'est-à-dire rw,suid,dev,exec,auto,nouser,async) ne sont peut-être pas les plus adaptées à /tmp/. Mais je n'ai pas approfondi la question.

= =

J'ajoute que tu devrais t'intéresser (sauf pour la partition-swap) à

sudo tune2fs -l /dev/sdxn | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#59 Le 15/11/2018, à 00:04

Babdu89

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Bonsoir.

Et que c'est géré différemment entre le GRUB (selon la version) de la 16.04 et celui de la 18.04...

moko138 a écrit.

est une nouveauté. Et tu me l'apprends.

Je n'en parlais pas pour le moment, pour ne pas embrouiller l'affaire...
Mais chez moi, je constate ceci.

La version de Grub de la 12.04  (grub modifié personnalisé, par mes soins pour savoir ce que je lance depuis une machine avec 4 disques interne, ou j'ai pas mal d'installations de tests.).

Les installations de 2 Ubuntu 18.04 installés dans cette machine, depuis le grub (menu grub modifié) de la 12.04, ne démarrent pas...

Les menu grub (donc les grub) des 14.04 gèrent mieux, les 18.04 démarrent.

Je vais recherche les retours des maj de grub de la 12.04, et les menuentry dans la rubrique /etc/grub.d/30_os-prober qui ne démarrent pas, et les poster...
À suivre...

@+.  Babdu89  .

Dernière modification par Babdu89 (Le 15/11/2018, à 00:05)


J'ai découvert Ubuntu avec la 07.10.... Et alors?!...  Depuis je regarde de temps en temps si Windows marche toujours....

Hors ligne

#60 Le 15/11/2018, à 00:35

Babdu89

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Alors voila ce que donne la maj de grub de la 12.04, pour la 18.04.

Found Ubuntu 18.04 LTS (18.04) on /dev/sde13
/usr/sbin/grub-probe : erreur : unknown filesystem.

Voila le menuentry dans 30_os-prober du grub.cfg de la 12.04.

menuentry "Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-9d044740-d68d-4898-b8fd-b1a7aee967eb (on /dev/sde13)" --class gnu-linux --class gnu --class os {
	savedefault
	insmod part_msdos
	linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro quiet splash $vt_handoff
	initrd /boot/initrd.img-4.15.0-20-generic
}
menuentry "Ubuntu, avec Linux 4.15.0-20-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-20-generic-advanced-9d044740-d68d-4898-b8fd-b1a7aee967eb (on /dev/sde13)" --class gnu-linux --class gnu --class os {
	savedefault
	insmod part_msdos
	linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro quiet splash $vt_handoff
	initrd /boot/initrd.img-4.15.0-20-generic
}
menuentry "Ubuntu, with Linux 4.15.0-20-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-20-generic-recovery-9d044740-d68d-4898-b8fd-b1a7aee967eb (on /dev/sde13)" --class gnu-linux --class gnu --class os {
	savedefault
	insmod part_msdos
	linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro recovery nomodeset
	initrd /boot/initrd.img-4.15.0-20-generic
}

Çà ne démarre pas.


Maintenant avec le grub d'une des 14.04, la maj de grub 14.04

Ubuntu 18.04 LTS (18.04) trouvé sur /dev/sdd13

Voila le menuentry dans la rubrique 30_os-prober du grub.cfg de la 14.04.

menuentry 'Ubuntu 18.04 LTS (18.04) (sur /dev/sdd13)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-9d044740-d68d-4898-b8fd-b1a7aee967eb' {
	insmod part_msdos
	insmod ext2
	set root='hd3,msdos13'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos13 --hint-efi=hd3,msdos13 --hint-baremetal=ahci3,msdos13  9d044740-d68d-4898-b8fd-b1a7aee967eb
	else
	  search --no-floppy --fs-uuid --set=root 9d044740-d68d-4898-b8fd-b1a7aee967eb
	fi
	linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro quiet splash $vt_handoff
	initrd /boot/initrd.img-4.15.0-20-generic
}
submenu 'Options avancées pour Ubuntu 18.04 LTS (18.04) (sur /dev/sdd13)' $menuentry_id_option 'osprober-gnulinux-advanced-9d044740-d68d-4898-b8fd-b1a7aee967eb' {
	menuentry 'Ubuntu (sur /dev/sdd13)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.15.0-20-generic--9d044740-d68d-4898-b8fd-b1a7aee967eb' {
		insmod part_msdos
		insmod ext2
		set root='hd3,msdos13'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos13 --hint-efi=hd3,msdos13 --hint-baremetal=ahci3,msdos13  9d044740-d68d-4898-b8fd-b1a7aee967eb
		else
		  search --no-floppy --fs-uuid --set=root 9d044740-d68d-4898-b8fd-b1a7aee967eb
		fi
		linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro quiet splash $vt_handoff
		initrd /boot/initrd.img-4.15.0-20-generic
	}
	menuentry 'Ubuntu, avec Linux 4.15.0-20-generic (sur /dev/sdd13)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.15.0-20-generic--9d044740-d68d-4898-b8fd-b1a7aee967eb' {
		insmod part_msdos
		insmod ext2
		set root='hd3,msdos13'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos13 --hint-efi=hd3,msdos13 --hint-baremetal=ahci3,msdos13  9d044740-d68d-4898-b8fd-b1a7aee967eb
		else
		  search --no-floppy --fs-uuid --set=root 9d044740-d68d-4898-b8fd-b1a7aee967eb
		fi
		linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro quiet splash $vt_handoff
		initrd /boot/initrd.img-4.15.0-20-generic
	}
	menuentry 'Ubuntu, with Linux 4.15.0-20-generic (recovery mode) (sur /dev/sdd13)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.15.0-20-generic-root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro recovery nomodeset-9d044740-d68d-4898-b8fd-b1a7aee967eb' {
		insmod part_msdos
		insmod ext2
		set root='hd3,msdos13'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos13 --hint-efi=hd3,msdos13 --hint-baremetal=ahci3,msdos13  9d044740-d68d-4898-b8fd-b1a7aee967eb
		else
		  search --no-floppy --fs-uuid --set=root 9d044740-d68d-4898-b8fd-b1a7aee967eb
		fi
		linux /boot/vmlinuz-4.15.0-20-generic root=UUID=9d044740-d68d-4898-b8fd-b1a7aee967eb ro recovery nomodeset
		initrd /boot/initrd.img-4.15.0-20-generic
	}

Çà démarre.

Je n'ai pas encore tester la copie de ce menuentry dans le grub.cfg rubrique 30_os-prober de la 12.04, pour voir si çà démarre la 18.04...
Faut que je teste çà.

Édit
Non,non,çà ne marche pas, l'écriture des menuentry de la 14.04 ne convient pas à la 12.04.il n'y a pas affichage.

C'est ce qui m'a pousser à m'intéresser à ce sujet...

@+.   Babdu89  .

Dernière modification par Babdu89 (Le 15/11/2018, à 09:33)


J'ai découvert Ubuntu avec la 07.10.... Et alors?!...  Depuis je regarde de temps en temps si Windows marche toujours....

Hors ligne

#61 Le 15/11/2018, à 04:35

moko138

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

[HS]

Babdu89 a écrit :

voila ce que donne la maj de grub de la 12.04, pour la 18.04.

Found Ubuntu 18.04 LTS (18.04) on /dev/sde13
/usr/sbin/grub-probe : erreur : unknown filesystem.

N'oublie pas que 16.04 et les versions suivantes intègrent une modification d'ext4 qui le rend illisible par 14.04 et les versions antérieures :

/dev/sda3 a une(des) fonctionnalité(s) non supportée(s) : metadata_csum

Pour que jeange (#218) puisse partager entre 14.04 et 18.04 une partition ext4 de données, j'ai dû :
- lui faire supprimer la partition de données ;
- la lui faire refaire à partir de 14.04 ;
- interdire (avec tune2fs) les fsck automatiques sur cette partition de données ;
- prescrire des fsck manuels périodiques lancés uniquement depuis 14.04.
              [HS]


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#62 Le 15/11/2018, à 19:19

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Salut,

@moko138   
    b) : elle est par défaut, à 60...  C'est vrai que j'avais changé ça à 5 sur ma 16.04, autant le faire ici aussi.
PS : c'est fait.
    De là à la passer en fichier sur /, sincèrement je pense que je vais garder ma pauvre partoche de pauvre disque smile

    c) : Nofail : je me le note, je le ferai.
    Pour /tmp, en effet, je me mets tes propositions sous le coude, je vais surveiller ça et en effet adapter si ça correspond à mon utilisation.
    Je savais que je me "compliquais" un peu l'histoire avec cet ajout de disque et de partoches en plus, mais bon... Faut que je me fasse mon idée.

Merci en tout cas pour tes explications.

Sauf que je ne vois pas à quoi je dois m'intéresser avec

sudo tune2fs -l /dev/sdxn | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"

parce que ça me sort ça :

hieldayn@bureau:~$ sudo tune2fs -l /dev/sdc1 | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"
Filesystem created:       Sat Sep  1 11:31:53 2018
Mount count:              191
Maximum mount count:      -1
Last checked:             Sat Sep  1 11:31:53 2018
Check interval:           0 (<none>)
hieldayn@bureau:~$ sudo tune2fs -l /dev/sda1 | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"
Filesystem created:       Sat Sep  1 11:31:38 2018
Mount count:              190
Maximum mount count:      -1
Last checked:             Sat Sep  1 11:31:38 2018
Check interval:           0 (<none>)
hieldayn@bureau:~$

mais je ne vois pas trop l'info utile...
Si : mea culpa : j'ai commencé mon install le 1er Septembre, et non en Août comme je le croyais lol wink

Blague à part : tu penses que je dois surveiller quoi avec cette commande ?
   
   
@Badbu89
Il a l'air d'y avoir un lien entre les générations de GRUB et les générations de noyaux...
Après tout, c'est pas forcément surprenant... Mais que celui de la 16.04 et celui de la 18.04 aient tant à être bricolés d'options pour lancer un système, je suis quand même étonné.

Quand tu veux mixer du 12.04 et 18.04, je te trouve ambitieux, quand même big_smile

Devoir utiliser "nomodeset" qui est pas loin d'un démarrage en mode "recovery", c'est déjà gros...
Mais entrer en plus des paramètres un peu "old school" de démarrage en mode texte (et non graphique), c'est particulièrement étonnant... parce qu'entre 16.04 et 18.04, au final, je suis toujours avec Xorg, pas avec Wayland, donc entre les 2 on ne devrait pas perdre de compatibilité...

OK, OK, j'ai une NVidia, j'ai un vieux matériel, tout ça, tout ça... mais je trouve ça surprenant quand même (peut-être tout simplement que c'est parce que c'est à un niveau de profondeur informatique qui me dépasse allègrement...)

Hors ligne

#63 Le 08/01/2019, à 19:03

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Bonjour à tous,

Nouvelle expérimentation et info intéressante :

Avec ce démarrage qui arrive à fonctionner grâce à "nomodeset" et GRUB_GFXPAYLOAD_LINUX=text dans /etc/default/grub , j'ai voulu faire du propre dans mon PC.

J'ai pu enlever le disque de la 16.04, et remettre le disque avec la Xubuntu Studio 16.04 qui me manquait.
Au passage, j'ai aussi passé mes données sur un nouveau disque de 1To partitionné en 2 et mon disque de sauvegarde sur un 500 Go parce que je commençais à être un peu limite-limite... Mais peu importe, pas d'incidence, et çà s'est bien passé, avec les modifs de fstab et tout ça...

J'ai donc ensuite démarré sur la 18.04, fait un update-grub pour qu'il détecte Studio, et redémarré dessus. Pas de problème.

J'ai vu que j'avais de vieux noyaux (4.10) et un plus récent (4.13), mais qu'à cela ne tienne, je fais une mise à jour, parce que je l'avais enlevé depuis un moment et que ça méritait...

50 minutes plus tard, me voilà avec une Ubuntu Studio dernier cri, 16.04.5 avec un noyau 4.15.0-43 (le même que sous 18.04 !?!).

Bon, je redémarre sous 18.04, pas de soucis, normal, donc je fais un petit update-grub pour détecter le démarrage possible sous Studio par son nouveau noyau, et je m'en vais...

Sauf qu'après je veux aller sur Studio, donc démarrage avec dans le bios le disque déclaré étant celui de la 18.04, là j'ai Grub, donc je sélectionne "Ubuntu 16.04.5"... mais ça ne démarre pas...

Je relance, et cette fois j'édite la ligne de la Studio : il n'y a pas "nomodeset"...
Je l'ajoute et je lance : ça marche !

Or je n'en avais pas eu besoin avant...

Donc avec le Grub de la 18.04 (version 2.02-2ubuntu8.9) et lancement du Noyau d'Ubuntu Studio en 4.13, ça marche, mais avec le 4.15 (comme pour 18.04), ben ça ne démarre pas, obligé de glisser un "nomodeset"...

Donc je pense confirmer que les noyaux > 4.13 ne reçoivent pas les mêmes infos de démarrage depuis grub, ça serait donc plausiblement plus un problème de noyau que de Grub...

J'attends donc impatiemment le passage en 4.18 de février pour tester, par contre, j'ai quand même une question pour vous :
     => comment puis-je dire à ma 18.04 de mettre "nomodeset" pour démarrer aussi mon Ubuntu Studio lors d'un update-grub parce que pour le moment je suis obligé de me taper l'édition de la ligne a la mano à chaque fois, or ce n'est pas assez "friendly-user" à mon goût pour que mon fils de 12 ans puisse le lancer sans éditer des lignes de grub systématiquement et risquer de me mette le bronx ... ??

NB : J'ai essayé d'éditer /etc/default/grub et de mettre GRUB_CMDLINE_LINUX="nomodeset", mais ça n'a pas marché (même si je savais que ce n'est à priori pas la meilleur des idées)

Hors ligne

#64 Le 26/01/2019, à 09:35

moko138

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Le 14/11, bibi a écrit :

tu devrais t'intéresser (sauf pour la partition-swap) à

sudo tune2fs -l /dev/sdxn | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"

Je suis désolé, je n'avais pas vu sad ta réponse du 15/11/2018 :

Hieldayn a écrit :

@moko138   
je ne vois pas à quoi je dois m'intéresser avec

sudo tune2fs -l /dev/sdxn | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"

parce que ça me sort ça :

hieldayn@bureau:~$ sudo tune2fs -l /dev/sdc1 | grep -Ei "Mount count|Maximum mount|Filesystem created|Last checked|Check interval"
Filesystem created:       Sat Sep  1 11:31:53 2018
Mount count:              191
Maximum mount count:      -1
Last checked:             Sat Sep  1 11:31:53 2018
Check interval:           0 (<none>)
hieldayn@bureau:~$ 

mais je ne vois pas trop l'info utile (...) tu penses que je dois surveiller quoi avec cette commande ?

Cette commande montre le réglage de ne jamais vérifier (sauf en sortie de crash) le système de fichiers (FS) de la partition sdxn !

Maximum mount count:      -1         # Ni tous les c montages,
Check interval:           0 (<none>)  # Ni tous les i jours.

Quel est le risque ?

man tune2fs
                              vous risquez d'aboutir à des corruptions silen‐
              cieuses du système de  fichiers  en  cas  de  défauts  dans  les
              disques, câbles, mémoires ou dans la conception du noyau et vous
              ne vous en apercevrez que lorsqu'il sera  trop  tard,  après  la
              perte des données.

  Il faut toutefois distinguer deux cas.


A) Cas des partitions partagées de données
  Cette interdiction des vérifications automatiques est, paradoxalement, correcte et même nécessaire sur les partitions en ext4 (de données) partagées entre plusieurs Linux de générations différentes (typiquement *buntu 14.04 et 18.04).
Mais il est tout aussi nécessaire de lancer périodiquement à la main la vérification depuis le Linux le plus ancien !
    Pour les explications,
le risque de l'automatisation est exposé plus haut en #61
et une solution en ./viewtopic.php?pid=21982840#p21982840 à partir de "Ce qui me soucie".

- -

B) Cas des partitions-systèmes
  Cette interdiction des vérifications automatiques, sur les partitions-systèmes (/, /var/ ou /var/log...) étant absurde et dangereuse, on appliquera aux partitions-systèmes :

man tune2fs
              Il est vivement recommandé d'activer soit -c (limite  en  nombre
              de  montages) soit -i (limite en temps) pour que e2fsck(8) véri‐
              fie régulièrement et complètement le système de  fichiers.  

Par exemple :

sudo tune2fs -c 10 -i 7d <chaque partition-système>

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#65 Le 26/01/2019, à 10:58

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Merci Moko !
Je m'étais bien dit que tu n'avais pas vu, et que tu étais sûrement passé à autre chose, c'était pas grave.

Tes explications sont bien notées et mises en œuvre sur mes partitions /, /tmp et /var/log.
En plus du "nofail" sur les points de montage autres que "/" dans fstab et que je n'avais pas encore pris le temps de faire.

Je pense que je ramènerai les /tmp (34Mo actuellement) et /var/log (1 Go) sur la même partition que / dans mes prochaines installations en prévoyant plus de place sur cette partition, C'est plus simple. Après tout si je laisse bien de la place, ça ne réécrira pas tout le temps les mêmes clusters, l'usure devrait être limitée...

Merci encore pour les explications !

Hors ligne

#66 Le 26/01/2019, à 19:25

moko138

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Hieldayn a écrit :

Je pense que je ramènerai les /tmp (34Mo actuellement) et /var/log (1 Go) sur la même partition que / dans mes prochaines installations (...) Après tout si je laisse bien de la place, ça ne réécrira pas tout le temps les mêmes clusters,

1) Sur un ssd bien fait (ça dépend beaucoup du sérieux avec lequel le constructeur fait le micrologiciel) le nivelage d'usure fonctionne, bien, d'autant plus que les limites de partitions sont, sur un ssd, virtuelles.

2) Pour /tmp, pas d'objection

3) Par contre, remettre /var/log sur le ssd me semble une très mauvaise idée : c'est vraiment là, et de loin, qu'il y a les écritures les plus fréquentes.
  D'ailleurs tu l'as exprimé spontanément :

Hieldayn a écrit :

kern.log quand ça plante (le fichier contient plusieurs démarrage, je ne mets que le dernier)
(...) Et voilà syslog quand ça plante (là c'est quand même de super gros fichiers !! )

Compte le nombre de nouvelles lignes écrites dans ces fichiers en 1 heure (3.600 secondes), il y a de quoi être impressionné.


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#67 Le 26/01/2019, à 19:47

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Hmmm... oui, tu as bien raison, maintenant que tu en parles, ça écrit vraiment beaucoup dans les logs à chaque démarrage...

/tmp dans le / avec beaucoup de place n'usera finalement pas tant que ça, mais /var/log à part, en effet, ça paraît judicieux.
Dans mon cas, un Tour avec des disques "poubelle", ne me pose pas de problème.
Pour d'autres, avec les portables qui ont maintenant un SSD + HDD, il faut penser alors à garder un petite partoche de logs sur le HDD...

Merci beaucoup, je vois plus clair grâce à toi... big_smile

Hors ligne

#68 Le 30/01/2019, à 19:11

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

moko138, sur un autre fil a écrit :

0,3 Gio, je maintiens, et ça fait une sacrée marge !
Qui va lire 10 Gio de logs ???
[...]
Dès que ça enfle, il faut en chercher la cause et l'éliminer.
[...]

ça je suis bien d'accord, et avant que tu en parles, justement, je n'avais même pas fait attention que ça avait pris ces proportions... en l'occurrence, c'est abusé.
Je comprends et adhère à ce que tu dis (et grandtoubab aussi) mais le truc, c'est qu'on ne sait jamais quand on va avoir besoin d'une info d'un log... Donc entre désactiver et trop avoir, je préférerais un juste milieu.

moko138, sur un autre fil a écrit :

- et enfin, si besoin, je vide quelques vieux logs sans les supprimer.

Un petite explication, STP ?
Je n'ai pas assez d'expérience pour déterminer ce qui est utile et ce qui ne l'est pas, et ce qu'on peut alléger/supprimer et ce qu'il ne vaut mieux pas...

moko138, sur un autre fil a écrit :

1,1 Gio, tu vas en faire quoi ???

M'engueule pas, je découvre ! lol
J'ai certainement pas l'intention d'en faire la collection ! wink


moko138, sur un autre fil a écrit :

  Oui, mais en activant "journal", tu greffes à tes logs une maxi-gonflette artificielle !

hmm ... j'ai rien activé, moi... En tout cas : pas volontairement.
C'est quand même un truc sur lequel il faut alors être vigilant... Parce que les trucs de ce genre qui s'activent dans ton dos sans ton avis, c'est typiquement le genre de trucs windowsien qui m'agace...

moko138, sur un autre fil a écrit :

Hieldayn a écrit :

(ce qui permettrait aussi peut-être de rapatrier /var/log ça dans la même partoche que "/" si on purge les logs tous les ... disons 1 mois... ) ?

Tu n'as toujours pas intégré le problème de la fréquence des écritures !
Retrancher des lignes n'abolit pas l'usure provoquée par leur écriture !

Ah, ben là oui, j'ai vraiment dit une très grosse connerie... Dit comme ça, j'ai pris le truc à l'envers en gérant la conséquence au lieu de la cause... c'est pourtant pas mon habitude, merci de me le faire remarquer, ...  Toutes mes excuses...


Bon, donc, les résultats des commandes que tu demandes dans l'autre fil sont :

hieldayn@bureau:~$ sudo du -am -d1 /var/log | sort -h | tail -15
[sudo] Mot de passe de hieldayn : 
1	/var/log/unattended-upgrades
1	/var/log/wtmp
1	/var/log/wtmp.1
1	/var/log/Xorg.0.log
1	/var/log/Xorg.0.log.old
1	/var/log/Xorg.1.log
1	/var/log/Xorg.1.log.old
1	/var/log/Xorg.2.log
1	/var/log/Xorg.2.log.old
2	/var/log/boot.log
6	/var/log/boot-info
11	/var/log/installer
22	/var/log/boot-repair
977	/var/log/journal
1020	/var/log
hieldayn@bureau:~$ 

Si je comprends bien : usage disque montre que la quasi-totalité de la place prise par les Logs (1020 Mo) est dans /var/log

hieldayn@bureau:~$ sudo du -am -d1 /var/log/journal | sort -h | tail -15
977	/var/log/journal
977	/var/log/journal/cfa60753718c42e49e5f4a6b96e04620
hieldayn@bureau:~$ 

En effet, y'a un journal, et c'est rempli...

Je vois dans ce fameux dossier des fichiers .journal de talles 8, 16, 24 et 32 Mo... Pas anodin : il y a donc des limites de tailles de fichier... Mais c'est gros quand même...
Un coup de ncdu :

 --- /var/log/journal/cfa60753718c42e49e5f4a6b96e04620 --------------------------
                         /..                                                    
   32,0 MiB [##########]  system@d9b8912c80354dbeb...42-00057faafbe41e43.journal
   24,0 MiB [#######   ]  system@d9b8912c80354dbeb...4f-00057e7af70b3ff7.journal
   24,0 MiB [#######   ]  system@3d6089d9de4647b38...fe-00057a4c33c0548b.journal
   16,0 MiB [#####     ]  user-1002@15ca8165c99545...cd-00057affcb9d3fd9.journal
   16,0 MiB [#####     ]  user-1002.journal
   16,0 MiB [#####     ]  user-1001@98edf4a7bb1645...44-00057faafbf8b32b.journal
   16,0 MiB [#####     ]  user-1001@98edf4a7bb1645...50-00057e7af7134321.journal
   16,0 MiB [#####     ]  user-1001@98edf4a7bb1645...f8-00057dae81d021f5.journal
   16,0 MiB [#####     ]  user-1001@98edf4a7bb1645...93-00057aed2c12f153.journal
   16,0 MiB [#####     ]  user-1001@0e2c289c2abe48...00-00057a4c33d42e47.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...e3-000580605804e7fd.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...37-00057ff1f58a062f.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...36-00057f6f16b984b3.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...7c-00057ec63df8659e.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...67-00057e54110f77b6.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...f7-00057dae81c1bbe0.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...42-00057c957221847b.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...b6-00057bfa7f8c2c0d.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...b2-00057b7c12997b50.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...8e-00057b3bc8a96540.journal
   16,0 MiB [#####     ]  system@d9b8912c80354dbeb...01-00057aed2aa44b60.journal
   16,0 MiB [#####     ]  system@3d6089d9de4647b38...01-00057a2b7e6c2644.journal
   16,0 MiB [#####     ]  system@00057aed2b10daa7-3941fd5d6b6d5341.journal~
   16,0 MiB [#####     ]  system@00057a2b4f47a99f-bb68b55661b6744f.journal~
   16,0 MiB [#####     ]  system@00057a0581ccb9e8-ed99c3b3d67c5a93.journal~
   16,0 MiB [#####     ]  system@000579b19fd664a0-78bc3fd4991570d7.journal~
    8,0 MiB [##        ]  user-1003@8787874957334f...cd-00057d00414a40a0.journal
    8,0 MiB [##        ]  user-1003.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...e4-00058060580b324f.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...38-00057ff1f59208fd.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...37-00057f6f16c2e1ce.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...f1-00057f32693bab9b.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...ef-00057f1e05354212.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...94-00057ef5b3157447.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...7d-00057ec63e01498d.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...68-00057e541116381b.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...22-00057e39df7689de.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...60-00057e28658c97b2.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...43-00057c95722a07c3.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...e5-00057c221f53a691.journal
    8,0 MiB [##        ]  user-1001@98edf4a7bb1645...b3-00057b7c12a5a83c.journal
    8,0 MiB [##        ]  user-1001@0e2c289c2abe48...aa-00057ab74e25d49c.journal
    8,0 MiB [##        ]  user-1001@0e2c289c2abe48...30-00057aa3c30f5d60.journal
    8,0 MiB [##        ]  user-1001@0e2c289c2abe48...33-00057a3e87c38729.journal
    8,0 MiB [##        ]  user-1001@0e2c289c2abe48...81-00057a2b80455145.journal
    8,0 MiB [##        ]  user-1001@03b475a1933946...93-000579dbab1d3af4.journal
    8,0 MiB [##        ]  user-1001@03b475a1933946...85-000579b1a12711f2.journal
    8,0 MiB [##        ]  user-1001@00057aed2c14b2df-4bd07c2a93f4072d.journal~
 Total disk usage:   1,0 GiB  Apparent size:   1,0 GiB  Items: 92        

Je n'ai clairement pas besoin de tout cela...
Maintenant que tu m'éclaires là-dessus, j'ai hâte de comprendre comment gérer et limiter cela intelligemment.

Hors ligne

#69 Le 04/03/2019, à 16:15

Hieldayn

Re : [RESOLU] Ubuntu 18.04 freeze, sauf si boot par autre disque

Bonjour,

Suite et fin des histoires :

Prenant mon courage à 2 mains et ayant fait des sauvegardes (et clones de disques), j'en suis venu à tenter une installation du HWE Stack.

Oui, c'est déconseillé sur de la vieille machine, mais comme mon install Ubuntu 18.04.1 n'allait pas le faire toute seule, et que sinon j'aurais réinstallé le tout en 18.04.2 pour faire ce test, qui aurait fait presque la même chose alors banco.

D'autant que comme j'ai vu, ma Ubuntu Studio 16.04.3 a migré toute seule des noyaux 4.4 => 4.10 => 4.13 sans problème mais qu'à partir du jour où elle a mis le 4.15 j'ai eu les mêmes problèmes de démarrage que sous la 18.04, je me dis qu'il y a vraiment plus un soucis de noyau qui ne veut pas prendre en charge mon matériel qu'autre chose...

Bref, donc, après les sauvegardes, j'ai lancé ça

sudo apt install --install-recommends linux-generic-hwe-18.04 xserver-xorg-hwe-18.04

Je suis à présent sur le noyau 4.18.0-15 :

hieldayn@bureau:~$ uname -a
Linux bureau 4.18.0-15-generic #16~18.04.1-Ubuntu SMP Thu Feb 7 14:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
hieldayn@bureau:~$ 

Et j'ai pu supprimer l'option nomodeset et aussi de commenter la ligne GFXPAYLOAD dans /etc/default/grub :

hieldayn@bureau:~$ cat /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_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# GRUB_GFXPAYLOAD_LINUX=text

[...]

hieldayn@bureau:~$ 

... Et tout fonctionne très bien depuis (j'ai fait tout ça le 24/02/2019) !!
Il y avait donc bien des choses non prises en charge dans le 4.15 et qui le sont dans le 4.18.

N'empêche que c'est décidé : je m’attelle a me refaire un PC... ça devient de plus en plus difficile si je veux rester sur quelque chose d'assez friendly-user (comme Ubuntu, même si finalement Xubuntu me va aussi assez bien) pour ma famille... Et puis bon ,du matos qui 14 ans, ça aura quand même été bien rentabilisé tongue


NB : J'ai voulu faire peau neuve à ma Studio, mais la 16.04.3 a déjà les montées de noyaux nativement activées, or elle passera pas toute seule en 4.18... Donc tant pis, je me la suis réinstallé en 18.04 (même si c'est pas une LTS); et par contre je n'ai pas installé le HWE Stack (qui n'installe pas les noyaux 4.18 en lowlatency mais en generic), donc je me suis installé à la main le noyau 4.18 en sélectionnant les éléments "lowlatency" depuis https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18/
et en les installant manuellement.

Et cela fonctionne aussi parfaitement ! Du moins ça fera jusqu'à ce que je me monte une nouvelle config...



Merci pour votre aide et les différents conseils, j'ai appris plein de choses.

Hors ligne