[Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

ThêtaClic · Le 18/08/2018, à 19:02

Bonjour,
la mise à niveau vers Ubuntu 18.04.1 s'est mal passée.
Le processus de boot s'interrompt peu après le choix du système dans le menu Grub et ne va pas jusqu'au login de l'utilisateur.
Après un passage en mode "recovery" on peut voir que la partition / est montée (/dev/sda6) mais que la partition /home (/dev/sda7) ne l'est pas, ou plutôt que le montage s'est mal fait : démonter puis monter à la main fonctionne.
Merci de votre aide pour trouver l'erreur et la corriger.

Dernière modification par ThêtaClic (Le 30/08/2018, à 16:42)

GammaDraconis · Le 18/08/2018, à 19:42

Il fallait faire une nouvelle installation, pas une mise à niveau.

ThêtaClic · Le 18/08/2018, à 21:07

Merci pour la réponse.

GammaDraconis a écrit :

Il fallait faire une nouvelle installation, pas une mise à niveau.

À quoi sert donc une telle procédure de mise à niveau ?
Il me semble par ailleurs qu'une nouvelle installation crée de nouveaux utilisateurs et rend difficile la récupération des données d'un utilisateur existant ?

Coeur Noir · Le 18/08/2018, à 22:52

1) Ce que Gamma oublie de dire c'est qu'avant d'effectuer une mise à niveau il y a quelques points à vérifier afin de s'assurer que tout se passera bien :
- désactiver tout ou partie des ppa,
- voire pour certains ppa, passer par ppa-purge pour revenir aux paquets de la distribution officielle ( notamment tout ce qui concerne noyaux et pile graphique ),
- mettre à jour cet actuel système,
- avoir une sauvegarde de ses documents préférés, ça peut toujours servir ;-)

En gros, la procédure de mise à niveau s'attend à un système maintenu à jour via les mécanismes « officiels ».

2) « une nouvelle installation crée de nouveaux utilisateurs et rend difficile la récupération des données d'un utilisateur existant » oui et non, il y a une bonne chance que le nouvel utilisateur ait accès sans rien faire aux données de l'ancien - si celui était le premier et seul utilisateur du système. Sinon c'est pas très compliqué de se réapproprier les données - à condition d'avoir conservées celles-ci ( soit parceque le /home était sur une partition à part, soit parce que sauvegarde… )

Dernière modification par Coeur Noir (Le 18/08/2018, à 23:19)

ThêtaClic · Le 19/08/2018, à 08:10

il y a une bonne chance que le nouvel utilisateur ait accès sans rien faire aux données de l'ancien

Est-ce que cela veut dire que je dois faire une réinstallation en croisant les doigts pour que tout se passe bien ?

xubu1957 · Le 19/08/2018, à 08:23

Bonjour,

Prérequis a écrit :

(...)
Par prudence, avoir sauvegardé votre «/home» sur un support externe.

La Doc > reinstallation_ubuntu

Coeur Noir · Le 19/08/2018, à 15:33

ThêtaClic a écrit :

il y a une bonne chance que le nouvel utilisateur ait accès sans rien faire aux données de l'ancien
Est-ce que cela veut dire que je dois faire une réinstallation en croisant les doigts pour que tout se passe bien ?

Hey J'en sais rien ! Tu ne réponds pas vraiment aux suggestions du post précédent...

En l'état tu n'accèdes pas à ta session graphique. C'est ça ?
Ce serait bien qu'on voit à quoi ressemble ton installation :

lsblk
sudo blkid
cat /etc/fstab

Mais oui réinstaller est parfois plus rapide que de chercher à comprendre et réparer et ça assure de partir sur une base saine.

Dernière modification par Coeur Noir (Le 19/08/2018, à 15:38)

ThêtaClic · Le 19/08/2018, à 18:51

Merci de ton aide.

Coeur Noir a écrit :

Tu ne réponds pas vraiment aux suggestions du post précédent...

Je suis en train de bosser la doc proposée par xubu1957 et de m'assurer que ma sauvegarde de /home est bien récupérable.

