Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[FreeBSD] Rootfs en nfs

8 réponses
Avatar
JKB
Bonjour à tous,

Petite question du soir. Considérons un serveur NetBSD (7) faisantœ
office de serveur NFS et de serveur de boot (dhcpd + tftp/inet) et
un client diskless FreeBSD (10.2). Les deux machines sont en amd64.

J'ai essayé d'installer directement le client en mode diskless, cela
fonctionne jusqu'au moment où le programme d'installation me demande
le mot de passe root et où cela se bauge lamentablement parce que
/mnt est démonté peu avant. Ce n'est pas grave, j'ai installé le
système sur un disque USB et j'ai recopié le disque USB en question
(avec un pax -rw -p e) sur mon serveur.

J'arrive à booter sans problème. Sauf que j'ai une ribambelle
d'erreurs lors du boot. pxeboot charge le chargeur freebsd qui
lance le noyau. Celui-ci râle sur le fait qu'il ne trouve pas de
rootfs sur le disque USB0 puis finit par trouver judicieux de monter
le rootfs qui est stipuler dans /etc/fstab. Après ce passage
difficile, tout semble fonctionner raisonnablement bien.

Je suppose donc que le noyau a gardé quelque part une indication de
rootfs, mais je ne vois pas où. J'ai regardé dans les fichiers du
chargeur (/boot/defaults), je n'ai rien vu qui puisse correspondre
de près ou de loin à une telle indication.

Une idée ?

Bien cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

8 réponses

Avatar
JKB
Le Wed, 30 Dec 2015 15:53:31 +0000 (UTC),
JKB écrivait :
Bonjour à tous,

Petite question du soir. Considérons un serveur NetBSD (7) faisantœ
office de serveur NFS et de serveur de boot (dhcpd + tftp/inet) et
un client diskless FreeBSD (10.2). Les deux machines sont en amd64.

J'ai essayé d'installer directement le client en mode diskless, cela
fonctionne jusqu'au moment où le programme d'installation me demande
le mot de passe root et où cela se bauge lamentablement parce que
/mnt est démonté peu avant. Ce n'est pas grave, j'ai installé le
système sur un disque USB et j'ai recopié le disque USB en question
(avec un pax -rw -p e) sur mon serveur.

J'arrive à booter sans problème. Sauf que j'ai une ribambelle
d'erreurs lors du boot. pxeboot charge le chargeur freebsd qui
lance le noyau. Celui-ci râle sur le fait qu'il ne trouve pas de
rootfs sur le disque USB0 puis finit par trouver judicieux de monter
le rootfs qui est stipuler dans /etc/fstab. Après ce passage
difficile, tout semble fonctionner raisonnablement bien.

Je suppose donc que le noyau a gardé quelque part une indication de
rootfs, mais je ne vois pas où. J'ai regardé dans les fichiers du
chargeur (/boot/defaults), je n'ai rien vu qui puisse correspondre
de près ou de loin à une telle indication.

Une idée ?

Bien cordialement,



Autre problème qui pollue la console :
atrun[809]: cannot lock /var/at/jobs/: permission denied.

Tout le reste du système fonctionne parfaitement. Naturellement,
tout ce qu'il faut tourne sur le serveurn en particulier statd et
lockd. Sendmail arrive à verrouiller des fichiers sans problème.
J'ai testé qu'il râlait si j'arrêtais lockd sur mon serveur NFS.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Bruno Ducrot
Bonjour,

On 2015-12-30, JKB wrote:
Je suppose donc que le noyau a gardé quelque part une indication de
rootfs, mais je ne vois pas où. J'ai regardé dans les fichiers du
chargeur (/boot/defaults), je n'ai rien vu qui puisse correspondre
de près ou de loin à une telle indication.




Peut-être vfs.root.mountfrom="nfs:rhost:path" ?
Je ne suis pas certain que celà marchera ceci dit.

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
Bruno Ducrot
On 2015-12-31, JKB wrote:
Le Wed, 30 Dec 2015 15:53:31 +0000 (UTC),

Autre problème qui pollue la console :
atrun[809]: cannot lock /var/at/jobs/: permission denied.




