Don't Panic IT

Putin. Ça fait 3 mois que j’ai rien publié. Ça craint. En même temps j’ai rien fait qui aurait pu justifié un GROS article. Et même pour celui là, j’ai un peu honte.

Aujourd’hui j’vais vous donner une petite astuce pour les alternates CD des distributions Ubuntu.

Pour rappel, les alternates CD, ce sont des CD d’installation Linux sans la possibilité de faire du LiveCD (et sans avoir a passer par elle pour installer le système). Elles trouvent leur utilité sur les vieilles bécanes. D’ailleurs, c’est assez mal foutu, puisqu’une distribution légère comme Xubuntu et Lubuntu, faites pour être installées sur de vieilles machines, n’arrivent pas (ou difficilement au prix d’heures de chargement) à tourner en LiveCD. Forcement, c’est des système qui, Ok, a partir du disque, peuvent se contenter de 512 MoRAM, mais en LiveCD, MEGAPURGE.

Bref, donc il existe des versions moches de liveCD, ou l’on se retrouve vers des écrans d’installation style 1985. C’est très OldScool, et les habitués de DéBian seront content de l’avoir.

Le problème que j’ai rencontré, via le créateur de CD de démarrage d’Ubuntu, c’est qu’une fois la clé USB remplie de la version Alternate de Xubuntu, pendant l’installation, il me demandait (ce gros baltringue) de mettre le CD de Xubuntu. C’est idiot. Mais chez Canonical, on en est plus a une connerie près (dédicace pour @Jee4404 ).

Le Wiki d’Ubuntu met a sa disposition une solution : http://doc.ubuntu-fr.org/installation_alternate en ajoutant cdrom-detect/try-usb=true à votre isolinux.cfg. Personnellement, pour moi ça n’a pas marché, et en plus visiblement la 12.04 de Xubuntu est déjà configurée comme ça par défaut.

Heureusement, ce dernier, après avoir lâchement abandonné l’installation, vous propose plusieurs choses, comme continuer l’installation (mais il va gueuler parce qu’il aura pas les fichiers) ou alors vous donner un accès au shell (dernier dans la liste des propositions).

Donc, il faut prendre l’accès au shell, et se retrouver avec le bon vieux shell old Unix.

~ #

On va donc TRUANDER. Ouai. Vraiment. On va lui raconter des cracks a Linux.

Déjà, il faut que vous connaissiez le périphérique de votre clé USB. Vous savez, dans /dev/, il y a plein de sda, sdb, sdc etc…, et bien il faut trouver celui de votre clé. Si vous n’avez qu’un disque dur et votre clé, ça devrait normalement être /dev/sdb, mais vérifiez si possible, c’est plus sur.

Suivez les commandes ci dessous, en remplaçant sdX par votre clé USB (par exemple sda, sdb ou autre), et je vous les explique après:

~ # cd /dev

~ # rm cdrom

~ # ln -s /dev/sdX /dev/cdrom

“Ok mec c’est quoi cette bouffonnerie?” vous dites vous. Et bien je me suis posé le problème a l’envers. “Si Linux veut un périphérique sur lequel pomper ses fichier, et bien on a qu’a lui donner”. De façon automatique, il cherchait visiblement a faire un mount /dev/cdrom /cdrom , je me suis donc dit qu’un point de montage est un point de montage, et qu’il fallait donc lui faire croire que la clé USB était un CD.

On supprime donc le périphérique du cdrom (qui est physiquement lui aussi un lien symbolique), et on le remplace par un autre lien symbolique, du même nom, qui pointe vers la clé USB.

Et là TADAAAA.

On reprend l’installation là ou il s’était arrêté (monter le CD), et on envoie. Et là miracle, il lance l’analyse du CD puis l’installation. Bon, c’est long par contre hein, on est sur du 512 MoRam et un intel Celeron Mobile. Faut pas le brusquer.

/me lance l’ordi par la fenêtre.

Voila voila. C’était cool non?

