Re: systemd systemd-random-seed.service et mount

2023-01-31 Par sujet Christophe Maquaire 
Le mardi 31 janvier 2023 à 11:49 +0100, didier gaumet a écrit :
> 

> *hypothèses* (vu mes connaissances sur le sujet) :-) :
> 
> - ton lien vers /var est *peut-être* la cause parce qu'il serait
> présent 

C'est bien la cause.

> en situation ordinaire mais absent lors du début du boot?
> - donc dans ton cas *peut-être* que créer ce lien dans l'initramfs
> (je 
> n'ai jamais fait mais je suppose que c'est possible?) pourrait
> résoudre 
> ton problème sans nécessité de passer un paramètre d'entropie au 
> bootloader (peut-être d'ailleurs grub2 aussi est-il capable de gérer
> ça...)?
> - par contre tu aurais *peut-être* besoin d'en passer par là si tu 
> utilisais un swap chiffré à chiffrement aléatoire?
> 
> 
En fait en remplaçant le lien par un montage bind dans le fstab, le
problème disparaît.

Merci pour ton aide.

Christophe

Re: systemd systemd-random-seed.service et mount

2023-01-31 Par sujet Christophe Maquaire 
Le mardi 31 janvier 2023 à 11:42 +0100, Basile Starynkevitch a écrit :
> 
> 
> A mon avis le problème est là! Avoir mis un lien symbolique sur /var
> est probablement une mauvaise idée!
> 
Probablement.

> Toutes les fois où (sous Debian comme Ubuntu) /var est un lien
> symbolique (vers un autre système de fichier que la racine) j'ai eu
> des problèmes.
> On pourrait peut-être (mais c'est compliqué) envisager un montage
> bind.

Bin ça marche... 
Après avoir supprimé le lien , mis en options du montage dans mon fstab
defaults,bind pour /lent/var sur /var et après un premier boot pendant
lequel systemd-journal-flush a coincé tout est rentré dans l'ordre. 

> Personnellement je suggère de laisser /var dans le système de fichier
> racine et peut-être d'utiliser des montages bind pour des parties
> moins importantes, par exemple /usr/src 
> Dans mon /etc/fstab j'ai mis la ligne suivante:
> /home/UsrSrc /usr/src none    bind
>  
> Certains d'entre vous pourraient être intéressés par mon utilitaire
> sync-periodically.c ou par le projet logiciel libre RefPerSys.
> Dans ce cas, n'hésitez pas à me contacter (pour vos questions ou
> améliorations) par courriel vers bas...@starynkevitch.net
> Librement

Merci pour la piste.

Christophe

Re: systemd systemd-random-seed.service et mount

2023-01-31 Par sujet didier gaumet 

Le 31/01/2023 à 10:37, Christophe Maquaire a écrit :


Moui mais:
- Il n'y a pas de raison, même si l'entropie générée est faible, que le
service ne démarre pas correctement, j' ai vérifié sur d'autres
machines (bon en stable, certes), et c'est un service "standard" de
systemd installé par debian

[...]

*hypothèses* (vu mes connaissances sur le sujet) :-) :