Peut-être le répertoire n'appartient-il pas à "daemon" ?

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
JKB
Le Mon, 4 Jan 2016 09:29:58 +0000 (UTC),
Bruno Ducrot écrivait :
On 2015-12-31, JKB wrote:
Le Wed, 30 Dec 2015 15:53:31 +0000 (UTC),

Autre problème qui pollue la console :
atrun[809]: cannot lock /var/at/jobs/: permission denied.




Peut-être le répertoire n'appartient-il pas à "daemon" ?



$ cd /var/at/
$ ls -al
total 8
drwxr-xr-x 4 root wheel 512 Aug 12 17:26 .
drwxr-xr-x 27 root wheel 512 Jan 3 14:49 ..
drwxr-xr-x 2 daemon wheel 512 Aug 12 17:26 jobs
drwxr-xr-x 2 daemon wheel 512 Aug 12 17:26 spool

Si pourtant... Je précise que la copie du système a été faite avec
pax -rw -p e pour garder toutes les autorisations.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
JKB
Le Mon, 4 Jan 2016 09:27:07 +0000 (UTC),
Bruno Ducrot écrivait :
Bonjour,

On 2015-12-30, JKB wrote:
Je suppose donc que le noyau a gardé quelque part une indication de
rootfs, mais je ne vois pas où. J'ai regardé dans les fichiers du
chargeur (/boot/defaults), je n'ai rien vu qui puisse correspondre
de près ou de loin à une telle indication.




Peut-être vfs.root.mountfrom="nfs:rhost:path" ?
Je ne suis pas certain que celà marchera ceci dit.



Je n'ai pas tenté cette expérience (je tenterai le week-end prochain
lorsque j'aurai un face à face avec cette machine).

Il n'empêche que cette configuration ne peut provenir que du noyau
lui-même ou d'un truc dans /boot. Dans dmesg, j'obtiens les messages
suivants :

...
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
ugen0.4: <Unknown> at usbus0 (disconnected)

ce qui est logique, il n'y a pas de disque USB branché. La question
est donc de savoir ce qui se passera lorsqu'une clef USB sera
oubliée dans un port de la machine. Et comme cela échoue, le noyau
passe à autre chose :

uhub_reattach_port: could not allocate new device
Trying to mount root from nfs:192.168.10.128:/srv/pythagore
[nfsv3,tcp,soft,intr,rw]...
NFS ROOT: 192.168.10.128:/srv/pythagore

Là, j'avoue, j'ai un doute. Les options sont celles que j'ai écrites
dans /etc/fstab :

192.168.10.128:/srv/pythagore / nfs nfsv3,tcp,soft,intr,rw 0 0

Or à ce moment-là, je ne vois pas comment le noyau peut trouver ces
options qui sont sur la partition racine. Naturellement, dans le
fichier /etc/dhcpd.conf du serveur, j'ai écrit :

subnet 192.168.10.0 netmask 255.255.255.0 {
host pythagore {
hardware ethernet D8:CB:8A:7D:10:59;
fixed-address 192.168.10.102;
filename "pxeboot";
option root-path "192.168.10.128:/srv/pythagore";
}
}

La question est donc : comment ce fichu truc arrive lors du boot à
monter ma partition racine avec des paramètres qui figurent sur
cette dernière ? Lorsque j'utilise Solaris ou Linux en diskless, le
boot se fait en nfsv2 ou v3, la partition racine est montée par le
noyau en lecture seule puis remontée en lecture/écriture en fonction
des options fournies dans le fichier /etc/fstab. Avec FreeBSD, j'ai
l'impression que la partition racine est déjà montée par le noyau
avec les options du /etc/fstab _avant_ que cette partition soit
montée. Il y a pour moi comme un mystère...

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Bruno Ducrot
On 2016-01-04, JKB wrote:
Le Mon, 4 Jan 2016 09:27:07 +0000 (UTC),
Bruno Ducrot écrivait :
Bonjour,

On 2015-12-30, JKB wrote:
Je suppose donc que le noyau a gardé quelque part une indication de
rootfs, mais je ne vois pas où. J'ai regardé dans les fichiers du
chargeur (/boot/defaults), je n'ai rien vu qui puisse correspondre
de près ou de loin à une telle indication.