“Ouaaai, génial! 4ans pour installé Linux sur cette merde! Ça c’est cool!”

Bonjour à tous!

Petit billet plein de légèreté et de beauté aujourd’hui. Vous, brillants administrateurs systèmes qui tombez par hasard sur ce blog en quête de réponses improbables, n’avez jamais rêvé d’un peu de couleur et de folie pour vos environnement de développement?

Donc aujourd’hui je vais vous parler d’un petit logiciel sympatoch nommé gource.

Gource est un logiciel de visualisation de projet git/svn qui permet de voir les dossiers, les branches, les commits et les membres à partir des logs sur le projet en question. Niveau professionnel, l’intérêt est plus que limité, mais d’un point de vue visuel, qu’est ce que ça en jette ;D.

Voici par exemple ce que des petits malins ont générés à partir des dépôts git de php. On y voit les contributions et les évolutions au fur et à mesure, comme la naissance de php 4 puis 5.

Pour vous amuser à visualiser vos projets, voici donc la marche à suivre :

Etape 1 : Installer les dépendances et les librairies.

Ce logiciel fonctionne avec les librairies SDL compilées en C++ (j’ai d’ailleurs été bien surpris de voir à quel point ces librairies commençaient à devenir intéressantes, ne se contentant plus de faire du 2D SNES, je devrais plus me tenir au courant).

Pour ce faire donc, sur une machine debian (Ubuntu 11.10 dans mon cas) envoyer la commande suivante :

sudo apt-get install build-essential libsdl1.2-dev libsdl-image1.2-dev libftgl-dev libpcre3-dev libpng12-dev libjpeg62-dev

Etape 2 : Installer “Gource”.

Les versions de “gource” sont disponibles à la page suivante : http://code.google.com/p/gource/downloads/list

Etant codé en C++, ces derniers nous gratifient joyeusement d’une versions Win32 ce qui satisfera nos chers utilisateurs de Microsoft :).

Une fois les sources décompressées, il s’agis maintenant de les compiler afin d’obtenir un exécutable. Les commandes classiques suffisent :

cd /Repertoire_de_Gource
./configure
make
sudo make install

Si vous n’avez pas fait de connerie, normalement, si vous envoyez dans votre terminal :

gource -h

Vous devriez voir apparaître la liste d’aide (assez complète) pour gource et donc que votre installation sera un succès.

Etape 3 : Utiliser “Gource”.

Maintenant que gource est installé, il ne vous reste plus qu’a vous rendre dans votre dossier ou siège votre clone local de git (le dossier qui contient le .git in fact).

cd Dossier_du_Projet

Et à lancer la commande suivante, qui est la commande standard pour avoir un rendu vif et dynamique :

gource —seconds-per-day 80 —auto-skip-seconds 0.1 —file-idle-time 500 —max-files 500 —multi-sampling -1280x720 —stop-at-end —elasticity 0.1 -b 000000  —hide filenames,dirnames  —disable-progress —user-friction .2 —disable-bloom

Les arguments de commande sont suffisament clair pour faire ce que vous voulez. Par défaut la visualisation est en fenetré, mais vous pouvez le faire facilement passer en plein écran (et épater vos colègues) avec l’argument supplémentaire

“-f” ou “—fullscreen”.

Voila, grâce à Gource, vous allez pouvoir faire tomber les filles en soirée en montrant “Voila ce que c’est qu’être développeur!”.

C’est comme jouer de la guitare mais en mieux.

Etape bonus : compresser votre résultat en vidéo.

Si vous voulez faire baver le monde devant vos réalisations et pouvoir les héberger sur YoupornTube, il faut donc envoyer tout ça en enregistrement vidéo.

Pour ça je vous conseil de consulter la page ici présente : http://code.google.com/p/gource/wiki/Videos

Elle contient toutes les indications pour encoder proprement vos vidéos en mp4.

