Plus je m'=E9loigne de Debian plus je vois ses "probl=E8mes".
Je r=E9sume.
1) Debian est une tr=E8s bonne distrib pour les serveurs, d'accord.
A mon avis, leur fa=E7on de geler les paquets requiert =E9norm=E9ment de
ressources, et cette fa=E7on de faire devrait =EAtre r=E9serv=E9e aux
entreprises. (Puisque une entreprise comme RH, on l'a paie en partie
pour les backports des probl=E8mes de s=E9curit=E9. Si RH utilisait les
derni=E8res versions upstream elle serait moins ch=E8re).
Bon, ils veulent le faire quand m=EAme, fort bien, mais pourquoi le
faire sur 25000 paquets ? Est-ce vraiment raisonnable ? C'est des
questions que j'aimerais qu'ils se posent.
2) Debian semble essayer de viser =E9galement les utilisateurs desktop.
Sauf que ni -testing, ni -unstable ne sont faits officiellement pour.
L'initrd (enfin l'initramfs) parse le /proc/cmdline et tu peux utiliser les mots clés debug, ou break.
Lapin compris...
Le pseudo-fichier /proc/cmdline contient les options de démarrage passées par le chargeur (lilo, grub...) au noyau. Certaines de ces options sont des paramètres du noyau, d'autres peuvent servir à autre chose. Si j'ai bien compris, Kevin dit que parmi ces options l'initrd reconnaît les mots-clés "debug" et "break". Apparemment "break" interrompt l'exécution de l'initrd et lance un shell (ash). En revanche je n'ai pas vu l'effet de "debug".
Pour (encore) plus d'infos, il est possible d'ouvrir l'initramfs: zcat initramfs.gz | cpio -i -d -H newc --no-absolute-filenames
Peux-tu détailler, steupl ? Il est où ce fichier initramfs.gz ?
C'est le fichier /boot/initrd.img-<version_du_noyau>. C'est une archive cpio (un peu comme tar, mais avec un format différent) compressée par gzip.
Le script lancé est le script /init, sa lecture est intéressante.
pas de script init à la racine sur ma debian...
Il est dans l'initrd, pas dans la partition racine.
Hugolino a écrit :
Le 24 Oct 2008 21:30:37 GMT, Kevin Denis a écrit:
L'initrd (enfin l'initramfs) parse le /proc/cmdline et tu peux utiliser
les mots clés debug, ou break.
Lapin compris...
Le pseudo-fichier /proc/cmdline contient les options de démarrage
passées par le chargeur (lilo, grub...) au noyau. Certaines de ces
options sont des paramètres du noyau, d'autres peuvent servir à autre
chose. Si j'ai bien compris, Kevin dit que parmi ces options l'initrd
reconnaît les mots-clés "debug" et "break". Apparemment "break"
interrompt l'exécution de l'initrd et lance un shell (ash). En revanche
je n'ai pas vu l'effet de "debug".
Pour (encore) plus d'infos, il est possible d'ouvrir l'initramfs:
zcat initramfs.gz | cpio -i -d -H newc --no-absolute-filenames
Peux-tu détailler, steupl ? Il est où ce fichier initramfs.gz ?
C'est le fichier /boot/initrd.img-<version_du_noyau>. C'est une archive
cpio (un peu comme tar, mais avec un format différent) compressée par gzip.
Le script lancé est le script /init, sa lecture est intéressante.
pas de script init à la racine sur ma debian...
Il est dans l'initrd, pas dans la partition racine.
L'initrd (enfin l'initramfs) parse le /proc/cmdline et tu peux utiliser les mots clés debug, ou break.
Lapin compris...
Le pseudo-fichier /proc/cmdline contient les options de démarrage passées par le chargeur (lilo, grub...) au noyau. Certaines de ces options sont des paramètres du noyau, d'autres peuvent servir à autre chose. Si j'ai bien compris, Kevin dit que parmi ces options l'initrd reconnaît les mots-clés "debug" et "break". Apparemment "break" interrompt l'exécution de l'initrd et lance un shell (ash). En revanche je n'ai pas vu l'effet de "debug".
Pour (encore) plus d'infos, il est possible d'ouvrir l'initramfs: zcat initramfs.gz | cpio -i -d -H newc --no-absolute-filenames
Peux-tu détailler, steupl ? Il est où ce fichier initramfs.gz ?
C'est le fichier /boot/initrd.img-<version_du_noyau>. C'est une archive cpio (un peu comme tar, mais avec un format différent) compressée par gzip.
Le script lancé est le script /init, sa lecture est intéressante.
pas de script init à la racine sur ma debian...
Il est dans l'initrd, pas dans la partition racine.
Toxico Nimbus
Stéphane CARPENTIER a écrit :
Toxico Nimbus wrote:
Stéphane CARPENTIER a écrit :
En dehors de l'écran, bleu, bien sûr, ce serait trop facile.
pfff, l'écran bleu c'est une repompe moisie du guru meditation de l'AmigaOS.
Désolé, je ne voulais vexer personne.
En plus, le bsod, c'est pas vraiment blink-blink.
Stéphane CARPENTIER a écrit :
Toxico Nimbus wrote:
Stéphane CARPENTIER a écrit :
En dehors de l'écran, bleu, bien sûr, ce serait trop facile.
pfff, l'écran bleu c'est une repompe moisie du guru meditation de
l'AmigaOS.
En dehors de l'écran, bleu, bien sûr, ce serait trop facile.
pfff, l'écran bleu c'est une repompe moisie du guru meditation de l'AmigaOS.
Désolé, je ne voulais vexer personne.
En plus, le bsod, c'est pas vraiment blink-blink.
Patrice Karatchentzeff
"Thierry B." a écrit :
--{ Patrice Karatchentzeff a plopé ceci: }--
>> à comprendre: par exemple, avec aptitude on peut installer ou >> enlever des paquets, mais on ne peut pas avoir la liste des >> paquets installés. Il faut passer par une obscure option de >> dpkg... > > # aptitude search ".*" | egrep "^i"
>> à comprendre: par exemple, avec aptitude on peut installer ou
>> enlever des paquets, mais on ne peut pas avoir la liste des
>> paquets installés. Il faut passer par une obscure option de
>> dpkg...
>
> # aptitude search ".*" | egrep "^i"
>> à comprendre: par exemple, avec aptitude on peut installer ou >> enlever des paquets, mais on ne peut pas avoir la liste des >> paquets installés. Il faut passer par une obscure option de >> dpkg... > > # aptitude search ".*" | egrep "^i"
Non, c'est juste que j'aurais bien vu unc commande d'aptitude qui sorte juste la liste des paquets installés... On peut espérer...
-- "Ce qui est affirmé sans preuve est nié sans preuve" (c) Pipolin
Droopy191
Hugolino a écrit :
Le Thu, 23 Oct 2008 16:19:48 +0200, Pascal Hambourg a écrit:
Hugolino a écrit :
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été installé --> reboot incapable de monter la racine. Je soupçonne fortement que c'est à cause de fstab qui référence les partitions par /dev/hdXY alors que etchnhalf doit attendre des champs UUID.
J'ai du noyau etchnhalf qui tourne sur deux machines, et pas vu d'UUID.
Ça n'était qu'un soupçon... Je n'ai pas cherché à résoudre le problème.
Salut,
Je viens de tenter un upgrade de Etch vers Lenny. J'ai le sentiment que le pb que j'ai rencontré est le meme.
Carte mère MSI K9N SLI Platinum ( si ca a une importance ? ) Debian Etch AMD64 d'origine debian.
Changement des sources, passage en Lenny -> reboot sur le noyau 2.6.26 et un beau message "Waiting for a root filesystem"
Le pb venait du fait le disque principal pour une raison que j'ignore est passé de sda à sdb ( une inversion entre 2 disques pour etre précis ). Pour le découvrir, on laisse le nouveau noyau démarrer, ca bloque sur "Waiting for a root filesystem", au bout de 5-10 minutes, on a accès à une ligne de commande réduite. un "dmsesg | grep sd*" qui va bien, permet de retrouver ces petits. Redémarrage, passage du bon paramètre à grub root=... démarrage sur 3 pattes, modification de menu.lst, mise à jour de grub, maj de fstab. On redemarre et ca marche.
Je crois en effet que la bonne solution aurait été les uid. ( mais j'aime pas ces nombres à rallonge ;-) )
En espérant que ca puisse aider le prochain.
-- DR
Hugolino a écrit :
Le Thu, 23 Oct 2008 16:19:48 +0200, Pascal Hambourg a écrit:
Hugolino a écrit :
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien
en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été
installé --> reboot incapable de monter la racine. Je soupçonne
fortement que c'est à cause de fstab qui référence les partitions par
/dev/hdXY alors que etchnhalf doit attendre des champs UUID.
J'ai du noyau etchnhalf qui tourne sur deux machines, et pas vu d'UUID.
Ça n'était qu'un soupçon... Je n'ai pas cherché à résoudre le problème.
Salut,
Je viens de tenter un upgrade de Etch vers Lenny.
J'ai le sentiment que le pb que j'ai rencontré est le meme.
Carte mère MSI K9N SLI Platinum ( si ca a une importance ? )
Debian Etch AMD64 d'origine debian.
Changement des sources, passage en Lenny -> reboot sur le noyau 2.6.26
et un beau message "Waiting for a root filesystem"
Le pb venait du fait le disque principal pour une raison que j'ignore
est passé de sda à sdb ( une inversion entre 2 disques pour etre précis ).
Pour le découvrir, on laisse le nouveau noyau démarrer, ca bloque sur
"Waiting for a root filesystem", au bout de 5-10 minutes, on a accès à
une ligne de commande réduite.
un "dmsesg | grep sd*" qui va bien, permet de retrouver ces petits.
Redémarrage, passage du bon paramètre à grub root=...
démarrage sur 3 pattes, modification de menu.lst, mise à jour de grub,
maj de fstab.
On redemarre et ca marche.
Je crois en effet que la bonne solution aurait été les uid.
( mais j'aime pas ces nombres à rallonge ;-) )
Le Thu, 23 Oct 2008 16:19:48 +0200, Pascal Hambourg a écrit:
Hugolino a écrit :
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été installé --> reboot incapable de monter la racine. Je soupçonne fortement que c'est à cause de fstab qui référence les partitions par /dev/hdXY alors que etchnhalf doit attendre des champs UUID.
J'ai du noyau etchnhalf qui tourne sur deux machines, et pas vu d'UUID.
Ça n'était qu'un soupçon... Je n'ai pas cherché à résoudre le problème.
Salut,
Je viens de tenter un upgrade de Etch vers Lenny. J'ai le sentiment que le pb que j'ai rencontré est le meme.
Carte mère MSI K9N SLI Platinum ( si ca a une importance ? ) Debian Etch AMD64 d'origine debian.
Changement des sources, passage en Lenny -> reboot sur le noyau 2.6.26 et un beau message "Waiting for a root filesystem"
Le pb venait du fait le disque principal pour une raison que j'ignore est passé de sda à sdb ( une inversion entre 2 disques pour etre précis ). Pour le découvrir, on laisse le nouveau noyau démarrer, ca bloque sur "Waiting for a root filesystem", au bout de 5-10 minutes, on a accès à une ligne de commande réduite. un "dmsesg | grep sd*" qui va bien, permet de retrouver ces petits. Redémarrage, passage du bon paramètre à grub root=... démarrage sur 3 pattes, modification de menu.lst, mise à jour de grub, maj de fstab. On redemarre et ca marche.
Je crois en effet que la bonne solution aurait été les uid. ( mais j'aime pas ces nombres à rallonge ;-) )
En espérant que ca puisse aider le prochain.
-- DR
Jonathan ROTH
Droopy191 a écrit : [...]
Je crois en effet que la bonne solution aurait été les uid. ( mais j'aime pas ces nombres à rallonge ;-) )
Utilise des labels ?
En espérant que ca puisse aider le prochain.
Merci d'avoir diagnostiqué le problême ;)
Droopy191 a écrit :
[...]
Je crois en effet que la bonne solution aurait été les uid.
( mais j'aime pas ces nombres à rallonge ;-) )