Peut-être vfs.root.mountfrom="nfs:rhost:path" ?
Je ne suis pas certain que celà marchera ceci dit.



Je n'ai pas tenté cette expérience (je tenterai le week-end prochain
lorsque j'aurai un face à face avec cette machine).

Il n'empêche que cette configuration ne peut provenir que du noyau
lui-même ou d'un truc dans /boot. Dans dmesg, j'obtiens les messages
suivants :

...
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
ugen0.4: <Unknown> at usbus0 (disconnected)



Là, je sèche. Il faudrait un "show" à partir du prompt de loader. Il
y a probablement un 'rootdev' défini, qui provient lors
de l'installation sur le disque USB, mais je ne sais pas à quel moment
celà se passe. Peut-être qu'un contributeur aura une réponse.

Il faudra probablement définir :
set rootdev="nfs:ip:path"
et aussi (si cette variable est définie)
unset root_disk_unit
dans /boot/loader.rc
(et non pas forcément dans loader.conf).

A tester en tout cas si le mountfrom dans loader.conf ne fonctionne pas.
On a aussi un vfs.mountfrom.options afin de préciser les options de
montage, au cas où cela pourrait aider.


ce qui est logique, il n'y a pas de disque USB branché. La question
est donc de savoir ce qui se passera lorsqu'une clef USB sera
oubliée dans un port de la machine. Et comme cela échoue, le noyau
passe à autre chose :

uhub_reattach_port: could not allocate new device
Trying to mount root from nfs:192.168.10.128:/srv/pythagore
[nfsv3,tcp,soft,intr,rw]...
NFS ROOT: 192.168.10.128:/srv/pythagore

Là, j'avoue, j'ai un doute. Les options sont celles que j'ai écrites
dans /etc/fstab :

192.168.10.128:/srv/pythagore / nfs nfsv3,tcp,soft,intr,rw 0 0

Or à ce moment-là, je ne vois pas comment le noyau peut trouver ces
options qui sont sur la partition racine. Naturellement, dans le
fichier /etc/dhcpd.conf du serveur, j'ai écrit :

subnet 192.168.10.0 netmask 255.255.255.0 {
host pythagore {
hardware ethernet D8:CB:8A:7D:10:59;
fixed-address 192.168.10.102;
filename "pxeboot";
option root-path "192.168.10.128:/srv/pythagore";
}
}

La question est donc : comment ce fichu truc arrive lors du boot à
monter ma partition racine avec des paramètres qui figurent sur
cette dernière ? Lorsque j'utilise Solaris ou Linux en diskless, le
boot se fait en nfsv2 ou v3, la partition racine est montée par le
noyau en lecture seule puis remontée en lecture/écriture en fonction
des options fournies dans le fichier /etc/fstab. Avec FreeBSD, j'ai
l'impression que la partition racine est déjà montée par le noyau
avec les options du /etc/fstab _avant_ que cette partition soit
montée. Il y a pour moi comme un mystère...




Aucune idée. Es-tu certain qu'il n'y a pas eu de remount ?
Normalement, cela se passe dans /etc/rc.initdiskless, lui-même appelé par
/etc/rc.

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
Bruno Ducrot
On 2016-01-04, JKB wrote:
Le Mon, 4 Jan 2016 09:29:58 +0000 (UTC),
Bruno Ducrot écrivait :
On 2015-12-31, JKB wrote:
Le Wed, 30 Dec 2015 15:53:31 +0000 (UTC),

Autre problème qui pollue la console :
atrun[809]: cannot lock /var/at/jobs/: permission denied.




Peut-être le répertoire n'appartient-il pas à "daemon" ?



$ cd /var/at/
$ ls -al
total 8
drwxr-xr-x 4 root wheel 512 Aug 12 17:26 .
drwxr-xr-x 27 root wheel 512 Jan 3 14:49 ..
drwxr-xr-x 2 daemon wheel 512 Aug 12 17:26 jobs
drwxr-xr-x 2 daemon wheel 512 Aug 12 17:26 spool

Si pourtant... Je précise que la copie du système a été faite avec
pax -rw -p e pour garder toutes les autorisations.

