a écrit :
Désinstaller "systemd" pour "sysvinit" :
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Deb ian_jessie/sid_installation
> Impossible de lancer le mode graphique que ce soit avec
> lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite (quid ?)
> Ces difficultés viennent-elles de "systemd" et faut-il le dé sinstaller ?
> (je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de configuration
de X avec systemd qui empêchait gdm3 ou kdm (je ne me souvient plus) de
démarrer. En revanche en console, un startx fonctionnait toujours. Je
n'ai jamais eu de problème d'authentification.
Mais j'ai de gros problèmes dans les dépendances des daemons su r mon
serveur de test.
Pour moi, le principal problème est surtout dans le fait que systemd
impose quasiment à chaque coup un reboot du serveur pour être s ûr que
tout se passe correctement. Cordialement, JKB
andre_debian@numericable.fr a écrit :
Désinstaller "systemd" pour "sysvinit" :
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Deb ian_jessie/sid_installation
> Impossible de lancer le mode graphique que ce soit avec
> lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite (quid ?)
> Ces difficultés viennent-elles de "systemd" et faut-il le dé sinstaller ?
> (je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de configuration
de X avec systemd qui empêchait gdm3 ou kdm (je ne me souvient plus) de
démarrer. En revanche en console, un startx fonctionnait toujours. Je
n'ai jamais eu de problème d'authentification.
Mais j'ai de gros problèmes dans les dépendances des daemons su r mon
serveur de test.
Pour moi, le principal problème est surtout dans le fait que systemd
impose quasiment à chaque coup un reboot du serveur pour être s ûr que
tout se passe correctement. Cordialement, JKB
a écrit :
Désinstaller "systemd" pour "sysvinit" :
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Deb ian_jessie/sid_installation
> Impossible de lancer le mode graphique que ce soit avec
> lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite (quid ?)
> Ces difficultés viennent-elles de "systemd" et faut-il le dé sinstaller ?
> (je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de configuration
de X avec systemd qui empêchait gdm3 ou kdm (je ne me souvient plus) de
démarrer. En revanche en console, un startx fonctionnait toujours. Je
n'ai jamais eu de problème d'authentification.
Mais j'ai de gros problèmes dans les dépendances des daemons su r mon
serveur de test.
Pour moi, le principal problème est surtout dans le fait que systemd
impose quasiment à chaque coup un reboot du serveur pour être s ûr que
tout se passe correctement. Cordialement, JKB
J'attendrai plus de maturité de Jessie ou plutôt de systemd dans Jessie.
Il semblerait que systemd fonctionne très bien... si on réinstalle
tout le système et si on n'y touche plus après l'installation. Pas fait
pour moi qui bidouille pas mal et installe en général par
incrémentations.
J'attendrai plus de maturité de Jessie ou plutôt de systemd dans Jessie.
Il semblerait que systemd fonctionne très bien... si on réinstalle
tout le système et si on n'y touche plus après l'installation. Pas fait
pour moi qui bidouille pas mal et installe en général par
incrémentations.
J'attendrai plus de maturité de Jessie ou plutôt de systemd dans Jessie.
Il semblerait que systemd fonctionne très bien... si on réinstalle
tout le système et si on n'y touche plus après l'installation. Pas fait
pour moi qui bidouille pas mal et installe en général par
incrémentations.
apparement le configurateur l'a fais pour moi
:/etc/apache2/mods-available# a2enmod php5
Module php5 already enabled
Le 27/04/2015 14:20, Julien a écrit :Bonjour,
As-tu activé le module php de apache ? :
a2enmod php
As-tu relancé apache ? ton fichier de test se trouve dans ton home ?
Julien
Le 27/04/2015 14:13, a écrit :moi j'ai commencer à tester debian 8 amd64 j'ai installer apache 2.4
et php apache marche php marche pas je sais pas pourquois ...... je
cherche
apt-get install apache2 php5
Le 27/04/2015 14:07, maderios a écrit :On 04/27/2015 10:41 AM, Alain Rpnpif wrote:Bonjour,
Le 26 avril 2015, maderios a écrit :Idem, d'ailleurs Testing marchait bien depuis un petit moment. Par
ailleurs, il faut essayer et utiliser Sid, cela en vaut la peine.
Sid est plus stable/fiable qu'Ubuntu, mais c'est un débat
trollesque...
Mouais.
BonjourPar erreur, il y a 2 semaines, mon fils a mis à jour, sur une
machine de
bureau, Wheezy avec sid et son systemd. Malheur lui en a pris, car
plus
moyen de de connecter en Xorg.
Après tentative de remettre sysvinit, systemd a mis un de ces bazars
tel que seul la console de maintenance fonctionnait. Il semble que
systemd avec Xorg n'aime pas du tout le changement de libc6.
Après 2 ou 3 heures de travail, tout est revenu dans l'ordre.
En 2015, passer sans transition de Wheezy à Sid, cela représente un
saut dans l'espace-temps considérable. Il est donc logique qu'il
faille revoir certaines configurations, il est même étonnant que
cela se passe si bien pour toi.
- J'utilise Sid pour travailler sur un PC, systemd marche bien et
me simplifie la vie par rapport à Sysvinit. Aucun souci ailleurs.
- J'utilise Jessie pour ménager un vieux (> 12 ans) portable
poussif, donc rares mises à jour, c'est l'intérêt de stable.
- J'ai réalisé tardivement que Testing n'est pas très sûr dans la
mesure où les maj de sécurité arrivent toujours très tard par
rapport à Sid et Stable.
apparement le configurateur l'a fais pour moi
root@deb8test:/etc/apache2/mods-available# a2enmod php5
Module php5 already enabled
Le 27/04/2015 14:20, Julien a écrit :
Bonjour,
As-tu activé le module php de apache ? :
a2enmod php
As-tu relancé apache ? ton fichier de test se trouve dans ton home ?
Julien
Le 27/04/2015 14:13, contact@baal.fr a écrit :
moi j'ai commencer à tester debian 8 amd64 j'ai installer apache 2.4
et php apache marche php marche pas je sais pas pourquois ...... je
cherche
apt-get install apache2 php5
Le 27/04/2015 14:07, maderios a écrit :
On 04/27/2015 10:41 AM, Alain Rpnpif wrote:
Bonjour,
Le 26 avril 2015, maderios a écrit :
Idem, d'ailleurs Testing marchait bien depuis un petit moment. Par
ailleurs, il faut essayer et utiliser Sid, cela en vaut la peine.
Sid est plus stable/fiable qu'Ubuntu, mais c'est un débat
trollesque...
Mouais.
Bonjour
Par erreur, il y a 2 semaines, mon fils a mis à jour, sur une
machine de
bureau, Wheezy avec sid et son systemd. Malheur lui en a pris, car
plus
moyen de de connecter en Xorg.
Après tentative de remettre sysvinit, systemd a mis un de ces bazars
tel que seul la console de maintenance fonctionnait. Il semble que
systemd avec Xorg n'aime pas du tout le changement de libc6.
Après 2 ou 3 heures de travail, tout est revenu dans l'ordre.
En 2015, passer sans transition de Wheezy à Sid, cela représente un
saut dans l'espace-temps considérable. Il est donc logique qu'il
faille revoir certaines configurations, il est même étonnant que
cela se passe si bien pour toi.
- J'utilise Sid pour travailler sur un PC, systemd marche bien et
me simplifie la vie par rapport à Sysvinit. Aucun souci ailleurs.
- J'utilise Jessie pour ménager un vieux (> 12 ans) portable
poussif, donc rares mises à jour, c'est l'intérêt de stable.
- J'ai réalisé tardivement que Testing n'est pas très sûr dans la
mesure où les maj de sécurité arrivent toujours très tard par
rapport à Sid et Stable.
apparement le configurateur l'a fais pour moi
:/etc/apache2/mods-available# a2enmod php5
Module php5 already enabled
Le 27/04/2015 14:20, Julien a écrit :Bonjour,
As-tu activé le module php de apache ? :
a2enmod php
As-tu relancé apache ? ton fichier de test se trouve dans ton home ?
Julien
Le 27/04/2015 14:13, a écrit :moi j'ai commencer à tester debian 8 amd64 j'ai installer apache 2.4
et php apache marche php marche pas je sais pas pourquois ...... je
cherche
apt-get install apache2 php5
Le 27/04/2015 14:07, maderios a écrit :On 04/27/2015 10:41 AM, Alain Rpnpif wrote:Bonjour,
Le 26 avril 2015, maderios a écrit :Idem, d'ailleurs Testing marchait bien depuis un petit moment. Par
ailleurs, il faut essayer et utiliser Sid, cela en vaut la peine.
Sid est plus stable/fiable qu'Ubuntu, mais c'est un débat
trollesque...
Mouais.
BonjourPar erreur, il y a 2 semaines, mon fils a mis à jour, sur une
machine de
bureau, Wheezy avec sid et son systemd. Malheur lui en a pris, car
plus
moyen de de connecter en Xorg.
Après tentative de remettre sysvinit, systemd a mis un de ces bazars
tel que seul la console de maintenance fonctionnait. Il semble que
systemd avec Xorg n'aime pas du tout le changement de libc6.
Après 2 ou 3 heures de travail, tout est revenu dans l'ordre.
En 2015, passer sans transition de Wheezy à Sid, cela représente un
saut dans l'espace-temps considérable. Il est donc logique qu'il
faille revoir certaines configurations, il est même étonnant que
cela se passe si bien pour toi.
- J'utilise Sid pour travailler sur un PC, systemd marche bien et
me simplifie la vie par rapport à Sysvinit. Aucun souci ailleurs.
- J'utilise Jessie pour ménager un vieux (> 12 ans) portable
poussif, donc rares mises à jour, c'est l'intérêt de stable.
- J'ai réalisé tardivement que Testing n'est pas très sûr dans la
mesure où les maj de sécurité arrivent toujours très tard par
rapport à Sid et Stable.
On 04/27/2015 04:49 PM, BERTRAND Joël wrote:maderios a écrit :On 04/27/2015 03:56 PM, BERTRAND Joël wrote:a écrit :Impossible de lancer le mode graphique que ce soit avec
lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite
(quid ?)
Problème de PAM ?
Et miracle, enfin "tdm-trinity" se lance avec mot de passe accepté...
Aurais-je le même parcours du combattant lors du prochain boot ?
Ces difficultés viennent-elles de "systemd" et faut-il le
désinstaller ?
(je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de
configuration de X avec systemd qui empêchait gdm3 ou kdm (je ne me
souvient plus) de démarrer. En revanche en console, un startx
fonctionnait toujours. Je n'ai jamais eu de problème
d'authentification.
Mais j'ai de gros problèmes dans les dépendances des daemons sur
mon serveur de test.
Pour moi, le principal problème est surtout dans le fait que
systemd impose quasiment à chaque coup un reboot du serveur pour être
sûr que tout se passe correctement.
Bonjour
Systemd n'est pas Sysvinit. Normalement, pas besoin de reboot pour que
Systemd active et démarre un service/daemon.
Les commandes existent pour cela...
Ce n'est _pas_ le problème. Après la dernière mise à jour de
systemd, une partie des modules du noyau (dont nfsd) ont été virés avec
l'impossibilité de le recharger à la main. Je n'ai pas eu le temps de
chercher, j'ai rebooté. Pour information, cela m'est arrivé plusieurs
fois.
C'est bien une histoire d'initialisation d'un service (ici nfs) avec une
commande de systemd. Tant que cela n'est pas fait, tu peux rebooter à
l'infini sans espoir...
Pour nfs:
systemctl enable nfs-common
Synchronizing state for nfs-common.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common enable
systemctl start nfs-common
Ensuite idem avec nfs-kernel-server, rpcbind/dépendances et autres
services qui ne démarrent pas au boot.
C'est maintenant bien au point chez Debian mais au début de
l'intégration de systemd, il m'a fallu tout démarrer à la main quand ça
voulait bien (re)démarrer...
On 04/27/2015 04:49 PM, BERTRAND Joël wrote:
maderios a écrit :
On 04/27/2015 03:56 PM, BERTRAND Joël wrote:
andre_debian@numericable.fr a écrit :
Impossible de lancer le mode graphique que ce soit avec
lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite
(quid ?)
Problème de PAM ?
Et miracle, enfin "tdm-trinity" se lance avec mot de passe accepté...
Aurais-je le même parcours du combattant lors du prochain boot ?
Ces difficultés viennent-elles de "systemd" et faut-il le
désinstaller ?
(je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de
configuration de X avec systemd qui empêchait gdm3 ou kdm (je ne me
souvient plus) de démarrer. En revanche en console, un startx
fonctionnait toujours. Je n'ai jamais eu de problème
d'authentification.
Mais j'ai de gros problèmes dans les dépendances des daemons sur
mon serveur de test.
Pour moi, le principal problème est surtout dans le fait que
systemd impose quasiment à chaque coup un reboot du serveur pour être
sûr que tout se passe correctement.
Bonjour
Systemd n'est pas Sysvinit. Normalement, pas besoin de reboot pour que
Systemd active et démarre un service/daemon.
Les commandes existent pour cela...
Ce n'est _pas_ le problème. Après la dernière mise à jour de
systemd, une partie des modules du noyau (dont nfsd) ont été virés avec
l'impossibilité de le recharger à la main. Je n'ai pas eu le temps de
chercher, j'ai rebooté. Pour information, cela m'est arrivé plusieurs
fois.
C'est bien une histoire d'initialisation d'un service (ici nfs) avec une
commande de systemd. Tant que cela n'est pas fait, tu peux rebooter à
l'infini sans espoir...
Pour nfs:
systemctl enable nfs-common
Synchronizing state for nfs-common.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common enable
systemctl start nfs-common
Ensuite idem avec nfs-kernel-server, rpcbind/dépendances et autres
services qui ne démarrent pas au boot.
C'est maintenant bien au point chez Debian mais au début de
l'intégration de systemd, il m'a fallu tout démarrer à la main quand ça
voulait bien (re)démarrer...
On 04/27/2015 04:49 PM, BERTRAND Joël wrote:maderios a écrit :On 04/27/2015 03:56 PM, BERTRAND Joël wrote:a écrit :Impossible de lancer le mode graphique que ce soit avec
lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite
(quid ?)
Problème de PAM ?
Et miracle, enfin "tdm-trinity" se lance avec mot de passe accepté...
Aurais-je le même parcours du combattant lors du prochain boot ?
Ces difficultés viennent-elles de "systemd" et faut-il le
désinstaller ?
(je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de
configuration de X avec systemd qui empêchait gdm3 ou kdm (je ne me
souvient plus) de démarrer. En revanche en console, un startx
fonctionnait toujours. Je n'ai jamais eu de problème
d'authentification.
Mais j'ai de gros problèmes dans les dépendances des daemons sur
mon serveur de test.
Pour moi, le principal problème est surtout dans le fait que
systemd impose quasiment à chaque coup un reboot du serveur pour être
sûr que tout se passe correctement.
Bonjour
Systemd n'est pas Sysvinit. Normalement, pas besoin de reboot pour que
Systemd active et démarre un service/daemon.
Les commandes existent pour cela...
Ce n'est _pas_ le problème. Après la dernière mise à jour de
systemd, une partie des modules du noyau (dont nfsd) ont été virés avec
l'impossibilité de le recharger à la main. Je n'ai pas eu le temps de
chercher, j'ai rebooté. Pour information, cela m'est arrivé plusieurs
fois.
C'est bien une histoire d'initialisation d'un service (ici nfs) avec une
commande de systemd. Tant que cela n'est pas fait, tu peux rebooter à
l'infini sans espoir...
Pour nfs:
systemctl enable nfs-common
Synchronizing state for nfs-common.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common enable
systemctl start nfs-common
Ensuite idem avec nfs-kernel-server, rpcbind/dépendances et autres
services qui ne démarrent pas au boot.
C'est maintenant bien au point chez Debian mais au début de
l'intégration de systemd, il m'a fallu tout démarrer à la main quand ça
voulait bien (re)démarrer...
maderios a écrit :On 04/27/2015 04:49 PM, BERTRAND Joël wrote:maderios a écrit :On 04/27/2015 03:56 PM, BERTRAND Joël wrote:a écrit :Impossible de lancer le mode graphique que ce soit avec
lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite
(quid ?)
Problème de PAM ?
Et miracle, enfin "tdm-trinity" se lance avec mot de passe
accepté...
Aurais-je le même parcours du combattant lors du prochain boot ?
Ces difficultés viennent-elles de "systemd" et faut-il le
désinstaller ?
(je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de
configuration de X avec systemd qui empêchait gdm3 ou kdm (je
ne me
souvient plus) de démarrer. En revanche en console, un startx
fonctionnait toujours. Je n'ai jamais eu de problème
d'authentification.
Mais j'ai de gros problèmes dans les dépendances des
daemons sur
mon serveur de test.
Pour moi, le principal problème est surtout dans le fait que
systemd impose quasiment à chaque coup un reboot du serveur
pour être
sûr que tout se passe correctement.
Bonjour
Systemd n'est pas Sysvinit. Normalement, pas besoin de reboot
pour que
Systemd active et démarre un service/daemon.
Les commandes existent pour cela...
Ce n'est _pas_ le problème. Après la dernière mise à jour de
systemd, une partie des modules du noyau (dont nfsd) ont été
virés avec
l'impossibilité de le recharger à la main. Je n'ai pas eu le
temps de
chercher, j'ai rebooté. Pour information, cela m'est arrivé
plusieurs
fois.
C'est bien une histoire d'initialisation d'un service (ici nfs)
avec une
commande de systemd. Tant que cela n'est pas fait, tu peux rebooter à
l'infini sans espoir...
Pour nfs:
systemctl enable nfs-common
Synchronizing state for nfs-common.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common enable
systemctl start nfs-common
Ensuite idem avec nfs-kernel-server, rpcbind/dépendances et autres
services qui ne démarrent pas au boot.
C'est maintenant bien au point chez Debian mais au début de
l'intégration de systemd, il m'a fallu tout démarrer à la main
quand ça
voulait bien (re)démarrer...
Franchement, je ne t'ai pas attendu pour faire ça. Mais dans mon
cas, cela ne suffit pas. Et ne me demande pas pourquoi. Quand un
serveur, fût-il de test, est en rade, au bout de quelques minutes,
tu dois trouver une solution fiable et pérenne.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
maderios a écrit :
On 04/27/2015 04:49 PM, BERTRAND Joël wrote:
maderios a écrit :
On 04/27/2015 03:56 PM, BERTRAND Joël wrote:
andre_debian@numericable.fr a écrit :
Impossible de lancer le mode graphique que ce soit avec
lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite
(quid ?)
Problème de PAM ?
Et miracle, enfin "tdm-trinity" se lance avec mot de passe
accepté...
Aurais-je le même parcours du combattant lors du prochain boot ?
Ces difficultés viennent-elles de "systemd" et faut-il le
désinstaller ?
(je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de
configuration de X avec systemd qui empêchait gdm3 ou kdm (je
ne me
souvient plus) de démarrer. En revanche en console, un startx
fonctionnait toujours. Je n'ai jamais eu de problème
d'authentification.
Mais j'ai de gros problèmes dans les dépendances des
daemons sur
mon serveur de test.
Pour moi, le principal problème est surtout dans le fait que
systemd impose quasiment à chaque coup un reboot du serveur
pour être
sûr que tout se passe correctement.
Bonjour
Systemd n'est pas Sysvinit. Normalement, pas besoin de reboot
pour que
Systemd active et démarre un service/daemon.
Les commandes existent pour cela...
Ce n'est _pas_ le problème. Après la dernière mise à jour de
systemd, une partie des modules du noyau (dont nfsd) ont été
virés avec
l'impossibilité de le recharger à la main. Je n'ai pas eu le
temps de
chercher, j'ai rebooté. Pour information, cela m'est arrivé
plusieurs
fois.
C'est bien une histoire d'initialisation d'un service (ici nfs)
avec une
commande de systemd. Tant que cela n'est pas fait, tu peux rebooter à
l'infini sans espoir...
Pour nfs:
systemctl enable nfs-common
Synchronizing state for nfs-common.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common enable
systemctl start nfs-common
Ensuite idem avec nfs-kernel-server, rpcbind/dépendances et autres
services qui ne démarrent pas au boot.
C'est maintenant bien au point chez Debian mais au début de
l'intégration de systemd, il m'a fallu tout démarrer à la main
quand ça
voulait bien (re)démarrer...
Franchement, je ne t'ai pas attendu pour faire ça. Mais dans mon
cas, cela ne suffit pas. Et ne me demande pas pourquoi. Quand un
serveur, fût-il de test, est en rade, au bout de quelques minutes,
tu dois trouver une solution fiable et pérenne.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/553EAF35.5000506@systella.fr
maderios a écrit :On 04/27/2015 04:49 PM, BERTRAND Joël wrote:maderios a écrit :On 04/27/2015 03:56 PM, BERTRAND Joël wrote:a écrit :Impossible de lancer le mode graphique que ce soit avec
lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite
(quid ?)
Problème de PAM ?
Et miracle, enfin "tdm-trinity" se lance avec mot de passe
accepté...
Aurais-je le même parcours du combattant lors du prochain boot ?
Ces difficultés viennent-elles de "systemd" et faut-il le
désinstaller ?
(je n'ose le faire sans quelques avis...)
Difficile à dire comme ça. Je n'ai eu qu'un problème de
configuration de X avec systemd qui empêchait gdm3 ou kdm (je
ne me
souvient plus) de démarrer. En revanche en console, un startx
fonctionnait toujours. Je n'ai jamais eu de problème
d'authentification.
Mais j'ai de gros problèmes dans les dépendances des
daemons sur
mon serveur de test.
Pour moi, le principal problème est surtout dans le fait que
systemd impose quasiment à chaque coup un reboot du serveur
pour être
sûr que tout se passe correctement.
Bonjour
Systemd n'est pas Sysvinit. Normalement, pas besoin de reboot
pour que
Systemd active et démarre un service/daemon.
Les commandes existent pour cela...
Ce n'est _pas_ le problème. Après la dernière mise à jour de
systemd, une partie des modules du noyau (dont nfsd) ont été
virés avec
l'impossibilité de le recharger à la main. Je n'ai pas eu le
temps de
chercher, j'ai rebooté. Pour information, cela m'est arrivé
plusieurs
fois.
C'est bien une histoire d'initialisation d'un service (ici nfs)
avec une
commande de systemd. Tant que cela n'est pas fait, tu peux rebooter à
l'infini sans espoir...
Pour nfs:
systemctl enable nfs-common
Synchronizing state for nfs-common.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common enable
systemctl start nfs-common
Ensuite idem avec nfs-kernel-server, rpcbind/dépendances et autres
services qui ne démarrent pas au boot.
C'est maintenant bien au point chez Debian mais au début de
l'intégration de systemd, il m'a fallu tout démarrer à la main
quand ça
voulait bien (re)démarrer...
Franchement, je ne t'ai pas attendu pour faire ça. Mais dans mon
cas, cela ne suffit pas. Et ne me demande pas pourquoi. Quand un
serveur, fût-il de test, est en rade, au bout de quelques minutes,
tu dois trouver une solution fiable et pérenne.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Si ça peut rendre service à ceux qui ont les mêmes problèmes que moi :
si je désinstalle "systemd", au profit de "sysvinit",
pourrais-je le réinstaller ensuite ?
(en cas de plantage du système et revenir à systemd).
Si ça peut rendre service à ceux qui ont les mêmes problèmes que moi :
si je désinstalle "systemd", au profit de "sysvinit",
pourrais-je le réinstaller ensuite ?
(en cas de plantage du système et revenir à systemd).
Si ça peut rendre service à ceux qui ont les mêmes problèmes que moi :
si je désinstalle "systemd", au profit de "sysvinit",
pourrais-je le réinstaller ensuite ?
(en cas de plantage du système et revenir à systemd).
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1°
install de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec
Jessie et Sid. Le problème vient des utilisateurs et non de Systemd. Il
faut savoir que la transition depuis Sysvinit n'est pas automatique mais
les commandes de systemd (cf message précédent + doc abondante sur le
net) sont faites pour assurer cette transition, encore faut-il avoir la
volonté de les utiliser...
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1°
install de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec
Jessie et Sid. Le problème vient des utilisateurs et non de Systemd. Il
faut savoir que la transition depuis Sysvinit n'est pas automatique mais
les commandes de systemd (cf message précédent + doc abondante sur le
net) sont faites pour assurer cette transition, encore faut-il avoir la
volonté de les utiliser...
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1°
install de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec
Jessie et Sid. Le problème vient des utilisateurs et non de Systemd. Il
faut savoir que la transition depuis Sysvinit n'est pas automatique mais
les commandes de systemd (cf message précédent + doc abondante sur le
net) sont faites pour assurer cette transition, encore faut-il avoir la
volonté de les utiliser...
On 04/27/2015 09:23 PM, Alain Rpnpif wrote:
>J'attendrai plus de maturité de Jessie ou plutôt de systemd dans Jessie.
>Il semblerait que systemd fonctionne très bien... si on réinstalle
>tout le système et si on n'y touche plus après l'installation. Pas fait
>pour moi qui bidouille pas mal et installe en général par
>incrémentations.
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1° install
de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec Jessie et
Sid. Le problème vient des utilisateurs et non de Systemd. Il faut savoir
que la transition depuis Sysvinit n'est pas automatique mais les commandes
de systemd (cf message précédent + doc abondante sur le net) sont faites
pour assurer cette transition, encore faut-il avoir la volonté de les
utiliser...
On 04/27/2015 09:23 PM, Alain Rpnpif wrote:
>J'attendrai plus de maturité de Jessie ou plutôt de systemd dans Jessie.
>Il semblerait que systemd fonctionne très bien... si on réinstalle
>tout le système et si on n'y touche plus après l'installation. Pas fait
>pour moi qui bidouille pas mal et installe en général par
>incrémentations.
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1° install
de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec Jessie et
Sid. Le problème vient des utilisateurs et non de Systemd. Il faut savoir
que la transition depuis Sysvinit n'est pas automatique mais les commandes
de systemd (cf message précédent + doc abondante sur le net) sont faites
pour assurer cette transition, encore faut-il avoir la volonté de les
utiliser...
On 04/27/2015 09:23 PM, Alain Rpnpif wrote:
>J'attendrai plus de maturité de Jessie ou plutôt de systemd dans Jessie.
>Il semblerait que systemd fonctionne très bien... si on réinstalle
>tout le système et si on n'y touche plus après l'installation. Pas fait
>pour moi qui bidouille pas mal et installe en général par
>incrémentations.
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1° install
de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec Jessie et
Sid. Le problème vient des utilisateurs et non de Systemd. Il faut savoir
que la transition depuis Sysvinit n'est pas automatique mais les commandes
de systemd (cf message précédent + doc abondante sur le net) sont faites
pour assurer cette transition, encore faut-il avoir la volonté de les
utiliser...
Pour moi c'est plutôt au soft de s'adapter aux utilisateurs que le
contraire. Surtout quand 90% des utilisateurs n'ont pas demandé à
utiliser ce soft.
Pour moi c'est plutôt au soft de s'adapter aux utilisateurs que le
contraire. Surtout quand 90% des utilisateurs n'ont pas demandé à
utiliser ce soft.
Pour moi c'est plutôt au soft de s'adapter aux utilisateurs que le
contraire. Surtout quand 90% des utilisateurs n'ont pas demandé à
utiliser ce soft.
Le 27 avril 2015, maderios a écrit :Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1°
install de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec
Jessie et Sid. Le problème vient des utilisateurs et non de Systemd. Il
faut savoir que la transition depuis Sysvinit n'est pas automatique mais
les commandes de systemd (cf message précédent + doc abondante sur le
net) sont faites pour assurer cette transition, encore faut-il avoir la
volonté de les utiliser...
Appréciation subjective et désobligeante.
Quand je disais réinstallé ce n'était pas avec l'installeur mais avec
apt-get et aptitude.
Par contre, effectivement je n'ai pas "la volonté d'utiliser" systemd.
Je n'y vois, aujourd'hui, aucun intérêt pour moi à part des
complications.
Le 27 avril 2015, maderios a écrit :
Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1°
install de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec
Jessie et Sid. Le problème vient des utilisateurs et non de Systemd. Il
faut savoir que la transition depuis Sysvinit n'est pas automatique mais
les commandes de systemd (cf message précédent + doc abondante sur le
net) sont faites pour assurer cette transition, encore faut-il avoir la
volonté de les utiliser...
Appréciation subjective et désobligeante.
Quand je disais réinstallé ce n'était pas avec l'installeur mais avec
apt-get et aptitude.
Par contre, effectivement je n'ai pas "la volonté d'utiliser" systemd.
Je n'y vois, aujourd'hui, aucun intérêt pour moi à part des
complications.
Le 27 avril 2015, maderios a écrit :Bidouilleur amateur, je n'ai jamais réinstallé Debian depuis ma 1°
install de Potatoe (1999?) et Systemd fonctionne maintenant nickel avec
Jessie et Sid. Le problème vient des utilisateurs et non de Systemd. Il
faut savoir que la transition depuis Sysvinit n'est pas automatique mais
les commandes de systemd (cf message précédent + doc abondante sur le
net) sont faites pour assurer cette transition, encore faut-il avoir la
volonté de les utiliser...
Appréciation subjective et désobligeante.
Quand je disais réinstallé ce n'était pas avec l'installeur mais avec
apt-get et aptitude.
Par contre, effectivement je n'ai pas "la volonté d'utiliser" systemd.
Je n'y vois, aujourd'hui, aucun intérêt pour moi à part des
complications.