Archives de catégorie : FreeBSD

Montage de clé USB, nouvelle partition et décompression d’archive zip sous FreeBSD

Un nouvel article le lendemain du précédent, et oui je m’amuse bien avec les commandes sur FreeBSD. Et puis surtout je voudrais rapidement arriver à une utilisation pour jouer et filmer mes parties de Minecraft 😉 Du coup, aujourd’hui, je ne vais pas encore parler de tentative de compilation du code-source du driver que j’ai trouvé pour ma carte réseau. Par contre, j’ai préparé le terrain 🙂

Tout d’abord, il a fallu que je trouve le driver approprié, ne serait-ce que pour savoir si il y est déjà dans FreeBSD mais pour une raison inconnue ne serait pas chargé, ou si j’aurais à le chercher sur Internet. Pour connaître ma carte réseau, j’ai utilisé une commande qui ne s’écrit pas pareil sous Linux, mais fait la même chose, c’est à dire donner le nom, etc… des périphériques.

pciconf -lv | grep -i "net"

Ce qui m’a donné le résultat suivant :

device = 'QCA6174 802.11ac Wireless Network Adapter'
class = network
device = 'Killer E2400 Gigabit Ethernet Controller'
class = network
subclass = ethernet

A partir de ce stade, je savais qu’il fallait chercher le driver pour faire fonctionner QCA6174. Et donc j’ai cherché sur Internet, et trouvé le driver ath10k. Ce driver existe pour Linux, mais pas pour la famille des BSDs. Il été indiqué que la version 11 de FreeBSD, prévoyait de l’intégrer, mais pour l’instant ce n’est pas le cas 🙁 Heureusement, quelqu’un s’occupe depuis un long moment à porter le driver pour les BSDs 🙂 Il s’agit de Adrian Chadd et son code-source qu’il continue à améliorer se trouve sur son GitHub : https://github.com/erikarn/athp

Ma clé USB Superman :p
Ma clé USB Superman :p

J’ai donc téléchargé sur l’ordinateur actuel le contenu compressé de son travail, sans savoir ce que ça donnera, mais je verrais bien :p J’ai ensuite mis le contenu dans ma clé USB Superman et inséré dans mon ordinateur contenant FreeBSD. La clé a été détectée automatiquement, mais il fallait que je monte à la main la clé pour accéder à son contenu. Pour ce faire, j’ai du créer un répertoire et monter dessus la clé de cette façon :

mkdir /mnt/$USER
chown $USER:$USER /mnt/$USER
mount -t msdosfs /dev/da0s1 /mnt/$USER

J’ai temporairement appelé le montage de la clé USB par mon nom d’utilisatrice, mais je changerais plus tard pour mettre plusieurs montages USB avec des noms plus appropriés. Une fois que j’ai fais ça, j’ai pu me rendre dans la clé, et je voulais sauvegarder mon archive athp-master.zip sur l’ordinateur. J’ai donc créé un répertoire dans ma session utilisatrice que j’ai nommé tmpfiles/, encore temporairement en attendant de trouver mieux 🙂 Mais, comme je voulais mettre tout ça dans le HDD, et que mon installation de départ ne contenait des partitions que pour l’OS, j’ai donc eu a créer une nouvelle partition pour faire ma future compilation. Cette partition je la voulais exclusive à FreeBSD.

gpart add -t freebsd-ufs -s 50G -i 4 -l mdatafs

Le type est freebsd-ufs, la taille est 50 Go, l’index est 4, parce que c’est la 4ème partition (en GPT) du HDD et le label est mdatafs. Ensuite, j’ai vérifié ce que ça donnait sur mon disque qui s’appelle ada0, à l’aide de la commande :

gpart show ada0

Et j’avais ma nouvelle partition après toutes les autres 🙂 Puis, j’ai ajouté un système de fichier à la main toujours, et créé un répertoire pour monter la partition.

newfs -U /dev/ada0p4
mkdir /bsddata

Et enfin, pour terminer et m’assurer de ne pas devoir monter tout le temps moi-même la partition, je l’ai ajouté à la liste des partitions à monter automatiquement par FreeBSD, en modifiant le fichier /etc/fstab avec vi 🙂

/dev/ada0p4   /bsddata   ufs   rw   2   2