Coeur Noir a écrit :

En l'état tu n'accèdes pas à ta session graphique. C'est ça ?.

C'est ça.

Coeur Noir a écrit :

Ce serait bien qu'on voit à quoi ressemble ton installation :.

lsblk

------------------------------------------
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 34,7M 1 loop /snap/gtk-common-themes/319
loop1 7:1 0 3,7M 1 loop /snap/gnome-system-monitor/51
loop2 7:2 0 2,3M 1 loop /snap/gnome-calculator/180
loop3 7:3 0 87M 1 loop /snap/core/5145
loop4 7:4 0 13M 1 loop /snap/gnome-characters/103
loop5 7:5 0 140,9M 1 loop /snap/gnome-3-26-1604/70
loop6 7:6 0 14,5M 1 loop /snap/gnome-logs/37
sda 8:0 0 298,1G 0 disk
├─sda1 8:1 0 48,8G 0 part
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 79,2G 0 part
├─sda6 8:6 0 81G 0 part /
├─sda7 8:7 0 80G 0 part /home
├─sda8 8:8 0 3,4G 0 part [SWAP]
└─sda9 8:9 0 5,8G 0 part
sdb 8:16 0 465,8G 0 disk
├─sdb1 8:17 0 98,6G 0 part
└─sdb2 8:18 0 171,9G 0 part
sr0 11:0 1 6M 0 rom
------------------------------------------

sudo blkid

------------------------------------------
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/sda1: UUID="DA781BD9781BB36D" TYPE="ntfs" PARTUUID="00000001-01"
/dev/sda5: UUID="CCACBC33ACBC1A42" TYPE="ntfs" PARTUUID="00000001-05"
/dev/sda6: UUID="aadcd717-4b4d-4f34-8db2-408341f8199f" TYPE="ext4" PARTUUID="00000001-06"
/dev/sda7: UUID="060ab630-eeae-4a02-bf3e-f83334308abc" TYPE="ext4" PARTUUID="00000001-07"
/dev/sda8: UUID="31d9160c-c938-4feb-8813-65721b287a45" TYPE="swap" PARTUUID="00000001-08"
/dev/sdb1: UUID="6b3c15e0-2dcb-4db7-ac9b-b941f2c86297" TYPE="ext4" PARTUUID="a9b12c61-01"
/dev/sdb2: UUID="6b79d5de-ca64-4a18-9635-6bdfe120d5b0" TYPE="ext4" PARTUUID="a9b12c61-02"
/dev/sr0: UUID="2009-04-29-18-02-01-00" LABEL="Bluebirds" TYPE="iso9660"
/dev/sda9: PARTUUID="00000001-09"
------------------------------------------

 cat /etc/fstab

------------------------------------------
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda6 during installation
UUID=aadcd717-4b4d-4f34-8db2-408341f8199f / ext4 errors=remount-ro 0 1
# /home was on /dev/sda7 during installation
UUID=060ab630-eeae-4a02-bf3e-f83334308abc /home ext4 defaults 0 2
# swap was on /dev/sda8 during installation
UUID=31d9160c-c938-4feb-8813-65721b287a45 none swap sw 0 0
------------------------------------------

Coeur Noir a écrit :

Mais oui réinstaller est parfois plus rapide que de chercher à comprendre et réparer et ça assure de partir sur une base saine.

Réparer devrait m'en apprendre plus que réinstaller.

Coeur Noir · Le 19/08/2018, à 21:08

Je suis en train de bosser la doc proposée par xubu1957 et de m'assurer que ma sauvegarde de /home est bien récupérable. → c'est très sage ;-)