Je ne fais pas de tuto détaillé là dessus pour la simple et bonne raison que je me suis complètement vautré dans l’installation de codecs ffmpeg et qu j’ai flingué une partie des lectures vidéos sur mon linux, ce sont des choses qui arrivent u_u’…

Donc je vous souhaite bon courage et une bonne journée à tous!

Bonjour à tous.

Petit article aujourd’hui pour parler d’un souci, j’espère que ça servira d’avertissement pour certains qui tomberaient dans le même piège que moi.

Le ton est volontairement humoristique, car quand on a ce genre de couille, il vaut mieux en rire, ou du moins, essayer.

C’est assez relié avec les tutos sur les partages nfs déjà disponibles sur ce blog, donc pour ceux qui dormiraient au fond de la classe, prenez note.

Alors, comme vous avez pu le lire, j’ai récemment mis en place un système de partage assez simple mais néanmoins complexe (WTF?) au niveau de mon serveur de fichier et de mes systèmes là ou je travail en tant qu’administrateur système.

Alors comme ce matin j’ai vécu un véritable apocalypse et empêché une équipe de travaillé pendant 30 minutes, je préfère avertir les têtes brûlées qui voudrait un jour tenter de faire les mêmes conneries que moi. 

Ne faites pas comme moi, gardez toujours à l’esprit que quelque chose en développement, même si il parait très cool tout ça, N’EST PAS STABLE!

Quand j’ai formaté mon serveur à l’installation de Debian, j’ai pris la décision d’utiliser le BTRFS comme système de fichier. Pour ceux qui dormais ces 5 dernières années, le BTRFS est annoncé comme le successeur des systèmes journalisés comme la série des ext. Il est en développement depuis 2007 et considéré comme stable depuis mars 2009.
Oui mais… 

On peut se demande, pourquoi ce système si miraculeux, n’équipe donc pas toutes nos distributions linux actuelles? Lui qui annonces vers performance de +500% en compressé comparé à son camarade ext4, reste irrémédiablement dans l’ombre.

Le fait est que malgré tout le travail et les avancées faites sur son sujet, il n’en reste pas moins un système de fichier en développement, non complet et inapplicable à certaine situation.

Mon exemple est le suivant. Voici mon ancienne infrastructure, que vous connaissez bien, vous les deux ou trois qui suivez mon blog :

Comme vous le voyez, j’ai fais le choix du BTRFS et j’exporte en NFSv4 au cotés de la partition du Système linux, transportant la racine du système, sur une partition en XFS.

La première fois que j’ai tenté ce montage, j’ai été confronté à un problème assez étrange. En effet, la partition du NAS, en BTRFS, une fois monté en en NFS, provoquait un très très très gros ralentissement.
En temps normal, un hdparm -t sur la partition NAS donnait une vitesse de lecture variant entre 1 et 5 Mo/s, contrairement aux 110 Mo/s dont j’ai habitude.
Suspectant un problème inhérent au fait de dédoubler un lien nfs partant d’une même source et allant vers une même destination, je me suis donc décidé à essayer de ne tourner qu’avec une seule exportation, limitant dans le même coup les erreurs de démontages sur les postes clients, et j’ai donc donné vie au tutoriel d’hier (ou d’avant hier, je sais plus).

Bref, donc cette configuration fut modifiée et j’ai pu aboutir au bout de quelques recherches à l’ensemble suivant :

Hier soir je clos définitivement l’affaire, prépare à distance mes systèmes, et, prévoyant, met mon réveil plus tôt pour être premier au boulot, on sait jamais.

Ce matin, les 4 premiers postes démarrent sans encombre et je vais me fumer une cigarette, certes matinale mais néanmoins méritée pour célébrer ma victoire sur cette hérésie qu’est l’infrastructure de développement local standard des sociétés de développement web d’aujourd’hui.

En revenant de cette délicieuse cigarette, le 5e poste est allumé et… 

D’un coup, tout les systèmes commencent à ralentir.