Une fois que tout ça était fait, j’aurais pu monter directement la partition pour faire la suite, mais j’avais envie de voir comment se comporterait FreeBSD après un reboot. Sinon un simple mount /dev/ada0p4 /bsddata suffisait amplement 🙂

Pour terminer cette préparation à la tentative de compilation du driver, j’ai copié l’archive dans /bsddata/tmpfiles/ et procédé à sa décompression dans le répertoire. Mais, j’avais oublié de modifier les permissions en écriture sur /bsddata. Voici ce que j’ai donc fait pour être tranquille :

chmod 1777 /bsddata

J’ai oublié de préciser que certaines de ces actions ont été faite en Root, à l’aide de la commande su – et pour en sortir ensuite, j’ai utilisé la commande exit ou la combinaison de touches ctrl-d. Puis, j’ai pu faire ma copie, aller dans le répertoire et finalement décompresser mon archive dans le répertoire courant.

cp /mnt/$USER/athp-master.zip /bsddata/tmpfiles
cd /bsddata/tmpfiles
tar -xvf athp-master.zip

Les fichiers ont défilés à l’écran, c’est mignon x) J’ai maintenant, un répertoire athp-master dans bsddata/tmpfiles sur mon HDD qui n’attend plus que ma tentative de compilation et d’installation du driver. Je vous raconterais ça la prochaine fois 🙂

Les liens utiles qui m’ont aidés :

Correction de l’inconsistance d’usr sur FreeBSD

Samedi, j’ai continué mon aventure FreeBSD sur mon ordinateur de gaming et mon objectif était de résoudre le problème dont j’ai parlé dans l’article précédent, avec le slice consacré à /usr. J’écris cet article qu’aujourd’hui parce qu’hier, c’était Pâques x)

Voici un petit rappel du problème que j’ai rencontré une fois l’installation de FreeBSD terminé, et le boot réussi.

THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
        ufs: /dev/nvd0p3 (/usr)

C’est le message que j’avais et qui m’interdisait l’accès à ma session puisque tout ce qui permet cette dernière dépend de /usr 🙂 J’ai donc cherché comment corriger ce problème. Mais, je n’ai pas réussi par la méthode à utiliser dans ce type de cas. Je vous direz à la fin comment j’ai réglé le problème, mais d’abord voici ce que j’ai appris en m’y confrontant.

Tout d’abord, ce genre de problème se produit lorsque le système d’exploitation n’a pas été éteint convenablement. Je ne me souviens plus comment je m’y suis prise pour éteindre mon ordinateur ou le redémarrer une fois l’installation terminée. Je ne suis pas sûr que le problème ait réellement été provoqué par ce type d’évènement, mais quoi qu’il en soit, c’est ce qui arrive en cas d’arrêt brutal de l’ordinateur. Lorsque ça se produit, il y a un risque pour que les mesures à mettre en place entraine la perte des données. Il est bon de faire une sauvegarde des données avant tout opération de maintenance pour corriger le problème. Par contre, pour l’instant n’ayant pas pu aller plus loin dans les mesures à prendre, je n’ai pas encore appris à faire cette sauvegarde. Je n’en parlerais donc pas ici.

La première chose qui peut aider dans ce cas, et dans d’autres, c’est de pouvoir lister et regarder les systèmes de fichiers présents dans mon très cher FreeBSD. Ainsi je pouvais voir entre autres /usr au cas où j’aurais fait une boulette lors du partitionnement et du montage du slice pendant l’installation. Pour avoir la liste des systèmes de fichiers, il faut aller dans /etc/fstab.

cat /etc/fstab

Apparemment, de ce côté là, ça avait l’air d’aller. Ensuite, il faut appeler un commande qui a pour fonction de vérifier la consistance des systèmes de fichiers et de réparer si nécessaire. La fonction en question est normalement appelé lors du boot du système d’exploitation. C’est de cette manière que le système a pu m’avertir de l’erreur. Mais, on peut l’appeler soi-même pour dépanner.

fsck -t ufs /dev/nvd0p3