Il y a 2 disques dans ton pc, sda ( 298,1G sur lequel il y a windows ) et sdb ( 465,8G formaté ext4 mais avec de l'espace inutilisé ).
Aucune partition de sdb ne semble automatiquement montée au démarrage, c'est volontaire ? Comment utilises-tu ce disque ?

Sur sda tu as une partition /home ( sda7 ) distincte de la partition racine / ( sda6 ).
Ce que tu cherches à sauvegarder c'est le contenu de ton répertoire personnel /home/ton_nom_user ( ou de plusieurs répertoires si plusieurs utilisateurs ).

L'idée c'est de savoir « comment » tu veux te servir de tout ça… pourquoi 2 disques, pourquoi telles partitions ?
À première vue je dirais que cette installation est boiteuse puisqu'elle « oublie » de se servir du deuxième disque.

Tu parles bien d'une mise à niveau de 16.04 à 18.04, pas d'une réinstallation
( effacer la partition / contenant 16.04 pour mettre à la place une partition / de 18.04 et en te servant éventuellement de la partition /home déjà existante ) ?

Donc si c'est bien une mise à niveau, avant de lancer cette procédure, avais-tu :
- désactivé tout ou partie des ppa,
- voire pour certains ppa, passé du ppa-purge pour revenir aux paquets de la distribution officielle ( notamment tout ce qui concerne noyaux et pile graphique ),
- mis à jour l'actuel système 16.04 ?

Là encore l'idée c'est d'évaluer si la base de ton système est saine, et éventuellement réparable, ou si une réinstallation ne serait pas finalement plus profitable.
Un petit coup d'œil à tes sources de logiciels et autres ppa :

cat /etc/apt/sources.list
cat /etc/apt/sources.list.d/*

ThêtaClic · Le 20/08/2018, à 06:49

Coeur Noir a écrit :

Aucune partition de sdb ne semble automatiquement montée au démarrage, c'est volontaire ? Comment utilises-tu ce disque ?

J'avais oublié l'existence de ce deuxième disque comme j'avais oublié l'existence d'un système Windows sur le premier. Ce système Windows n'est plus utilisé depuis que, malgré son jeune âge, il est devenu grabataire, il y a bien longtemps :=)
Le deuxième disque est arrivé plus tard, le lien vers le système qu'il contient a du se perdre lors d'une précédente mise à niveau.

Coeur Noir a écrit :

Sur sda tu as une partition /home ( sda7 ) distincte de la partition racine / ( sda6 ).
Ce que tu cherches à sauvegarder c'est le contenu de ton répertoire personnel /home/ton_nom_user ( ou de plusieurs répertoires si plusieurs utilisateurs ).
Tu parles bien d'une mise à niveau de 16.04 à 18.04, pas d'une réinstallation
( effacer la partition / contenant 16.04 pour mettre à la place une partition / de 18.04 et en te servant éventuellement de la partition /home déjà existante ) ?

Oui.

Coeur Noir a écrit :

Donc si c'est bien une mise à niveau, avant de lancer cette procédure, avais-tu :
- désactivé tout ou partie des ppa,
- voire pour certains ppa, passé du ppa-purge pour revenir aux paquets de la distribution officielle ( notamment tout ce qui concerne noyaux et pile graphique ),

Non, l'utilisatrice principale est mon épouse, navigation web, mail, bureautique, rien qui sorte des sentiers battus, normalement pas de ppa.
Cependant il me semble que les pages qui traitent de la mise à niveau de Ubuntu devraient évoquer plus clairement cette désactivation des ppa.

Coeur Noir a écrit :

- mis à jour l'actuel système 16.04 ?

Oui.

Coeur Noir a écrit :

Un petit coup d'œil à tes sources de logiciels et autres ppa :

cat /etc/apt/sources.list

# deb cdrom:[Ubuntu 16.04.1 LTS _Xenial Xerus_ - Release amd64 (20160719)]/ xenial main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic main restricted
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates main restricted
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## universe WILL NOT receive any review or updates from the Ubuntu security
## team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic universe
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial universe
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates universe
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu xenial partner
# deb-src http://archive.canonical.com/ubuntu xenial partner

deb http://security.ubuntu.com/ubuntu bionic-security main restricted
# deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe
# deb-src http://security.ubuntu.com/ubuntu xenial-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse
# deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse

cat /etc/apt/sources.list.d/*

Le dossier /etc/apt/sources.list.d est vide.

Coeur Noir · Le 21/08/2018, à 02:03

Fichtre… rien de très bizarre, on voit qu'il s'agit d'un sources.list « mis à niveau » ( lignes contenant xenial commentées, c'est à dire qui débutent par # pour faire ignorer ce qui suit )
on pourrait le nettoyer un peu mais en tout cas rien là qui explique ton blocage.

/etc/apt/sources.list.d vide = pas de ppa. Donc pas là non plus qu'il y a un problème ;-)

Euh… au fait puisque tu n’accèdes pas à ta session graphique, tu les fais depuis une console tous ces retours de commande ?

Depuis une console où tu es « loggué » comme utilisateur que répond

ls -la | grep -E "author|xsess"

si tu vois bien ton nom de session comme propriétaire pour les quatre fichiers avec des droits rw, essaie

startx

…rien de porno, c'est censé démarrer la session graphique, mais il nous dira sans doute ce qui le chagrine.

Le processus de boot s'interrompt peu après le choix du système dans le menu Grub et ne va pas jusqu'au login de l'utilisateur
→ donc il n'y a pas un joli écran de connexion ( lightdm sous 16.04, GDM sous 18.04 ) qui s'affiche pour te proposer un choix d'utilisateur, c'est bien ça ?
C'est p'têt bien ça qui coince, la mise à niveau de lightdm à gdm ? À étudier en fonction de la réaction de startx, il y aura sans doute du

sudo dpkg-reconfigure gdm3

à passer.

Au cas où : tes ( vos ) documents persos sont-ils sauvegardés quelque part ? As-tu un support d'installation ( clé usb ou dvd ) d'une 18.04.1 ? Je ne dis pas que la réinstallation s'impose mais au regard de tes réponses précédentes, ça vaudrait peut-être le coup :
- à quoi bon garder un windows qui ne sert à rien ?
- pourquoi ne pas utiliser tous les disques à ta disposition ( y-a-t-il un SSD dans le tas ) ?
- organiser tout ça pour mieux coller à votre utilisation du pc ?

Dernière modification par Coeur Noir (Le 21/08/2018, à 02:33)

cqfd93 · Le 21/08/2018, à 02:49

Modération

Bonjour,

Pour ajouter toi-même les balises code à tes messages #8 et #10 :

Cliquer sur le lien « Modifier » en bas à droite du message
Sélectionner le texte
Cliquer sur le <> de l'éditeur de message

ThêtaClic · Le 21/08/2018, à 15:02

Merci Coeur Noir de t'intéresser au sujet.

tu les fais depuis une console tous ces retours de commande ?

Oui, c'est la console de maintenance, sous root accessible à partir du mode "recovery". J'accède au forum à partir d'une autre machine.

à quoi bon garder un windows qui ne sert à rien ?

Bonne question.
Nostalgie ?
Souvenir du jour où ma femme m'a demandé de lui installer "un truc qui marche !" ?
De nos jours un Go, ça ne vaut plus rien.
Et puis je l'ai payé b....l ! ;=)

Les choses ont évolué dans les dernières 24 heures.
La réinstallation me paraît une solution devenue évidente. Je fait donc une réinstallation sur /dev/sda6 pour / et sur /dev/sda7 pour /home.
Et au reboot suivant : même comportement, ce qui montre que la procédure de mise à niveau n'est pas en cause.

En utilisant deux fois de suite l'option "resume" du mode "recovery" le processus de boot arrive à son terme et permet un login graphique avec un /home bien monté et toutes les données de l'utilisateur (principal) qui sont conservées et accessibles. Seulement la session fonctionne mal (chargement très long des applis, mouvement saccadé des fenêtres).
Un coup d’œil dans le fichier de log du serveur X montre que c'est le module VESA qui pilote.
Si on regarde de plus près les erreurs dans le log du serveur X.

cat /var/log/Xorg.0.log|grep "(EE)"

	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    91.446] (EE) open /dev/dri/card0: No such file or directory
[    91.446] (EE) open /dev/dri/card0: No such file or directory
[    91.447] (EE) open /dev/fb0: No such file or directory
[    91.448] (EE) open /dev/fb0: No such file or directory
[    91.448] (EE) Screen 0 deleted because of no matching config section.
[    91.448] (EE) Screen 0 deleted because of no matching config section.
[    91.448] (EE) Screen 0 deleted because of no matching config section.
[    92.231] (EE) AIGLX: reverting to software rendering

Et pour les warnings

cat /var/log/Xorg.0.log|grep "(WW)"

	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    91.295] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    91.295] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[    91.295] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[    91.295] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[    91.295] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[    91.446] (WW) Falling back to old probe method for modesetting
[    91.447] (WW) Falling back to old probe method for fbdev
[    91.866] (WW) VESA(0): Unable to estimate virtual size

Je choisis alors d'utiliser une autre carte graphique (AMD radeon HD 6450) que j'installe dans la machine.
Reboot. Même comportement, mêmes erreurs (EE) et warnings (WW) dans le fichier de log du serveur X. J'observe que le module radeon est "loadé" puis "unloadé" et qu'au final c'est toujours VESA qui pilote.

Dans la console de maintenance, en root, je lance "startx". La commande plante.
Au reboot, oh ! surprise, le process arrive à son terme, jusqu'à la fenêtre de connexion de gdm (avec seulement deux options comme gestionnaire de bureau : Ubuntu et Ubuntu/Wayland). Le login se passe bien, les données perso sont là. Mais l'affichage n'est pas optimal.

Ce qu'il faudrait maintenant c'est que le serveur X utilise vraiment le pilote radeon. Reconfigurer le serveur X ? Mais comment faire ? Quel package reconfigurer ? Je suis preneur d'info là-dessus et de toute autre suggestion.

Coeur Noir · Le 22/08/2018, à 00:37

Oh mais c'est un pas de géant ça…

Par défaut la session Ubuntu devrait utiliser le pilote libre nouveau ( Ubuntu tout court, pas Ubuntu Wayland qui comme son nom l’indique utilise Wayland comme serveur graphique et non Xorg ).

Tu devrais dans la doc ou le forum trouver les manip's nécessaires pour rétablir nouveau comme driver - et il me semble aussi avoir lu récemment un fil où une ubuntu bootait sur vesa au lieu de nouveau, qu'évidemment je ne trouve plus…

…il semble que les CG amd soient plutôt bien supportées sous 18.04 via le pilote libre. À prendre avec des pincettes : https://linuxconfig.org/how-to-install- … aver-linux

À tout-z-hasard :

cat /etc/default/grub

Dernière modification par Coeur Noir (Le 22/08/2018, à 00:55)

ThêtaClic · Le 30/08/2018, à 16:40

Bonjour,
pour clore la discussion, après un peu de latence j'ai finalement suivi les conseils de Coeur Noir et réinstallé un nouveau système Ubuntu 18.04 sur tout l'espace de /dev/sdb. Le fonctionnement n'est pas optimal mais satisfait mon épouse.
Merci à tous ceux qui se sont intéressés au sujet et on contribué.
Considérons le sujet comme résolu.

Dernière modification par ThêtaClic (Le 30/08/2018, à 16:42)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/08/2018, à 19:02

[Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#2 Le 18/08/2018, à 19:42

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#3 Le 18/08/2018, à 21:07

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#4 Le 18/08/2018, à 22:52

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#5 Le 19/08/2018, à 08:10

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#6 Le 19/08/2018, à 08:23

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#7 Le 19/08/2018, à 15:33

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#8 Le 19/08/2018, à 18:51

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#9 Le 19/08/2018, à 21:08

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#10 Le 20/08/2018, à 06:49

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#11 Le 21/08/2018, à 02:03

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#12 Le 21/08/2018, à 02:49

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#13 Le 21/08/2018, à 15:02

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#14 Le 22/08/2018, à 00:37

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

#15 Le 30/08/2018, à 16:40

Re : [Résolu] La mise à niveau de Ubuntu 16.04 vers 18.04.1 se passe mal

Pied de page des forums