Cordialement,




Bon. A part lancer lockd avec l'option '-d' pour voir ce qui se passe,
je ne vois pas.

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
JKB
Le Mon, 4 Jan 2016 11:45:15 +0000 (UTC),
Bruno Ducrot écrivait :
On 2016-01-04, JKB wrote:
Le Mon, 4 Jan 2016 09:27:07 +0000 (UTC),
Bruno Ducrot écrivait :
Bonjour,

On 2015-12-30, JKB wrote:
Je suppose donc que le noyau a gardé quelque part une indication de
rootfs, mais je ne vois pas où. J'ai regardé dans les fichiers du
chargeur (/boot/defaults), je n'ai rien vu qui puisse correspondre
de près ou de loin à une telle indication.




Peut-être vfs.root.mountfrom="nfs:rhost:path" ?
Je ne suis pas certain que celà marchera ceci dit.



Je n'ai pas tenté cette expérience (je tenterai le week-end prochain
lorsque j'aurai un face à face avec cette machine).

Il n'empêche que cette configuration ne peut provenir que du noyau
lui-même ou d'un truc dans /boot. Dans dmesg, j'obtiens les messages
suivants :

...
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_IOERROR
ugen0.4: <Unknown> at usbus0 (disconnected)



Là, je sèche. Il faudrait un "show" à partir du prompt de loader. Il
y a probablement un 'rootdev' défini, qui provient lors
de l'installation sur le disque USB, mais je ne sais pas à quel moment
celà se passe. Peut-être qu'un contributeur aura une réponse.

Il faudra probablement définir :
set rootdev="nfs:ip:path"
et aussi (si cette variable est définie)
unset root_disk_unit
dans /boot/loader.rc
(et non pas forcément dans loader.conf).

A tester en tout cas si le mountfrom dans loader.conf ne fonctionne pas.
On a aussi un vfs.mountfrom.options afin de préciser les options de
montage, au cas où cela pourrait aider.



Je creuserai cela le week-end prochain. Merci pour ces informations.


ce qui est logique, il n'y a pas de disque USB branché. La question
est donc de savoir ce qui se passera lorsqu'une clef USB sera
oubliée dans un port de la machine. Et comme cela échoue, le noyau
passe à autre chose :

uhub_reattach_port: could not allocate new device
Trying to mount root from nfs:192.168.10.128:/srv/pythagore
[nfsv3,tcp,soft,intr,rw]...
NFS ROOT: 192.168.10.128:/srv/pythagore

Là, j'avoue, j'ai un doute. Les options sont celles que j'ai écrites
dans /etc/fstab :

192.168.10.128:/srv/pythagore / nfs nfsv3,tcp,soft,intr,rw 0 0

Or à ce moment-là, je ne vois pas comment le noyau peut trouver ces
options qui sont sur la partition racine. Naturellement, dans le
fichier /etc/dhcpd.conf du serveur, j'ai écrit :

subnet 192.168.10.0 netmask 255.255.255.0 {
host pythagore {
hardware ethernet D8:CB:8A:7D:10:59;
fixed-address 192.168.10.102;
filename "pxeboot";
option root-path "192.168.10.128:/srv/pythagore";
}
}

La question est donc : comment ce fichu truc arrive lors du boot à
monter ma partition racine avec des paramètres qui figurent sur
cette dernière ? Lorsque j'utilise Solaris ou Linux en diskless, le
boot se fait en nfsv2 ou v3, la partition racine est montée par le
noyau en lecture seule puis remontée en lecture/écriture en fonction
des options fournies dans le fichier /etc/fstab. Avec FreeBSD, j'ai
l'impression que la partition racine est déjà montée par le noyau
avec les options du /etc/fstab _avant_ que cette partition soit
montée. Il y a pour moi comme un mystère...




Aucune idée. Es-tu certain qu'il n'y a pas eu de remount ?



Je n'en ai aucune trace visible en tout cas. En tout état de cause,
le noyau tente de monter directement le disque NFS avec les options
du fstab et non les options envoyées par le serveur dhcp.

Normalement, cela se passe dans /etc/rc.initdiskless, lui-même appelé par
/etc/rc.



Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr