227
Je mets un complément.
Après avoir à nouveau monté ma partition /dev/sda5 sur swap dans yast/partition, comme décrit dans le message précédent, j'ai à nouveau profité de 2Go de swap.
Depuis lors, j'avais remarqué une lenteur au démarrage:
A start job is running for /dev/disk/by-uuid/fea36f54-1a…
Au fil des jours, trouvant cela un peu gênant, j'ai recherché, et j'ai trouvé.
Aujourd'hui je viens de vérifier mon /etc/fstab, j'avais ceci:
localhost:/home/thierry # cat /etc/fstab
UUID=e3ece1de-d3ed-4326-82b9-4e7207b22454 / ext4 defaults 0 1
UUID=050e52e7-bfc6-4e19-b3a7-33235da0326a /home ext4 data=ordered 0 2
UUID=09c97bb2-c8d3-4f97-b551-8ce684c55457 swap swap defaults 0 0
UUID=fea36f54-1a3e-4bfb-8f24-9e1d9cf13eb5 swap swap defaults 0 0
UUID=4632D33B32D32F25 /mnt/Nouveau_Nom ntfs-3g defaults 0 0
UUID="5c2c9399-fd64-43d6-9086-7f72f8c26dbd" /mnt/Dateien_Arbeit ext4 defaults 0 0
Il semble que la partition /dev/sa5 a changé de UUID après la coupure de courant.
On voit l'ancien UUID:
UUID=fea36f54-1a3e-4bfb-8f24-9e1d9cf13eb5 swap swap defaults 0 0
Cette même UUID qui posait problème au démarrage…
Dans mon journal, j'ai naturellement aussi trouvé des alertes (# journalctl):
Mär 13 10:03:56 localhost systemd[1]: dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device: Job dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device/start timed out.
Mär 13 10:03:56 localhost systemd[1]: dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device: Job dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device/start timed out.
Mär 13 10:03:56 localhost systemd[1]: Timed out waiting for device /dev/disk/by-uuid/fea36f54-1a3e-4bfb-8f24-9e1d9cf13eb5.
Mär 13 10:03:56 localhost systemd[1]: Dependency failed for /dev/disk/by-uuid/fea36f54-1a3e-4bfb-8f24-9e1d9cf13eb5.
Mär 13 10:03:56 localhost systemd[1]: Dependency failed for Swap.
Mär 13 10:03:56 localhost systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
Mär 13 10:03:56 localhost systemd[1]: dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.swap: Job dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.swap/start failed with result 'dependency'.
Mär 13 10:03:56 localhost systemd[1]: dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device: Job dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device/start timed out.
Mär 13 10:03:56 localhost systemd[1]: Timed out waiting for device /dev/disk/by-uuid/fea36f54-1a3e-4bfb-8f24-9e1d9cf13eb5.
Mär 13 10:03:56 localhost systemd[1]: Dependency failed for /dev/disk/by-uuid/fea36f54-1a3e-4bfb-8f24-9e1d9cf13eb5.
Mär 13 10:03:56 localhost systemd[1]: Dependency failed for Swap.
Mär 13 10:03:56 localhost systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
Mär 13 10:03:56 localhost systemd[1]: dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.swap: Job dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.swap/start failed with result 'dependency'.
Mär 13 10:03:56 localhost systemd[1]: dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device: Job dev-disk-by\x2duuid-fea36f54\x2d1a3e\x2d4bfb\x2d8f24\x2d9e1d9cf13eb5.device/start failed with result 'timeout'.
Je ne sais pas trop ce qui s'est passé, mais la ligne de l'ancien montage swap était toujours présente !!
Je l'ai commenté, puis ai redémarré le pc.
Il démarre à nouveau "rapidement".
Conclusion:
Après la coupure de courant
- l'UUID de la partition /dev/sd5 a changé (ma swap ici… mais cela peut concerner d'autre partition ?)
- le fstab contenait encore la ligne pour monter ce même uuid. Cette ligne est impérativement à supprimer à la main…
C'est la raison pour laquelle aucun montage de swap ne pouvait avoir lieu avec une UUID fantôme…
Il semble que je ne sois pas le seul a avoir vécu ce genre de mésaventure:
coupure de courant uuid linux
228
je pense que c'est déjà présent, il y a pas mal de tuto.
sudo zypper install systemd-zram-service zramcfg
https://warrenpost.wordpress.com/2020/10/31/enable-zswap-on-opensuse-15-2/ (anglais)
https://www.ctrl.blog/entry/how-to-systemd-zram-generator.html (anglais)
https://kaiserbarbarossa.github.io/post/2021/04/13/systemd-zram/ (allemand)
Je ne connaissais pas, dès que j'ai un peu de temps, je vais essayer.
@Kwinten
Moi j'ai 6 Go de ram, 2 Go de swap, mes partitions sont comme ceci:
thierry@localhost:~> lsblk -o NAME,FSTYPE,SIZE,TYPE,MOUNTPOINT
NAME FSTYPE SIZE TYPE MOUNTPOINT
sda 596,2G disk
├─sda1 ntfs 584,7G part /mnt/Nouveau_Nom
└─sda2 ext4 11,5G part
sdb 931,5G disk
├─sdb1 ntfs 94M part
├─sdb2 ntfs 370,2G part
├─sdb3 ntfs 526M part
├─sdb4 1K part
├─sdb5 swap 2G part [SWAP]
├─sdb6 ext4 30G part /
├─sdb7 ext4 63G part /home
├─sdb8 ext4 416G part /mnt/Dateien_Arbeit
└─sdb9 ext4 49,8G part
J'utilise sdb5, sdb6, sdb7 pour Leap 15.3.
sdb9 pour tumbleweed
le reste c'est win10 et des partitions de données…
Je me sens l'étroit parfois, mais ça fonctionne très bien.
232
Bonjour,
tu peux essayer de temporiser leur mise en service. Le principe est d'ajouter une commande (sleep) à un service, avant que ce service ne démarre. Ce n'est pas du tout garanti que cela fonctionne, mais ça vaut le coup d'essayer ! (c'est sans risque)
Par exemple pour 'stubby', en root dans un terminal:
** vérifie tout d'abord que ton service s'appelle bien stubby.service **
Ensuite dans un terminal en root (ou avec sudo):
# systemctl edit stubby.service
Un éditeur s'ouvre (nano ou vim), c'est vide. Tu tapes:
[Service]
ExecStartPre=/bin/sleep 60
60 → 60 secondes… (30, 120, …, ce que l'on veut)
Il faut sauvegarder !
Pour vérifier que tout va bien, normalement un dossier /etc/systemd/system/stubby.service.d a été créé, il doit contenir un fichier override.conf. Ce dernier contient le script qui a été saisi.
Il est maintenant nécessaire de recharger les fichiers de configuration de systemctl:
# systemctl daemon-reload
Maintenant il faut désactiver puis réactiver (disable - enable) le service stubby (ou restart).
# systemctl restart stubby.service
Éventuellement redémarre ta machine pour voir le comportement au démarrage. Tu peux faire la même opération pour DNSSEC, c'est à toi de voir. Il faut essayer, peut-être augmenter le nombre de secondes… C'est empirique.
Pour revenir en arrière, tu enregistres un fichier vide avec 'systemclt edit stubby', puis tu suis le reste de la procédure.
Il est aussi possible de supprimer le dossier /etc/systemd/system/stubby.service.d (celui qui contient override.conf), puis suivre la même procédure…
233
Bonjour,
Non, systemd-resolved n'est pas activé par défaut. Mais il est activable je pense.
thierry@toto-PC:~> systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: disabled)
…
Je te mets un lien qui pourrait t'intéresser https://shivering-isles.com/Configure-DoT-on-systemd-resolved
C'est sur Fedora, l'article date d'un an. Il y a peut-être possibilité d'adapter cela à Tumbleweed ?
234
Je viens de me lever un peu tard…
Ce matin tout est rentré dans l'ordre. Peut-être la mise à jour tardive d'hier (le paquet samba n'a pas changé), difficile à dire. Peut-être le fait d'avoir réinstallé samba 4.13.13, puis à nouveau samba 4.15.4, je ne sais pas.
Toujours est-il que mon scanner réseau envoie à nouveau le scan vers un dossier "samba" de mon ordi, avec une version 4.15.4
thierry@toto-PC:~> systemctl status smb.service
● smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2022-03-05 09:49:28 CET; 41s ago
…
Version : 4.15.4+git.324.8332acf1a63-150300.3.25.3
Je mets le sujet résolu.
235
Bonjour,
le service samba ne se lance plus correctement avec
Repository : Update repository with updates from SUSE Linux Enterprise 15
Name : samba
Version : 4.15.4+git.324.8332acf1a63-150300.3.25.3
toto-PC:/home/thierry # systemctl status smb
● smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2022-03-04 08:49:33 CET; 1h 45min ago
Docs: man:smbd(8)
man:samba(7)
man:smb.conf(5)
Process: 5362 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
Process: 5370 ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=1/FAILURE)
Main PID: 5370 (code=exited, status=1/FAILURE)
Status: "daemon failed to start: Samba failed to init printing subsystem"
Error: 13 (Keine Berechtigung)
Mär 04 08:49:32 toto-PC systemd[1]: Starting Samba SMB Daemon...
Mär 04 08:49:33 toto-PC smbd[5370]: [2022/03/04 08:49:33.087119, 0] ../../source3/smbd/server.c:1734(main)
Mär 04 08:49:33 toto-PC smbd[5370]: smbd version 4.15.4-git.324.8332acf1a63150300.3.25.3-SUSE-oS15.0-x86_64 started.
Mär 04 08:49:33 toto-PC smbd[5370]: Copyright Andrew Tridgell and the Samba Team 1992-2021
Mär 04 08:49:33 toto-PC systemd[1]: Started Samba SMB Daemon.
Mär 04 08:49:33 toto-PC smbd[5370]: [2022/03/04 08:49:33.143853, 0] ../../lib/util/become_daemon.c:120(exit_daemon)
Mär 04 08:49:33 toto-PC smbd[5370]: exit_daemon: daemon failed to start: Samba failed to init printing subsystem, error code 13
Mär 04 08:49:33 toto-PC systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE
Mär 04 08:49:33 toto-PC systemd[1]: smb.service: Failed with result 'exit-code'.
J'ai installé la version précédente (la 4.13.13+git.539.fdbc44a8598-3.20.2)
v | samba | Paket | 4.15.4+git.324.8332acf1a63-150300.3.25.3 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | samba | Paket | 4.13.13+git.539.fdbc44a8598-3.20.2 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
Le service samba fût à nouveau fonctionnel (je crois que c'est cette sortie, mais peu importe…):
toto-PC:/etc/samba # systemctl status smb
● smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2022-03-04 11:03:40 CET; 2s ago
Docs: man:smbd(8)
man:samba(7)
man:smb.conf(5)
Process: 10774 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
Main PID: 10778 (smbd)
Status: "smbd: ready to serve connections..."
Tasks: 4 (limit: 4915)
CGroup: /system.slice/smb.service
├─10778 /usr/sbin/smbd --foreground --no-process-group
├─10780 /usr/sbin/smbd --foreground --no-process-group
├─10781 /usr/sbin/smbd --foreground --no-process-group
└─10782 /usr/sbin/smbd --foreground --no-process-group
Mär 04 11:03:40 toto-PC systemd[1]: Starting Samba SMB Daemon...
Mär 04 11:03:40 toto-PC smbd[10778]: [2022/03/04 11:03:40.579565, 0] ../../lib/util/become_daemon.c:153(daemon_ready)
Mär 04 11:03:40 toto-PC systemd[1]: Started Samba SMB Daemon.
Mär 04 11:03:40 toto-PC smbd[10778]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
Mon scanner réseau (imprimante…) put à nouveau accéder à mon dossier 'scan' via samba…
Une recherche google ici montre que plusieurs distributions sont (ont été) impactées.
Pour info, je suis ici avec Leap 15.3, je ne sais pas ce qu'il en est avec Tumbleweed…
236
@burn2
Tu as raison, cette version 15.4 a quelque chose de 16. Pas la bière, mais on peut aussi faire avec.
C'est beau ça !
denebe@localhost:~> cat /usr/lib/os-release
NAME="openSUSE Leap"
VERSION="15.4 Beta"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.4"
PRETTY_NAME="openSUSE Leap 15.4 Beta"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
Avec plasma 5.24.2 
denebe@localhost:~> plasmashell --version
plasmashell 5.24.2
- Selon Phoronix, une installation plus facile du codec h.264 et des plugins GStreamer est prévue avec cette version.
- La 'news' officielle: ici.
- Lu sur facebook: "openSUSE Leap 15.4 is expected to reach the beta phase tomorrow. Plan a pizza party!"
Ceux qui veulent tester, Leap 15.4 beta est téléchargeable ici.
237
Bonjour,
je partage simplement une petite mésaventure… J'ai une quantité assez limité en RAM - 6Go - qui se remplit assez vite. À côté de cela, 2Go de swap sont allouées à l'OS.
Il y a quelques jours, j'ai subi une coupure de courant. Après avoir pu redémarré, malgré mes soins, j'ai rempli à plusieurs reprises les 6Go de RAM. C'est en fait ce que j'en déduis, car l'ordinateur ne répondait plus…
Bizarrerie: j'utilisais mon ordinateur peu ou prou comme avant la coupure de courant, mais quelques choses avaient changé semblait-il.
Je viens en fait de voir que ma swap était passée à 0 !
localhost:/home/thierry # swapon -s
localhost:/home/thierry #
Je viens de corriger (graphiquement par yast - partitionneur):
-s comme summery (résumé)
localhost:/home/thierry # swapon -s
Dateiname Typ Größe Benutzt Priorität
/dev/sda5 partition 2097148 512 -2
Bonne journée.
