Re: Erreur nvidia suite upgrade noyau 6.1.0-18
On Sunday 11 February 2024 11:43:32 Michel Verdier wrote: > Le 10 février 2024 ajh-valmer a écrit : > > Je ne peux donc pas augmenter la résolution avec ce pilote "Nouveau". > > On dirait que c'est le pilote "Vesa" qui a pris la main, pas "Nouveau"... > As-tu regardé dans les log ? Le pilote utilisé est indiqué clairement : Je vais voir. Avant, j'ai purgé nvidia depuis le noyau 6.1.0-17, pour faire un upgrade => noyau 6.1.0-18 et tenter à nouveau : # apt update # apt upgrade Errors were encountered while processing: linux-image-6.1.0-18-amd64 linux-image-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Je ne peux pas upgrader le système, je suis encore coincé... Bonne soirée.
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
On 12 Feb 2024 08:00, Hugues MORIN-TRENEULE wrote: Bonjour a tous Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. Ca fonctionne peut-être, mais ce n'est pas la manière recommandée ! Seulement l'update de "version" à "version +1" l'est. Donc tu devrais faire : 1. stretch -> buster 2. buster -> bullseye Pour l'avoir fait récemment, les étapes sont quasi les mêmes donc c'est pas trop chiant, et c'est plus sûr (ie. tu risques moins d'erreurs). Fais un doc avec juste les commandes pour aller plus vite. Si tu veux les miens je peux te les filer. -- ++ zithro / Cyril
Re : Stretch vers Bullseye - Probleme lors du apt full-upgrade
On 12/02/2024 19:23:39, Hugues MORIN-TRENEULE wrote: > Pour trouver le pid d'apt, c'est à l'aide de la commande ps? > Et apres kill "n° de pid" > Est ce qu'il y a autre chose a faire pour killer le processus d'apt? Tu peux tuer un processus en utilisant son nom avec la commande killall, qui s’utilise comme kill. killall firefox killall -9 firefox nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Salut Merci pour l'info Malheureusement même si j'entrevois de quoi tu parles, je ne sais pas trop comment faire en pratique. Donc si je comprends bien, maintenant que j'ai fait de la place, il faut que je relance la commande apt full-upgrade Mais avant cela, je dois killer le pid de apt et faire un dpkg-reconfigure. Pour trouver le pid d'apt, c'est à l'aide de la commande ps? Et apres kill "n° de pid" Est ce qu'il y a autre chose a faire pour killer le processus d'apt? Ensuite dpkg-reconfigure et enfin apt full-upgrade Est ce que cela vous semble OK Très cordialement Hugues Le lun. 12 févr. 2024 à 18:49, Alain RICHARD a écrit : > J’ai fait récemment un apt full-upgrade de Debian 12 à Debian 13 (Trixie) > et mon Pc s’est éteint (fausse manœuvre) et après avoir rebooté, le système > m’a pas laissé recommencer la même commande. J’ai du killer le Pid de apt > et faire un dpkg —reconfigure -à et ça a été. > > > Le 12 févr. 2024 à 17:14, Hugues MORIN-TRENEULE a > écrit : > > > Salut > > > C'est un système qui à l'origine avait été installé en Wheezy ou Jessie et > que j'ai upgradé. > Je n'avais pas autant de connaissance que maintenant et il m'avait semblé > plus judicieux de faire une partition par montage. > Je me disais que ca serait surement plus simple de restaurer le système en > cas de crash avec cette manière de faire. > Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, > /var et /opt. > > > Sinon concernant le "ménage", j'ai supprimé les anciens kernel dans /boot. > J'ai supprimé aussi les dossiers modules concernés dans /lib/module. > > Voila le nouvel etat de mon systeme de fichiers: > > df -TPh > Filesystem Type Size Used Avail Use% Mounted on > udev devtmpfs 2.0G 0 2.0G 0% /dev > tmpfs tmpfs 396M 7.5M 389M 2% /run > /dev/sda1 ext4 1.8G 661M 1.1G 39% / > /dev/sda8 ext4 28G 7.2G 19G 28% /usr > tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm > tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock > tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup > /dev/sdc1 ext4 916G 583G 287G 68% /mnt/data2 > /dev/sdb1 fuseblk 299G 285G 14G 96% /mnt/data > /dev/sda10 ext4 28G 2.7G 24G 11% /opt > /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp > /dev/sda9 ext4 19G 6.5G 11G 38% /var > /dev/sda3 ext4 73G 5.0G 65G 8% /home > /dev/sda5 ext4 920M 232M 625M 28% /boot > tmpfs tmpfs 396M 0 396M 0% /run/user/0 > /dev/sdd1 vfat 7.5G 366M 7.2G 5% /root/corsair > > df -i > Filesystem Inodes IUsedIFree IUse% Mounted on > udev 502193490 5017031% /dev > tmpfs506243848 5053951% /run > /dev/sda1122160 15831 106329 13% / > /dev/sda8 1831424 311408 1520016 18% /usr > tmpfs506243 1 5062421% /dev/shm > tmpfs506243 4 5062391% /run/lock > tmpfs506243 16 5062271% /sys/fs/cgroup > /dev/sdc1 61054976 13288 610416881% /mnt/data2 > /dev/sdb1 14184328 6185 141781431% /mnt/data > /dev/sda10 1831424797 18306271% /opt > /dev/sda7122160 28 1221321% /tmp > /dev/sda9 1220608 18510 12020982% /var > /dev/sda3 4890624 68947 48216772% /home > /dev/sda5 61056392606641% /boot > tmpfs506243 11 5062321% /run/user/0 > /dev/sdd1 0 00 - /root/corsair > > du -h -d 1 > 2.7G ./opt > 417M ./root > 6.5G ./var > 0 ./sys > 16K ./lost+found > 16M ./etc > 7.5M ./run > 12K ./media > 4.0K ./lib64 > 5.0G ./home > 7.2G ./usr > 13M ./sbin > 12M ./bin > 68K ./tmp > 564M ./lib > 868G ./mnt > 6.1M ./lib32 > 4.0K ./srv > 232M ./boot > 0 ./dev > 4.0K ./.cache > 0 ./proc > 890G . > > Est ce que cela vous semble suffisant pour l'upgrade? > > Et dans l'affirmative, que faut-il faire ensuite? > Je n'en ai pas la moindre idée et je ne voudrai pas exécuter de commande > qui pourrait faire empirer le probleme. > > Très cordialement > Hugues > > > Le lun. 12 févr. 2024 à 13:22, Michel Verdier a écrit : > >> Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : >> >> > J'ai effectivement vu ce message mais je n'en avais pas compris la >> raison. >> > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et >> > /boot son bien "chargées". >> > Est ce que le problème pourrait provenir de la? >> >> Le message repéré par Alban porte sur /lib donc ton / >> qui n'a que 127Mo de libre. La taille des modules varie selon les >> kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers >> temporaires pendant l'installation. Déjà fais peut-être le ménage dans >> les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce >> n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de >> la place sur / >> >> >
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Salut C'est un système qui à l'origine avait été installé en Wheezy ou Jessie et que j'ai upgradé. Je n'avais pas autant de connaissance que maintenant et il m'avait semblé plus judicieux de faire une partition par montage. Je me disais que ca serait surement plus simple de restaurer le système en cas de crash avec cette manière de faire. Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, /var et /opt. Sinon concernant le "ménage", j'ai supprimé les anciens kernel dans /boot. J'ai supprimé aussi les dossiers modules concernés dans /lib/module. Voila le nouvel etat de mon systeme de fichiers: df -TPh Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 2.0G 0 2.0G 0% /dev tmpfs tmpfs 396M 7.5M 389M 2% /run /dev/sda1 ext4 1.8G 661M 1.1G 39% / /dev/sda8 ext4 28G 7.2G 19G 28% /usr tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sdc1 ext4 916G 583G 287G 68% /mnt/data2 /dev/sdb1 fuseblk 299G 285G 14G 96% /mnt/data /dev/sda10 ext4 28G 2.7G 24G 11% /opt /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp /dev/sda9 ext4 19G 6.5G 11G 38% /var /dev/sda3 ext4 73G 5.0G 65G 8% /home /dev/sda5 ext4 920M 232M 625M 28% /boot tmpfs tmpfs 396M 0 396M 0% /run/user/0 /dev/sdd1 vfat 7.5G 366M 7.2G 5% /root/corsair df -i Filesystem Inodes IUsedIFree IUse% Mounted on udev 502193490 5017031% /dev tmpfs506243848 5053951% /run /dev/sda1122160 15831 106329 13% / /dev/sda8 1831424 311408 1520016 18% /usr tmpfs506243 1 5062421% /dev/shm tmpfs506243 4 5062391% /run/lock tmpfs506243 16 5062271% /sys/fs/cgroup /dev/sdc1 61054976 13288 610416881% /mnt/data2 /dev/sdb1 14184328 6185 141781431% /mnt/data /dev/sda10 1831424797 18306271% /opt /dev/sda7122160 28 1221321% /tmp /dev/sda9 1220608 18510 12020982% /var /dev/sda3 4890624 68947 48216772% /home /dev/sda5 61056392606641% /boot tmpfs506243 11 5062321% /run/user/0 /dev/sdd1 0 00 - /root/corsair du -h -d 1 2.7G ./opt 417M ./root 6.5G ./var 0 ./sys 16K ./lost+found 16M ./etc 7.5M ./run 12K ./media 4.0K ./lib64 5.0G ./home 7.2G ./usr 13M ./sbin 12M ./bin 68K ./tmp 564M ./lib 868G ./mnt 6.1M ./lib32 4.0K ./srv 232M ./boot 0 ./dev 4.0K ./.cache 0 ./proc 890G . Est ce que cela vous semble suffisant pour l'upgrade? Et dans l'affirmative, que faut-il faire ensuite? Je n'en ai pas la moindre idée et je ne voudrai pas exécuter de commande qui pourrait faire empirer le probleme. Très cordialement Hugues Le lun. 12 févr. 2024 à 13:22, Michel Verdier a écrit : > Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : > > > J'ai effectivement vu ce message mais je n'en avais pas compris la > raison. > > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et > > /boot son bien "chargées". > > Est ce que le problème pourrait provenir de la? > > Le message repéré par Alban porte sur /lib donc ton / > qui n'a que 127Mo de libre. La taille des modules varie selon les > kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers > temporaires pendant l'installation. Déjà fais peut-être le ménage dans > les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce > n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de > la place sur / > > > /dev/sda1 ext4 1.8G 1.6G 127M 93% / > > /dev/sda8 ext4 28G 7.2G 19G 28% /usr > > /dev/sda10 ext4 28G 2.7G 24G 11% /opt > > /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp > > /dev/sda9 ext4 19G 6.5G 11G 38% /var > > /dev/sda3 ext4 73G 5.0G 65G 8% /home > > /dev/sda5 ext4 920M 379M 478M 45% /boot > > Pourquoi avoir découpé sda en autant de partitions ? Ca n'augmente pas la > sécurité et tu perds plein de place sur certaines alors que d'autres > saturent. > >
Re: Erreur suite à un apt upgrade noyau 6.6.18
Le 12 février 2024 ajh-valmer a écrit : > Encore un qui n'a pas lu mon mail sans chercher plus loin que le bout > de ses yeux : >> xrandr --addmode VGA 1280x1024_60.00 >> xrandr --output VGA-0 --mode 1280x1024_60.00 : > Réponse : > xrandr: Failed to get size of gamma for output default > xrandr: cannot find output "VGA" Oui mais as-tu fais aussi et auparavant la commande xrandr *--newmode* indiquée par Bernard ?
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : > J'ai effectivement vu ce message mais je n'en avais pas compris la raison. > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et > /boot son bien "chargées". > Est ce que le problème pourrait provenir de la? Le message repéré par Alban porte sur /lib donc ton / qui n'a que 127Mo de libre. La taille des modules varie selon les kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers temporaires pendant l'installation. Déjà fais peut-être le ménage dans les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de la place sur / > /dev/sda1 ext4 1.8G 1.6G 127M 93% / > /dev/sda8 ext4 28G 7.2G 19G 28% /usr > /dev/sda10 ext4 28G 2.7G 24G 11% /opt > /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp > /dev/sda9 ext4 19G 6.5G 11G 38% /var > /dev/sda3 ext4 73G 5.0G 65G 8% /home > /dev/sda5 ext4 920M 379M 478M 45% /boot Pourquoi avoir découpé sda en autant de partitions ? Ca n'augmente pas la sécurité et tu perds plein de place sur certaines alors que d'autres saturent.
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour J'ai effectivement vu ce message mais je n'en avais pas compris la raison. Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et /boot son bien "chargées". Est ce que le problème pourrait provenir de la? Voila le résultat des commandes demandées: df -TPh Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 2.0G 0 2.0G 0% /dev tmpfs tmpfs 396M 7.5M 389M 2% /run /dev/sda1 ext4 1.8G 1.6G 127M 93% / /dev/sda8 ext4 28G 7.2G 19G 28% /usr tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sdc1 ext4 916G 583G 287G 68% /mnt/data2 /dev/sdb1 fuseblk 299G 285G 14G 96% /mnt/data /dev/sda10 ext4 28G 2.7G 24G 11% /opt /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp /dev/sda9 ext4 19G 6.5G 11G 38% /var /dev/sda3 ext4 73G 5.0G 65G 8% /home /dev/sda5 ext4 920M 379M 478M 45% /boot tmpfs tmpfs 396M 0 396M 0% /run/user/0 df -i Filesystem Inodes IUsedIFree IUse% Mounted on udev 502193473 5017201% /dev tmpfs506243823 5054201% /run /dev/sda1122160 3689185269 31% / /dev/sda8 1831424 311408 1520016 18% /usr tmpfs506243 1 5062421% /dev/shm tmpfs506243 4 5062391% /run/lock tmpfs506243 16 5062271% /sys/fs/cgroup /dev/sdc1 61054976 13288 610416881% /mnt/data2 /dev/sdb1 14184328 6185 141781431% /mnt/data /dev/sda10 1831424797 18306271% /opt /dev/sda7122160 28 1221321% /tmp /dev/sda9 1220608 18509 12020992% /var /dev/sda3 4890624 68947 48216772% /home /dev/sda5 61056412606441% /boot tmpfs506243 11 5062321% /run/user/0 Très cordialement Hugues Le lun. 12 févr. 2024 à 08:19, Alban Vidal a écrit : > Bonjour Hugues, > > Dans les logs il ressort le message "failed to write (No space left on > device)" qui signifie qu'il n'y a plus d'espace libre. > > Peux-tu nous transmettre le retour des commandes suivantes : > df -TPh > df -i > > Cordialement, > Alban > > > Le 12 février 2024 08:00:00 GMT+01:00, Hugues MORIN-TRENEULE < > mor...@gmail.com> a écrit : > >> Bonjour a tous >> >> >> Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer >> un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. >> >> Il y a quelques temps vos conseils et explications mon permis de de >> mettre a jours mon Stretch afin de le préparer à l'upgrade vers Bullseye >> (cf "Mise à jours et Update Stretch - Problème de dépôt" sur la liste => >> https://lists.debian.org/debian-user-french/2023/08/msg00289.html) >> >> En résumé, j'ai oublié de faire l'upgrade de mon stretch en temps et en >> heure. Quand j'ai voulu le faire, les dépôts de mon sources.list n'étaient >> plus valide. Votre aide m'a permis d'avoir les bons dépôts et de mettre a >> jours mon Stretch à sa dernière version avant de lancer l'upgrade. >> Jusque là aucun probleme. >> >> Une fois a jour, j'ai lancé la procédure d'upgrade de Stretch à Bullseye >> en suivant pas à pas la procedure decrite par debian.org: >> >> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html >> >> Tout s'est bien passé jusqu'au apt full-upgrade (paragraphe 4.4.6). >> J'ai fait les contrôles demandés, fait les sauvegardes. >> J'ai utilisé a plusieurs reprises les procédures d'upgrade de debian.org >> sans jamais rencontrer de probleme, c'est la 1ere fois que j'ai un crash >> lors de celle-ci et je ne sais pas trop que faire car je ne maitrise pas du >> tout le sujet. >> J'ai bien entendu tenté de faire quelques recherches mais cela ne m'a >> conduit a rien de concluant, soit ça n'a rien à voir, soit je ne comprends >> pas ce que je lis... >> >> Le probleme est survenu à environ 45% de l'installation. >> Voila le dernier message en console: >> [...] >> Selecting previously unselected package libnss-systemd:amd64. >> Preparing to unpack .../345-libnss-systemd_241-7~deb10u10_amd64.deb ... >> Unpacking libnss-systemd:amd64 (241-7~deb10u10) ... >> Errors were encountered while processing: >> >> >> /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> >> >> J'ai trouvé 2 messages d'erreurs avant le crash définitif: >> >> [...] >> Selecting previously unselected package linux-image-4.19.0-25-amd64. >> Preparing to unpack >> .../261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb ... >> Unpacking linux-image-4.19.0-25-amd64 (4.19.289-2) ... >> dpkg: error processing archive >> /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb >> (--unpack): >>
