Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

[moimadmax]

Ton disque est mourrant ?

En théorie non.

[Tramb]

Tu copies / avec -a et tu obtiens un Linux valide ?
Ça me paraît complètement indéfini pour /dev en fait, je n'envisagerais pas de garder plus que /home et éventuellement /etc à merger. Mais peut-être que je suis trop conservatif.

[Møgluglu]

Je vais peut-être dire un connerie, mais /dev c'est pas un FS spécial (devfs) qui est rempli par le kernel (et udev et compagnie) au boot et qui sert juste à communiquer avec lui, comme /sys?

Pour le reste la migration ne devrait pas poser trop de problème une fois que le loader a retrouvé ses petits, c'est pas pire que de mettre le disque dur dans une autre machine.

[Tramb]

Bah justement, si tu le copies (en itérant récursivement en partant de /) sur la destination, est-ce que ça se passe bien ?
Tu dois arriver à lire certains /dev/xxxx en tant que fichiers et en créer dans le /dev destination lors de la copie.

[Wobak]

Je dirais que peu importe parce que même si t'as des "fichiers" dans un répertoire, à partir du moment où il est mounté pour y mettre autre chose, les fichiers d'origine ne sont plus utilisés.

[Tramb]

C'est l'ordre de mounting qui décide qui override qui ?

[Nattefrost]

Salut les canards.
J'ai fait une bêtise : une mise a jour windows, j'en avais marre de me faire harceler par le prompt intrusif outil de l'oppression capitaliste de microsoft. Donc j'ai fait la MAJ 8.1.
Depuis je n'ai plus accès à GRUB au boot - pourtant j'ai bien désactivé le secureboot après la MAJ- je ne peux donc plus accéder à mon dualboot linux.

Savez vous si (j'espère que oui) y a un moyen de récupérer GRUB ?

[ducon]

Avec un live-CD ?

[Nattefrost]

Cimer Albert !

Rapide, facile (suffit de suivre les instructions).

[whiterabbit]

Tu copies / avec -a et tu obtiens un Linux valide ?
Ça me paraît complètement indéfini pour /dev en fait, je n'envisagerais pas de garder plus que /home et éventuellement /etc à merger. Mais peut-être que je suis trop conservatif.

So far so good pour moi, je fais la manip depuis un live CD, donc sur un FS inerte, les /dev et /sys ne sont donc pas peuplés (comme le souligne Møgluglu).

Avant de changer le Linux de mon HTPC, j'ai même poussé le vice jusqu'à faire l'install et toute la conf dans une VM, et cloner le tout dans la vraie machine une fois que tout roulait comme je le souhaitais.

[wardog]

C'est l'ordre de mounting qui décide qui override qui ?

Pas de saykse, merci.

[whiterabbit]

Dites, certains d'entre-vous utilisent encore grub-legacy ?

Je suis sous Arch, je ne suis pas passé à grub2 et jusqu'ici je ne m'en porte pas plus mal.
Par contre, le chargement du µcode pour les processeurs Intel change avec la version 3.17-2 du noyau, et il faut maintenant le charger avant le boot de la machine.

Il semble qu'il soit possible d'utiliser deux fois l'option initrd avec grub-legacy, du genre :

initrd  /intel-ucode.img
initrd  /initramfs-linux.img

Quelqu'un peut confirmer ?

[n3os]

Salut,

tu as une news à ce sujet https://archlinux.fr/news/changement...icrocode-intel .
Puis la version du noyau est maintenant dans "base" 3.17.1-1

[Møgluglu]

Et sinon, c'est si grave que ça de ne pas avoir la dernière mise à jour du microcode de la semaine dernière ?
On risque de se retrouver avec la mémoire transactionnelle activée sous Haswell ?

[whiterabbit]

Salut,

tu as une news à ce sujet https://archlinux.fr/news/changement...icrocode-intel .
Puis la version du noyau est maintenant dans "base" 3.17.1-1

Ouaip, c'est suite à cette news que j'ai posé la question, le wiki traite du cas de grub (grub2 donc), pas de grub-legacy (logique puisque plus officiellement pris en charge par Arch).

Et sinon, c'est si grave que ça de ne pas avoir la dernière mise à jour du microcode de la semaine dernière ?

Bien sûr que non, à vrai dire j'ai découvert l'histoire de la maj du µcode avec cette mise à jour. Ma question était plus dans l'optique "est-ce que ça risque de me poser problème si je ne m'en occupe pas".

[Møgluglu]

Bien sûr que non, à vrai dire j'ai découvert l'histoire de la maj du µcode avec cette mise à jour. Ma question était plus dans l'optique "est-ce que ça risque de me poser problème si je ne m'en occupe pas".

À moins que tu ne ne fasses partie des 3 personnes au monde concernées par un des bugs hardware qu'Intel a trouvé depuis la sortie du CPU, non, ça ne risque pas de poser problème. Au pire, ton CPU sera aussi buggé qu'au moment de sa sortie...

[whiterabbit]

Je devrais pouvoir vivre avec alors

En fait, la news sur archlinux.org étant assez succinte, j'ai eu l'impression qu'il fallait que tout utilisateur de CPU Intel fasse la modif, alors qu'en fait, comme le précise la version française de la news pointée par n3os, cela ne concerne que ceux qui avaient déjà installé le paquet intel-ucode.

Reste cette histoire de double initrd pour grub-legacy, même si cela ne me servira pas au final, ça a éveillé ma curiosité.

Merci pour les réponses en tout cas !

[pilipi]

Hello les canards,

J'ai un petit problème sur une distribution Debian, que je n'avais jamais rencontré avant.
Avant tout je précise que c'est une distrib Squeeze spéciale pour NAS, le DLink DNS320.

Donc, j'utilise le logiciel Pyload pour gérer mes téléchargements. C'est installé sur le NAS, ça tourne parfaitement. Mon problème c'est simplement que je n'arrive pas à le mettre en démarrage automatique du NAS.
Je crois avoir tout tenté, le mettre en cron, mettre le script dans /etc/init.d/, rien ne fonctionne.

Donc actuellement, j'ai un fichier "pyload" dans /etc/init.d qui contient ça :

#!/bin/sh

### BEGIN INIT INFO
# Provides:          pyload
# Required-Start:    $syslog $local_fs $network $remote_fs
# Required-Stop:     $syslog $local_fs $network $remote_fs
# Should-Start:      $remote_fs $named
# Should-Stop:       $remote_fs $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Starts pyload daemon
# Description:       This script runs the pyload service
### END INIT INFO

# Starts and stops the pyload daemon.

PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/bin/pyLoadCore
PIDFILE="~/.pyload/pyload.pid"
configdir=/root/.pyload

. /lib/lsb/init-functions

start() {
    log_daemon_msg "Starting pyLoad server"
    whoami
    lsss=$(ls ~)
    echo "folder : $lsss"
    $DAEMON --configdir=$configdir #--daemon

    if [ $? != 0 ]; then
        log_end_msg 1
        exit 1
    else
        log_end_msg 0
    fi
}

stop() {
    log_daemon_msg "Stoping pyLoad server"

    $DAEMON -q

    if [ $? != 0 ]; then
        log_end_msg 1
#        exit 1
    else
        log_end_msg 0
    fi
}

case "$1" in
    start)
       start
   ;;

    stop)
       stop
   ;;

    force-reload)
      stop
      sleep 5
      start
        ;;

    restart)
       stop
       sleep 2
       start
   ;;

    *)
   echo "Usage: $0 {start|stop|restart|force-reload}"
   exit 1
   ;;