Malheureusement, il était impossible pour le système de faire quoi que ce soit, en raison d’un problème de superblock. Le seul moyen de corriger le problème, d’après le système, était de proposer un superblock alternatif à celui qu’il voulait utiliser pour le système de fichier de /usr. Ce serait bien si j’expliquais ça, mais je ne suis pour l’instant moi-même pas encore assez calée pour en parler x) Il s’agit en fait de bloques de mémoire. Il y a des plages libres et d’autres occupées et pour bien faire, les plages ont une certaine taille. Le système utilise ces tailles comme unités de mesure en quelque sorte pour stocker proprement et retrouver les différents systèmes de fichiers. Voilà pour très grossièrement imager et avoir un minimum une idée de ce que c’est pour avancer sur ce problème 🙂

Pour tenter de donner au système un superblock, il fallait que je sache lesquelles sont disponibles. Pour savoir ça, j’ai entrée la commande suivante :

newfs -N /dev/nvd0p3

Il est très important de ne pas oublier l’option -N sinon la fonction peut créer un nouveau système de fichier sur l’actuel et donc détruire ce qui s’y trouve. Cette option permet uniquement d’afficher les superblocks disponibles et ensuite il est possible de les tester pour réparer le système corrompu. Pour faire cette opération j’ai essayé la commande suivante :

fsck_ffs -b <le numéro du superblock> /dev/nvd0p3

Et malheureusement, ni cette commande, ni d’autres ont pu fonctionner pour moi. J’ai du me résoudre à corriger tout ça en faisant une chose radicale. Réinstaller FreeBSD. Il est possible que quelque chose s’est mal passé lors de l’installation, ou après, mais comme je n’arrivais à rien et que je n’avais pas encore eu l’occasion d’utiliser mon nouvelle OS, je n’avais rien à perdre.

J’ai donc tout réinstallé en ajoutant un service que je n’avais pas pris, et en testant au passage si je pouvais ajouter un /home comme Linux. Ce qui n’a pas été possible 🙂 Finalement après avoir refais cette étape, mis à jour le boot loader pour prendre en compte mon SSD et testé un petit cat /etc/fstab au cas où avant le reboot, tout était rentré dans l’ordre 🙂 J’ai pu accéder à ma session pour la première fois 😀

Aujourd’hui j’ai déjà commencé à télécharger le code-source du driver réseau approprié pour mon matériel et à le transférer via clé USB dans un répertoire temporaire. J’en parlerais au prochain article :p

Les liens utiles qui m’ont aidés :

Installation de FreeBSD effectuée avec succés

Et voilà, FreeBSD est installé sur mon ordinateur de compétition, et ça n’a pas été du premier coup. Pour ce premier article dans la catégorie FreeBSD, j’ai envie de vous résumer ce qui s’est passé et comment j’ai résolu un problème lors du reboot du système 🙂

Tout d’abord voici le contexte. Mon ordinateur est un MSI au nom commercial GT72S 6QE Dominator Pro G. Un ordinateur portable spécialisé pour le gaming avec des technologies dernière génération. J’ai eu envie d’installer dessus un système d’exploitation libre et open-source. Linux était intéressant, certes j’avais rencontré des problèmes, mais avec de la persévérance ça aurait sans aucun doute pu se régler. Comme je le disais dans mon compte-rendu tourné de façon humoristique, FreeBSD m’attirait et donc j’ai préféré ne pas insister avec Linux et tenter ma chance avec le daemon 🙂

Sur cet ordinateur, j’ai un SSD et un HDD. Pour exploiter les avantages du SSD, et en même temps éviter d’user ce dernier à coup d’écritures intempestives, j’ai décidé d’installer la base du système d’exploitation sur le SSD, c’est à dire les slices (partitions sur FreeBSD) boot, / et /usr sur le SSD, et le reste sur le HDD, c’est à dire swap, /var et /tmp. Oui sur FreeBSD, je n’ai pas vu de référence au slice /home comme sous Linux.

Mes premières tentatives avec table de partitions en MBR donnaient des soucis avec GRUB. Bon là, je ne pourrais pas trop vous dire si c’était normal, parce que j’avais l’impression que c’était le vieux GRUB des Linux précédemment installés, mais ça ne devrait pas parce que j’avais effacé totalement mes disques durs pour refaire les slices. Enfin bref, comme mon ordinateur pourrait passer à du BIOS EFI si j’en ai besoin plus tard, et puisque le MBR connait des limitations en nombre de partitions/slices, j’ai opté pour l’essai de tables en GPT. Et je me suis sentis plus sereine pour faire mes magnifiques slices avec leur labels et leurs points de montage tout propres.