Suspectant un ralentissement du réseau, je cherche d’abord dans ce sens, avant de me rendre compte que mes hdparm ne passent plus. Chaque consoles ouvertes avec lesquelles je lance un hdparm me lâchent, et me guide désespérément vers la triste réalité que me réserve le /var/log/syslog.

Pour la faire courte, toute la couche BTRFS avait sauté d’un coup à la suite de l’appel nfsv4 du 5e poste. Je me retrouve avec une énorme erreur kernel, révélée en fait par le hdparm.

Je me retrouve donc à devoir repasser sur notre vieux serveur de fichier, celui qui crash dès qu’une porte claque trop fort.

Ouaip, donc un conseil :

LE BTRFS EN NFSv4 POUR LE PARTAGE MASSIF, ON ÉVITE!

Et moi je reformate ma partition de serveur en ext4. Ça m’apprendra a faire des expériences.

Bonjour à tous!

Aaaahh, enfin un petit billet, ça faisait longtemps. En fait j’avais pas mal de boulot assez répétitif, et surtout pas intéressant en ce qui concerne le blog. Mais là, tout se clos petit à petit, donc du coups, il est temps de faire quelques tutos rapide de solutions simples et efficaces pour les problèmes que j’ai rencontré, car oui, la plupart du temps, les solutions qu’on met plusieurs semaines à trouver sont toutes connes, mais fallait trouver la bonne façon de les aborder.

Aujourd’hui on va donc parler d’un souci qui peut vous avoir été soumis, surtout si vous avez déjà suivit mes tutos sur le NFSRoot.

