kane13 a écrit :L'installation s'est faite avec le manuel,
Donc tu as installé un manuel ?
Ma question porte sur le mode d'installation. Donc tu as installé à partir d'un CD si je comprends bien.
et niveau intégrité des données j'avoue ne pas savoir comment faire.
tu lances la commande md5sum fichier.iso dans un terminal, en te situant dans le répertoire du fichier à vérifier (où tu remplaces fichier.iso par le nom de l'image iso que tu vas graver) puis tu compares avec le chiffre donné pour cette image là.
Par exemple en bas de cette page il y a un fichier texte avec les md5sum des différents fichiers à télécharger sur cette page.
Pour moi, ton probleme est que le kernel n'arrive pas a detecte ton systeme de fichier, donc il doit manquer le hook "filesystems", et c'est mal.
Dans ce cas, deux solutions : soit tu remets le hook (en bootant sur un live CD), soit tu ajoutes le bon module (reiserfs, ext3, xfs, jfs, quoi_tu_veux) dans la ligne MODULES.
Dans les deux cas, il faut faire un rebuild (mkinitcpio -p kernel26).
J'en suis arrive a la conclusion que le mkinitcpio.conf avait ete modifie, car tu as egalement modifie ton /boot/grub/menu.lst : logiquement apres l'install, grub se sert de l'uuid des partitions pour booter (dans l'entree fallbakc, mais aussi dans l'entree "normale").
Ma question : as-tu resussi a booter une premiere fois (et fait des modifs) ou est-ce comme ca depuis le debut ?
# BINARIES
# This setting includes, into the CPIO image, and additional
# binaries a given user may wish. This is run first, so may
# be used to override the actual binaries used in a given hook.
# (Existing files are NOT overwritten is already added)
# BINARIES are dependancy parsed, so you may safely ignore libraries
BINARIES=""
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in anyway. This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options,
# like so:
# FILES="/etc/modprobe.conf"
FILES=""
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'modload' may be used in place of 'udev', but is not recommended
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
# This setup specifies all modules in the MODULES setting above.
# No raid, lvm2, or encrypted root is needed.
# HOOKS="base"
#
# This setup will autodetect all modules for your system and should
# work as a sane default
# HOOKS="base udev autodetect pata scsi sata filesystems"
#
# This is identical to the above, except the old ide subsystem is
# used for IDE devices instead of the new pata subsystem.
# HOOKS="base udev autodetect ide scsi sata filesystems"
#
# This setup will generate a 'full' image which supports most systems.
# No autodetection is done.
# HOOKS="base udev pata scsi sata usb filesystems"
#
# This setup assembles an pata raid array with an encrypted root FS.
# Note: See 'mkinitcpio -H raid' for more information on raid devices.
# HOOKS="base udev pata raid encrypt filesystems"
#
# This setup loads an lvm2 volume group on a usb device.
# HOOKS="base udev usb lvm2 filesystems"
HOOKS="base udev autodetect pata scsi sata usbinput keymap filesystems"
d'après ta dernière image, le disque est reconnu en tant que sda et non hda, par contre, il n'arrive pas à le lire (meme pas à reconnaitre la table de partition), mais si j'ai bien suivi, tu as bien une autre distribution dessus, non? tu arrives à booter dessus?
kane13 a écrit :Non, sur ce DD je n'ai que cette distrib
Je boot sur un autre DD pour l'autre distrib.
à mon avis, si tu n'as pas de données importantes, tu auras plus vite fait de réinstaller en prenant bien soin de lancer un "fsck -c" pour marquer d'éventuels secteurs déféctueux.
par contre, si tu veux vraiment essayer de récupérer les données, il faudra jouer avec testdisk et équivalent.
une dernière question... c'est un disque interne ou en usb (sans alim)?
je dis ca, parce qu'avec des disque en usb, il arrive parfois qu'il soient mal reconnus (ou en tout cas pas tout le temps) à cause d'une alimentation non suffisante.
C'est un disque IDE interne... donc vous pensez que ça vient d'un DD défectueux ? Ça me ferait un peu chier mais bon, au moins je saurais que ça vient pas de moi ... je peux tester le DD à partir d'ubuntu?
Si oui, comment?
Je formate de ce soir, mais si c'est pour tomber sur une autre erreur après l'installation ça n'aura servi à rien
kane13 a écrit :J'ai formaté le DD avec Gparted, est-ce normal qu'après l'avoir formater en ext3 il y ait 795 mio d'utilisés?
non, mais tu peux peut etre voir ce qu'il y a dedans...
kane13 a écrit :PS: c'est reconnu comme étant du hdx
le nom du disque dépend fortement de la config du kernel utilisé, au risque de me tromper, je pense que c'est l'option CONFIG_SCSI_SAS_ATA qui sur certaines distrib n'est pas activée.
kane13 a écrit :Dans le DD il y a le dossier "lost+found" et il est vide.
Ce qui veut dire que la partition est formattée en Ext3, mais que rien n'y est installé. Pas étonnant si ça ne démarre pas.
Tu peux vérifier le contenu depuis un live CD n'importe lequel. (passer root, invoquer cfdisk pour voir le nommage des partitions, et monter la partition que tu veux visiter avec mount /dev/XXX sur /mnt par exemple).
lost+found est un répertoire vide. Il sert au système de journalisation des fichiers. Je ne sais pas trop comment ça fonctionne mais si il y a un crash, au reboot le système récupère ce qui a pu être perdu et utilise ce répertoire.