esac

exit 0

Je fais un "update-rc.d pyload defaults", et j'ai donc ça :

update-rc.d: using dependency based boot sequencing

Mais j'ai l'impression que ça n'a pas bien fonctionné : la commande

find /etc/rc*.d/ -iname *pyload*

ne me retourne aucun résultat.

Je galère un peu, si la solution saute aux yeux de quelqu'un ...

Merci !

[Olorin]

Il me semble que j'avais eu le même genre de problème à l'époque où j'avais mon DNS-320. Si je me souviens bien je l'avais résolu en ajoutant une ligne (du genre /etc/init.d/pyload start) dans le script de démarrage de fun-plug, qui doit être situé dans /boot/linuxrc si mes souvenir sont bons.

[pilipi]

Hé bien merci, mon problème est résolu grâce à toi !
Ça fait 2 jours que je galère dessus, et je ne comprends toujours pas pourquoi ça ne fonctionne pas.

Bref maintenant ça fonctionne c'est l'essentiel.
Merci !

[Tilt]

Salut !
Je passe bientôt d'une 7950 à une 290.
Vu que je suis sous mint basée sur Debian avec les proprio des dépo. installés, niveau software j'ai rien à faire ?
J’éteins je swap les cartes et je rallume ?
Ou il faut m'attendre au pire ?

[wardog]

Salut !
Je passe bientôt d'une 7950 à une 290.
Vu que je suis sous mint basée sur Debian avec les proprio des dépo. installés, niveau software j'ai rien à faire ?
J’éteins je swap les cartes et je rallume ?
Ou il faut m'attendre au pire ?

Ca devrait aller.
Au pire, tu reboote sur la console de recuperation et tu réinstalle les drivers.

[Tilt]

ok ! je devrais m'en sortir

[Tilt]

ça a marché comme sur des roulettes !
J'ai quand même mis les 14.9 qui sont sur "unstable" et nikel

ESO en ultra c'est cool

[wardog]

Et dire qu'il faut que j'installe windows 7... Je le mets en VM vu qu'il ne va me servir que pour le boulot.

[moimadmax]

Pourquoi la redirection standard ne fonctionne pas avec python
python script.py > log

Comment faire, j'ai tenté de regarder dans python -h mais rien qui indique un fichier de sortie.

Merci

[rOut]

Peut être qu'il écrit sur stderr ?

[moimadmax]

Ahh donc avec ça python script.py > log 2>&1 ça devrait le faire.

Merci.

[rOut]

J'en sais rien, c'est en général le problème quand la redirection > ne fait rien.

[wardog]

J'en sais rien, c'est en général le problème quand la redirection > ne fait rien.

Peut-etre que tuner le .bashrc pour colorer la sortie de stderr pourrait aider a identifier les sorties?

Je dis ca mais ca fait des mois que je me dis qu'il faut que je le fasse sur le mien...