Voila, imaginez une situation lambda, vous avez un système bombardé en nfsroot, et vous possédez un autre serveur qui se monte dans ce système linux (en gros une architecture classique de développement avec un système et un serveur de fichier qui lui est raccordé.

Vous vous retrouvez donc avec, dans le système linux nfs, un bout de votre fstab qui ressemble plus ou moins à ça : 

nas:/nas /nas nfs4 1 0

C’est une configuration assez intéressante, simple a mettre en place, et loin d’être contestable. Au niveau de la fiabilité, elle est aussi contestable qu’une ou les systèmes serait interne aux machines, dans la mesure ou, en cas de panne du système, le serveur de fichier servirai à rien, et en cas inverse, un système sans serveur de fichier ne permettrait pas de bosser (ou peut être zoner sur Internet, et encore)

Bref, dans une logique de limitation des ressources, et pour en finir avec un serveur de fichier assez vieux et pantouflard, l’idée est venue de tout réunir au sein d’un même serveur. Le système et les données.

 

Pour ce faire, et éviter d’exporter depuis ce serveur les fichiers ET le système avec deux lignes dans le fichier d’exportation, on va faire une petite manip pour faire du deux en un.

Reprenons notre fichier d’exportation du système Ubuntu en nfsroot (voir tuto : http://dontpanicit.tumblr.com/post/11432209474/installation-dun-systeme-nfsroot-et-le-lancer-via ).

Imaginons qu’en temps normal, notre dossier de serveur de fichier soit à la racine  (monté comme cité plus haut) sous forme de :

/nas

Sa position dans le NFSR(NFSRoot), vue du serveur, serait donc ici :

/srv/ubuntu/nas

L’idée c’est donc de monter la partition qui contiens /nas (ou de monter le dossier en bind) directement dans ce dossier, et de lancer notre système, et penser à retirer de notre fstab de notre système ubuntu NFSR la ligne de montage NFS du nas.
Donc fstab du serveur :
/dev/sda42 /srv/current/nas filesystemtype defaults 1 1

Et plus de trace d’un montage du nas:/dns-nas dans le /srv/current/etc/fstab!

Si vous le faites, et que vous lancez votre système, il va démarrer, et un ls -al dans votre dossier /nas va vous montrer que … ça ne marche pas 8D.

PAS DE PANIQUE!

C’est tout a fait normal. Pour limiter les risques d’intrusion depuis le système jusqu’au serveur, GNU/Linux est justement configuré pour masquer les partitions montées ou disponibles du serveur depuis les clients. C’est une mesure de sécurité tout à fait logique de la part des concepteurs du système d’exports.

Il faut donc trouver les arguments qui vont bien pour justement by-passer cette sécurité en disant à l’exportation de se montrer nu comme un ver lors de son exploitation sur les machines clients.

C’est un lot de 3 options dans le man exportfs de Linux qu’il était important de repérer :

nohide - Première pierre angulaire de notre exportation, elle force les exportations à tout montrer. Nécessaire mais pas suffisante, elle a besoin du complément suivant.

crossmnt - Deuxième pierre, elle sert à montrer précisément les périphériques montés à la source, c’est à dire par le serveur.

Et enfin par mesure de précaution pour éviter les conflits de racine, on va poser un petit
fsid=0
Qui va quand même garantir la racine du système correctement, et rétablir un semblant de sécurité.

Donc au final notre ligne d’exportation va ressembler à ça : 
/srv/current/   192.168.0.0/24(rw,no_root_squash,async,subtree_check,nohide,crossmnt,fsid=0)

NB : Notez la nouvelle façon de noter l’IP, c’est elle la correcte :p. 

C’était vraiment bête comme idée, mais il fallait y penser.

C’est super pratique parce qu’on perd en complexité et on gagne en vitesse de traitement. Maintenant tout est empaqueté à la source, magique!


Voila c’est tout pour le tuto. Si vous avez des questions, n’hésitez pas. 
Spéciale bigup à @joellecorre qui ,lors de son bref passage parmi nous, m’a montré yEd, le logiciel que j’ai utilisé pour vous faire les jolis dessins ci dessus. Pensez à aller voir son blog, il est pas mal : Sublimigeek

 Bonne journée les gens :D.

Bonjour à tous!

Petit tuto aujourd’hui, plus précisément un complément de plus à l’utilisation d’un système nfsrooté.

Pour ceux qui auraient suivi le tuto sur l’installation du Linux en NFSroot, vous aurez peut être remarqué l’incapacité du système à démarrer des logiciels tels que Thunderbird, Skype etc…. Et bien c’est que ces système ont besoin d’une couche de cache que le NFSroot ne peux pas leur donner en natif (pour ceux qui auraient d’ailleurs lancé des débugs consoles sur ces applications, ont pu constater que leurs logs les gratifiaient d’un magique “SegFault”).

Ici on va voir comment y remédier.

Tout d’abord, il faut installer notre couche de cache, et pour cela, on va faire appel au paquet “nscd” (ou “Name Service Cache Daemon”).

Comme d’hab quand on installe une application, ont passe par apt-get :

~# sudo apt-get install nscd

Une fois l’installation terminé, on reboot tranquille, on se dit “Tout vas bien, pas d’erreur”, on clic que notre application Thunderbird et là… rien. Rien ne se lance.

PAS DE PANIQUE

Avant de me jeter des cailloux pointus à la gueule, dites vous bien que je me suis cassé le cul à plusieurs reprises (et je remercie encore “Ô mon Maitre” Yann pour me secourir dans des moments difficiles) en cherchant la source de l’erreur.
Après avoir longuement suspecter le script de démarrage de faire de la merde, j’ai ensuite compris finalement (via des echo tassés dans des fichiers) que le script n’était même pas appelé au démarrage du système.

En fait, depuis la 11.04 (voir même la 10.10 - 10.04 je crois), on ne passe plus par les runlevel de Système V pour démarrer des démons sous Linux, mais on utilise un nouveau système nommé UpStart. Ce dernier en fait prend la mains sur pas mal d’élément du démarrage, ce qui peux laisser perplexe quand on ne le sait pas.

Seulement, NSCD n’est pas fait pour démarrer par upstart, ce qui fait que ce dernier lui roule dessus au démarrage sans que NSCD puisse moufter sa sauce. Par conséquent il faut créer des scripts custom dans le répertoire de gestion d’upstart (comme on aurai pu faire avant dans les runlevels) afin de lui dire “Hey connard! T’es gentils, tu laisses les autres jouer!”.

voici donc le script a placer dans /etc/init/nscd.conf (Oui, le fichier n’existe pas, il faut le créer).

description	"name service cache daemon"

start on local-filesystems
stop on runlevel [06]

#expect fork
pre-start script
    mkdir -p /var/run/nscd
end script

exec /usr/sbin/nscd -f /etc/nscd.conf

Merci d’ailleurs à spidernik84 du forum Linuxquestions.org pour avoir trouvé ce script plus ou moins miraculeux.

Une fois ce script posé et enregistré, vous pouvez redémarrer votre linux et là, tadaaaa, Thunderbird se lance! Magique!

Reste cependant un dernier problème à résoudre : Cette solution est plus ou moins bonne car elle est faite main. Le délire c’est qu’il est possible qu’une mise a jour fasse sauter tout ça (upstart, nscd, ubuntu lui même). Si le problème ce représente, vous saurez cependant quoi faire!

NB : J’ai utilisé cette solution avec le paquet “unscd” mais techniquement tout devrait fonctionner correctement quand même avec la version nscd originale. Notez que pour “unscd” d’ailleurs, le fichier de conf est le même (et s’appelle aussi “nscd.conf”), puisque les binaires et les fichiers .conf de unscd se nomment nscd tout court. Donc le script est interchangeable.

Bonjour à tous et bienvenu pour le tuto de la semaine!

Il faut le prendre en complément du tutoriel sur l’installation en NFSroot, par conséquent, je ne reviendrai pas sur la partie installation et configuration du serveur (sauf à un moment précis mais la modification est à la fois mineure et essentiel donc restez attentif).

Ok, nous y voila.

Donc la méthode est la suivante :
On va commencer par créer une image .iso qui va en fait servir d’alternative au boot grub, car ce dernier est non seulement invivable à installer seul sur une VM, mais de plus pause d’important problèmes au lancement du NFS (avalanche d’erreurs, montage partiel, erreur “need a path” et j’en passe).

J’espère que vous n’avez pas oublié la partie de changement du /etc/initramfs-tools/initramfs.conf dans le premier tuto, car c’est impératif. Si ce n’est pas le cas, retournez sur l’ancien et recréez la initrd.img correctement.

Etape 1 : Création de l’image boot.iso

En fait basiquement, on va réutiliser les fichiers vmlinuz et inird.img préconfigurés du NFS pour créer une image correctement configuré. Pour ce faire, il faut donc créer un dossier à la racine (pour plus de rapidité et ne pas péter un câble avec les chemins d’accès) qui sera donc /iso.

A l’intérieur il faut créer un dossier “linux” pour se retrouver donc avec l’architecture suivante :

/iso
   |
   linux

Ensuite, on va placer nos deux images vmlinuz et initrd.img dans le dossier linux. Ce sont les images que l’on avait utilisé dans le tuto précédent pour grub (ils étaient à l’époque stocké dans /boot/LAN du disque sur le poste client)
On va juste changer le nom de l’initrd :

mv initrd.img initrd

On va maintenant créer le fichier qui va servir de configuration à l’image iso :

cd /iso
touch isolinux.cfg
vi isolinux.cfg

Collez y ça (arrangé à votre sauce) :

default linux
 
label linux
  kernel /linux/vmlinuz
  append initrd=/linux/initrd root=/dev/nfs ip=dhcp(ou les paramètres IP de votre réseau local) nfsroot=(adresse_de_votre_serveur):(chemin_d’accès_vers_votre_racine_nfsroot),rw,nolock

Ça vous rappelle des choses? C’est normal! On dirait le lanceur de Grub2 dans l’autre tuto. C’est pas pour rien hein? Sauf que lui en fait il va lancer les éléments pour que le .iso soit correcte.

Donc une fois ça fait, on va aller fouiner dans notre ubuntu embarqué sur le serveur pour aller y télécharger isolinux.bin.

scp (nom_d’utilisateur_ssh)@(adresse_du_serveur):/(chemin_d’accès_vers_votre_racine_nfsroot)/usr/lib/syslinux/isolinux.bin /iso/

voila, on y est presque, maintenant on va créer l’image boot.iso (notez, il faut être dans /iso (faites un cd /iso pour être sur):

mkisofs -R -V “NFS Boot” -o ../boot.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table .

Voila, maintenant que votre boot.iso fait pour le nfs est créé, on va configurer VirtualBox pour démarrer la machine.

Etape 2 : Configuration de VirtualBox

NB : Désolé pour les fans de VirtualBox OSE, mais il n’y a que la VirtualBox 4.1.4 qui permet la connexion par pont, et donc de permettre à la machine de démarrer avec les bonnes informations réseau. D’ailleurs, sous linux, il est possible que VirtualBox provoques de petites erreurs au démarrage, et demande l’emploi de certaines commandes setup. Faites les, c’est simplement certains modules de VirtualBox qui doivent être réinitialisés à chaque démarrage. C’est un bug connu.

Donc, lancez VirtualBox et créez une nouvelle machine, basé sous Linux Ubuntu. Donnez lui un peu de mémoire (minimum 512Mo, et encore, vous allez galérer. L’optimal c’est 1Go dédié de toute façon, et c’est d’autant plus valable pour une VM). Ensuite dans l’onglet réseau, sélectionnez “Accès par pont” et l’interface de votre carte réseau correcte (par défaut : eth0).

Ensuite allez dans “Stockage” et montez votre image boot.iso dans le lecteur CD.
Tien, maintenant essayez de booter. On pourrait se dire “Boarf, le serveur est configuré pour partager avec toutes les IP de mon domaine réseau (souvenez vous du 192.168.1.* qui couvre tout le domaine), il devrait se monter correctement”.
Miracle, votre noyau se monte correctement, les procédures se lancent, et là BAM!
Oh? Etrange! nfs-premount : acces denied error.
Patatra, je vois d’ici vos rêves et vos espoirs disparaître dans vos yeux, et la vie devenir plus sombre à chaque loop de “acces denied”.

PAS DE PANIQUE

Il y a des gens comme moi pour se prendre la tête avec ce genre de souci, et vous apporter la solution sur un plateau!
En fait, je n’ai pas tout a fait compris pourquoi, mais même dans le cas ou l’IP donné par le DHCP, accompagné de son masque et de sa passerelle, ne possède quand même pas les accès vers le serveur nfs.

Pour corriger ce problème, il faut vous rendre sur votre serveur, dans le fichier /etc/exports.
A l’époque, on avait marqué ça :

/srv/ubuntu IpdesClients(pour moi c’est 192.168.1.* pour couvrir toute la plage IP)(rw,no_root_squash,async,subtree_check)

Et bien il faut rajouter la ligne suivante :

/srv/ubuntu IPdelaVM/IDdumasque(24 pour 255.255.255.0, sinon faite la conversion)(rw,no_root_squash,async,subtree_check)

relancez votre serveur nfs

sudo service nfs-kernel-server reload

Et maintenant, sur votre PC client, relancez votre machine.

Tadaaaaaaaa! Ca marche. Cependant, pour les 11.04 et ulterieures, Unity nécessitant une accélération matérielle, il chargera l’ancienne interface gnome par défaut. Je n’ai pas réussis à stabiliser ça, mais bon, ça ne rentrait pas dans le cadre de ma demande.

D’ailleurs, l’installation de ce genre de chose tien plus du bricolage qu’autre chose, ce ne sont pas des machines très fiables, par conséquent, je conseil tout de même le Dual Boot de l’ancien tuto (a moins que ce soit pour une utilisation ponctuelle).

Voila, j’espère que ce tuto aura servi.
A plus les gens :).