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,
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,
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,
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.
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.
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.
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.
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.
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.
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" ?
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" ?
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" ?
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.
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.
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.
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...
Le Mon, 4 Jan 2016 09:27:07 +0000 (UTC),
Bruno Ducrot <ducrot@echo.fr> é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...
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...
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,
Le Mon, 4 Jan 2016 09:29:58 +0000 (UTC),
Bruno Ducrot <ducrot@echo.fr> é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,
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,
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.
On 2016-01-04, JKB wrote:
Le Mon, 4 Jan 2016 09:27:07 +0000 (UTC),
Bruno Ducrot <ducrot@echo.fr> é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.
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.