Au cours de l’installation, j’étais sensé pouvoir accéder à la configuration du réseau pour avoir Internet, mais comme c’était déjà le cas en LiveCD, ma carte réseau n’était pas reconnue. Ce soucis est lié au fait que ma carte est trop récente et qu’il faut donc utiliser un driver spécifique qui forte heureusement existe en version libre 🙂 On peut le trouver pour Linux, mais ayant déjà testé le LiveCD de GhostBSD, je sais aussi que ça fonctionnera pour FreeBSD. Me voilà rassurer pour la suite. En attendant, je fais sans Internet (enfin, je l’ai sur mon autre ordinateur, sinon pour les infos et pour vous écrire, je ne serais pas rendue x) ).

J’ai créé une utilisatrice qui n’est autre que moi-même. Je me suis invitée dans les groupes operator et wheel au minimum. Mot de passe admin et login/mdp pour ma session. Quelques services intéressants comme la souris en ligne de commandes (ça sert dans certains programmes qui simulent une interface pseudo-graphique en mode texte) et d’autres trucs. Et enfin, arrive la fin de l’installation et je reboot 🙂 Et… patatra, le bootloader ne reconnaissait pas le SSD :s Si vous rencontrez ce problème, ou passez par un moteur de recherche, voici ce que j’ai eu à l’écran :

gptboot: No /boot/loader on 0:ad(0p2)
gptboot: No /boot/boot/kernel on 0:ad(0p2)

Ensuite, il est demandé d’entrer le slice contenant le root après « Boot: », mais si dans certains cas réécrire X:ad(XpY) avec Y égal au bon slice et X, le bon disque, dans mon cas, ça ne fonctionnait pas. Et de plus cette solution est temporaire. En effet, le problème ici est que le SSD n’est tout simplement pas pris en compte par le bootloader. Il faut donc lui dire d’activer la prise en compte de ce dernier pour pouvoir booter dessus 🙂

J’ai voulu le faire après installation avec le LiveCD, puisqu’il m’était impossible d’accéder au système sans bootloader fonctionnel. Enfin en tout cas, je ne sais pas le faire. J’ai songé à monter le slice du SSD pour pouvoir accéder au fichier de configuration du bootloader, mais je n’y arrivais tout simplement pas. Je ne sais pas très bien si je n’avais pas les droits appropriés, ou autre chose. Donc, j’ai choisis la seule option que j’ai trouvé, recommencer l’installation de FreeBSD et accéder au shell à la fin avant de rebooter 🙂

Une fois l’installation terminée, l’installeur de FreeBSD demande si l’on souhaite accéder au shell pour procéder à quelques configurations, ajouter des paquets, etc… Une fois accepté, j’ai ouvert le fichier loader.conf avec vi de cette façon :

vi /boot/loader.conf

Une fois dans vi, ce fut l’occasion pour moi d’apprendre à manipuler ce programme. J’avais un peu l’impression de manipuler de la nitroglycérine parce que c’est assez particulier comme vous pouvez le voir dans ce lien : http://home.gna.org/unix-initiation/website/node192.html
J’ai ajouté dans le fichier loader.conf qui était vierge, les deux lignes suivantes :

nvme_load="YES"
nvd_load="YES"

C’est deux lignes indiquent au bootloader qu’il existe un disque avec un format /dev/nvdX et pour que cela fonctionne il ne faut pas oublier d’accéder au namespace nvme. Le HDD en tant que disque ATA utilise un fomat /dev/adaX, et par défaut c’est ce format qui est utilisé par FreeBSD si on ne lui dit rien. D’où l’importance, dans mon cas, de passer dans le shell pour configurer le bootloader après installation avant le premier reboot 🙂 Dés que j’ai enregistré les modifications et lancé un reboot, tout a fonctionné à merveille 😀

Bon, un autre soucis s’est présenté. Le slice /usr semble rencontrer un problème indiqué ainsi par le système :

THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
        ufs: /dev/nvd0p3 (/usr)

Du coup, je ne peux pas accéder à ma session personnelle. Heureusement, à la place FreeBSD me donne accès à une session en solo pour me permettre de procéder aux corrections. Il me reste à comprendre ce problème et à apprendre à le corriger :p Ahhh, je suis trop fière de moi 😀

Les liens utiles qui m’ont aidés :