- ton lien vers /var est *peut-être* la cause parce qu'il serait présent 
en situation ordinaire mais absent lors du début du boot?
- donc dans ton cas *peut-être* que créer ce lien dans l'initramfs (je 
n'ai jamais fait mais je suppose que c'est possible?) pourrait résoudre 
ton problème sans nécessité de passer un paramètre d'entropie au 
bootloader (peut-être d'ailleurs grub2 aussi est-il capable de gérer ça...)?
- par contre tu aurais *peut-être* besoin d'en passer par là si tu 
utilisais un swap chiffré à chiffrement aléatoire?

Re: systemd systemd-random-seed.service et mount

2023-01-31 Par sujet Basile Starynkevitch 


On 31/01/2023 10:48, Christophe Maquaire wrote:

Le lundi 30 janvier 2023 à 13:13 +0100, ajh-valmer a écrit :
Bonjour et merci de t'être peché sur la question

Désolé, ce lien (désolé sur Ubuntu) semble répondre à la question :

https://askubuntu.com/questions/1404691/fwupd-refresh-service-failed

Oui, mais ici il est proposé de de considérer le code de sortie comme
un succès, réel ou non.

Dans mon cas l'échec est réel. en fait après réflexion, mon problème
est lié à mon arborescence de fichiers, mon /var est en fait un lien;



A mon avis le problème est là! Avoir mis un lien symbolique sur /var est 
probablement une mauvaise idée!



Toutes les fois où (sous Debian comme Ubuntu) /var est un lien 
symbolique (vers un autre système de fichier que la racine) j'ai eu des 
problèmes.


On pourrait peut-être (mais c'est compliqué) envisager un montage bind.

Personnellement je suggère de *laisser **/var**dans le système de 
fichier racine* et peut-être d'utiliser des montages bind pour des 
parties moins importantes, par exemple /usr/src


Dans mon /etc/fstab j'ai mis la ligne suivante:

/home/UsrSrc /usr/src none    bind

Certains d'entre vous pourraient être intéressés par mon utilitaire 
sync-periodically.c 
 
ou par le projet logiciel libre RefPerSys .


Dans ce cas, n'hésitez pas à me contacter (pour vos questions ou 
améliorations) par courriel vers bas...@starynkevitch.net 



Librement

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: systemd systemd-random-seed.service et mount

2023-01-31 Par sujet Christophe Maquaire 
Le lundi 30 janvier 2023 à 13:13 +0100, ajh-valmer a écrit :
> 
Bonjour et merci de t'être peché sur la question
> Désolé, ce lien (désolé sur Ubuntu) semble répondre à la question :
> 
> https://askubuntu.com/questions/1404691/fwupd-refresh-service-failed

Oui, mais ici il est proposé de de considérer le code de sortie comme
un succès, réel ou non.

Dans mon cas l'échec est réel. en fait après réflexion, mon problème
est lié à mon arborescence de fichiers, mon /var est en fait un lien;
il semble que le montage de toute l'arborescence soit postérieur à
l'execution du service; donc en continuant ma reflexion je me dis qu'il
faudrait que je sache comment faire pour que l'execution du service
soit postérieure au montage complet de l'arborescence. 

Bon, bin je vais regarder de plus près cette section de systemd-random-
seed.service, bien que ça sorte largement de mon domaine de compétence
sur systemd...



[Unit]
Description=Load/Save Random Seed
Documentation=man:systemd-random-seed.service(8) man:random(4)
DefaultDependencies=no
RequiresMountsFor=/var/lib/systemd/random-seed
Conflicts=shutdown.target
After=systemd-remount-fs.service
Before=first-boot-complete.target shutdown.target
Wants=first-boot-complete.target
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

Merci encore,
Christophe

Re: systemd systemd-random-seed.service et mount

2023-01-31 Par sujet Christophe Maquaire 
Le lundi 30 janvier 2023 à 12:53 +0100, didier gaumet a écrit :
> 
> Bonjour,
> 
> pour situer mon niveau: tu viens de m'apprendre l'existence de ce
> service, donc ne t'attends à des conseils pointus de ma part ;-)
> 
Bonjour, et merci de ta proposition de réponse.

> mais le deuxième paragraphe de la page man du service semble pointer
> vers l'origine de ton souci:
> [...]
> Note that this service runs relatively late during the early boot
> phase, i.e. generally after the initial RAM disk (initrd) completed
> its
> work, and the /var/ file system has been mounted writable. Many
> system
> services require entropy much earlier than this — this service is
> hence
> of limited use for complex system. It is recommended to use a
> bootloader that can pass an initial random seed to the kernel to
> ensure
> that entropy is available from earliest boot on, for example systemd-
> boot(7), with its bootctl random-seed functionality.
> [...]

Moui mais:
- Il n'y a pas de raison, même si l'entropie générée est faible, que le
service ne démarre pas correctement, j' ai vérifié sur d'autres
machines (bon en stable, certes), et c'est un service "standard" de
systemd installé par debian
- pour changer de bootloader, humm... disons que grub ne m'a pas posé
de problèmes depuis longtemps et systemd, en général, c'est bien quand
ça marche mais en cas de problème, on a bien du mal à suivre le fil
pour retrouver qui fait quoi... 

Bon en regardant de plus près, mon /var est un lien sur /lent/var...
root@salicyline:~# ls -la /
lrwxrwxrwx   1 root root 9 26 mars   2014 var -> /lent/var

Je suppose que c'est l'origine de mon problème...

Merci encore

Christophe