[Wiki] Linux

Répondre
Partager Rechercher
Citation :
Publié par SiroTeur
Si j'ai bien compris ce que je faisais, j'ai mes 3 SSD de 120gb réunis en un seul volume (sda, sdb, et sde). Sur ce volume, j'ai trois partitions /home, root et swap.
Il y a une section de l'un des disques qui est utilise pour le /boot/efi

Mes deux hdd de 1Tb(data sdc et Media sdd), je ne savais pas trop quoi en faire, vu que j'ai récupéré un NAS récemment. Du coup, y'en a un avec mes jeux Steam et mes VM, et l'autre qui est vide en attente d'une utilisation.

Sachant que je vais acheter un meilleur NAS (post a venir) d'ici le mois de novembre, et que je vais remplacer mes 3 SSD @120GB par 2 SSD @500GB au même moment.

Alors, j'ai peut être mal compris l'intérêt de LVM, mais je pensais que réunir tout l'espace de plusieurs disques dans un seul volume, ça faisait un peu comme un "raid".

Je dois admettre que j'étais un peu presse de faire l'installation de ma machine, et que plus je réfléchissais, et plus j'allais rester encore sur Ubuntu, que je voulais changer a la base.
Tu m'as perdu entre ton graph et ce que tu dis =)
Faudrait un /etc/fstab cela serait plus lisible je pense.

Perso, déjà je mettrais les 2 HDD en sda et sdb pour eviter les erreurs futures. Dans ton cas de figure, c'est un peu tard, mais est ce que le NAS est vraiment plus intéressant que ton PC au niveau conso et facilité d'utilisation ? Tu risques d'avoir une redondance d'espace disque et une consommation totale d'electricité supérieur. Ensuite je connais pas tes besoins. J'avais étudié un temps un NAS pour la télé (XBMC essentiellement) puis j'ai laissé le PC avec une CM faible conso et un cable usb et HDMI bien long.
120Go en raid1 via les SSD, cela consomme peu et si tu mets les HDD en stockage avec lancement sur demande, cela te fait une conso elec assez faible.

LVM, jamais utilisé mais cela ressemble à un RAID0 plus souple. Le problème c'est que si un dur décède, tu perds tout le volume et là, cela fait TRES mal. (tu peux faire du RAID sur du LVM mais bon )

La joie de linux, c'est que niveau disque dur, tu peux tout remodifier sans avoir à reconfigurer (hormis refaire le boot suivant les modifs). Le seul inconvénient, c'est de recopier les données.

-------

Il y a le même truc avec la config de caniveau royal. En dehors du swap (27Go oO), pas besoin d'autant de partitions sauf cas spécifique (limité le /tmp par exemple).
Genre / sur le SSD1 et /home pour le SDD2.

Si /tmp prend trop de place, un simple bind dans /home et hop là.
J'ai des palpitations en voyant que @SiroTeur fait du btrfs au dessus de 2 PV portés par des partitions, le tout sans redondance

wall of text inc.

Je vais expliquer un peu LVM, parce que c'est généralement ce qui est mal compris.
LVM permet de dissocier les périphériques physiques du système de fichier avec une souplesse très agréable et des fonctionnalités sympathiques comme les snapshots.

A la base, on trouve les Physical Volumes (PV), qui peuvent être des disques locaux, des agrégats (raid software avec mdadm, raid hardware avec une carte dédiée), des volumes distants (accédés via une carte fiber channel, en iSCSI... peu importe), etc.
Avec ces PV, on crée des Volume Groups (VG). De base, c'est grosso modo du JBOD : si on perd un PV (typiquement si @SiroTeur crame un SSD), on perd tout ce qui est dans le VG . On limite évidemment ce risque avec du raid local ou des LUNs distant. Dans le monde serveur ça permet de faire des trucs très cool (ajout et retrait de PV à chaud, réplication d'un PV à un autre, migration stockage à chaud...). On verra plus loin qu'on peut aussi s'en sortir sans.
Dans les VG, on va allouer des Logical Volumes (LV). C'est ce qui va porter le système de fichier et servir pour les points de montages. Comme ce sont des objets logiques, on va pouvoir jouer avec et faire tout ce qui fait chier @Caniveau_Royal avec des partitions de disques physiques, ou faire des snapshots
Une bonne pratique est de ne pas allouer l'ensemble de l'espace disponible dans le VG, comme ça si un point de montage vient à se remplir plus que prévu, on peut augmenter sa taille en une ligne de commande. On peut évidemment réduire simplement la taille d'un LV (non plein).

Un LV peut être alloué de 2 façons :
* thick provisioning par défaut : on réserve de l'espace (logique évidemment : on s'en fout de la continuité) et on est sûr que cette espace sera disponible. On choisit en général ça pour les points de montage qui ne doivent pas se retrouver à sec (la racine...), mais aussi pour ceux qui risquent d'affamer les autres (/var...).
* thin provisioning : on déclare la taille du volume mais l'espace n'est pas réservé tant qu'il n'est pas utilisé. Typiquement en LVM avec un /home sur un thin volume, @Caniveau_Royal aurait eu 122Go libre dans le VG, où il aurait pu piocher pour son /tmp.
Évidemment, on jongle avec l'espace des LV d'un même VG, c'est pas de la magie

Je disais plus haut que si on perd un PV on perd le contenu du VG, mais qu'il y avait une solution... On peut faire du RAID directement au niveau du LV <o/ (on choisi LV par LV le niveau de RAID désiré, 1,4,5,6 ou 10, et on peut même changer ce niveau à chaud)
Je ne l'ai jamais utilisé (hors test rapide par curiosité), mais ça existe

Perso, j'aime beaucoup LVM, pour plusieurs raisons :
- C'est vieux, je commence à l'être moi aussi, donc je connais.
- C'est dispo partout, contrairement à BTRFS et ZFS.
Par contre il y a des trucs que j'aime moins :
- C'est relou quand les PV sont des partitions (pareil avec BTRFS et ZFS). Des fois on n'a pas le choix (genre /boot avec des grub pas assez récent) donc on fait avec, mais si c'est pas le cas (en particulier dans des VM) franchement c'est mieux en faisant des PV avec les disques complets
- Pour les snapshots je préfère quand même ZFS et BTRFS.


Pour @SiroTeur, si tu as déjà fait ton install :
- ajoute ton 3e SSD dans le VG
- passe tes LV en raid pour éviter de tout perdre en cas de pb sur un disque (tu as 3 disques ce serait dommage de s'en passer)
Si tu ne l'as pas fait (ou que tu es prêt à réinstall), BTRFS ne sert à rien au dessus de LVM. Soit tu fais tout en BTRFS en lui donnant directement les disques, soit tu fais du LVM + XFS ou ext4.
Le principal problème que je vois pour l'utilisation de BTRFS dans ton cas, c'est que tu as 3 disques, et que c'est raid 0 ou 1 uniquement donc tu ne pourras pas utiliser les 3.


Après pour les problématique de points de montage, sur des machines perso faut pas s'emmerder à les multiplier. L'espace disque se gère bien à la main sans avoir besoin de mettre de barrières logique. Du coup perso je fonctionne ainsi :
Je fais du LVM ou du BTRFS parce que ça me permet d'avoir un /home qui survit à une reinstall, tout en n'étant pas emmerdé par du redimensionnement de partition.
Je laisse tout le reste dans la racine (sauf /boot & co si grub ne gère pas évidemment)
Merci pour ces infos, je fais un truc similaire sur ESX: j'ai 3 disques et chaque disque physique correspond -si j'ai bien compris- à l'équivalent un volume group et dedans je fais plusieurs disques virtuels qui bossent par paire/trio selon ce dont j'ai besoin.

Genre j'ai :
Un RAID 1 de 20Go sur 3 disques (pour les documents importants)
Un autre RAID 1 sur 2 disques pour sauvegarder les VM qui durent dans le temps
Et une bonne partie du reste en JBOD parce que je m'en fous de tout perdre, ce sont les films/séries/musiques.

Je voulais passer sur Proxmox mais j'avais rien compris aux LVM, au final ça m'a pas l'air bien différent de ce que je fais (même si ça reste à un petit niveau, j'ai que 3 disques de 1 ou 2To et un SSD de 32Go, qui sert quasi qu'à ESX)

En tout cas je crois avoir mieux compris comment fonctionnent les LVM, même si je compte pas m'en servir avant longtemps.
Citation :
Publié par SiroTeur
[...]
Mais il est clair que je vais refaire l'installation. Et probablement pas utiliser LMV.
C'est le mieux à faire t'as un truc vraiment pas propre là. Et si tu veux des snapshots, BTRFS est un bon choix (mais tu le mets partout, ne t'emmerde pas à faire un /home séparé).
Citation :
Peut-être avec un RAID entre le SSD et l'un des HDD si c'est possible.
C'est techniquement possible, mais sans aucun intérêt en pratique.
Citation :
Pour les messages d'erreur ACPI par contre, c'est un autre problème. J'ai passe les derniers jours a potasser a droite et a gauche pour essayer de comprendre d'ou venait le problème. Et la seule solution que je trouve c'est acpi=off. Planquer le problème plutôt que le résoudre j'ai l'impression.
C'est clairement cacher ça sous le tapis, c'est dommage mais c'est souvent relou à troubleshoot.

Citation :
Publié par Metalovichinkov
Merci pour ces infos, je fais un truc similaire sur ESX: j'ai 3 disques et chaque disque physique correspond -si j'ai bien compris- à l'équivalent un volume group et dedans je fais plusieurs disques virtuels qui bossent par paire/trio selon ce dont j'ai besoin.

Genre j'ai :
Un RAID 1 de 20Go sur 3 disques (pour les documents importants)
Un autre RAID 1 sur 2 disques pour sauvegarder les VM qui durent dans le temps
Et une bonne partie du reste en JBOD parce que je m'en fous de tout perdre, ce sont les films/séries/musiques.

Je voulais passer sur Proxmox mais j'avais rien compris aux LVM, au final ça m'a pas l'air bien différent de ce que je fais (même si ça reste à un petit niveau, j'ai que 3 disques de 1 ou 2To et un SSD de 32Go, qui sert quasi qu'à ESX)

En tout cas je crois avoir mieux compris comment fonctionnent les LVM, même si je compte pas m'en servir avant longtemps.
Sur VMware tu parles des cluster de datastore ? (ça fait longtemps que j'ai pas fait d'ESX pur, du coup je sais plus ce qui est spécifique au vCenter ou pas)
Si oui, ça s'en rapproche un peu, on y retrouve les notions de thin provisionning, live migration pour pouvoir intervenir sur les disques à chaud, etc.

Pour la virtualisation sur du KVM (par exemple Proxmox), LVM propose des trucs que je n'ai pas abordé pour ne pas partir encore plus loin dans mon wall of text
KVM sait utiliser différentes techno pour ses pools de stockage.
Du mode fichier :
* en local sur ext4, xfs, zfs, btrfs... (ext4 et xfs pouvant être au dessus d'un LVM)
* sur le réseau en nfs
Du mode bloc :
* en local sur lvm : tu lui indiques un VG et il va créer des LV pour chaque disque virtuel.
* sur le réseau en iscsi
Chaque techno a ses avantages qui vont des performances pour tel type de workload à la facilité de réplication/backup.
Pour mon usage perso, j'utilise des fichiers par simplicité/habitude.

Par contre quel que soit ton hôte, je te recommande chaudement LVM pour les invités Linux, c'est de mon point de vue ce qui il a de plus souple pour resize.
Typiquement tu as un /var plein, tu ajoutes un disque de 40Go en thin provisionning à ta VM et VM :
pvcreate /dev/sdX
vgextend vgroot /dev/sdX
lvextend -L +2G -r /dev/mapper/vgroot-lvvar
Et hop tu as 2Go de plus dispo dans /var. Et 38Go dispo pour agrandir à la demande n'importe quel autre LV de vgroot, sans bouffer de place sur tes disques. C'est infiniment plus souple que de resize les vdisk comme on a tendance à le faire pour des VM windows, et ça t'évite les conneries de déplacement de partitions.
Oula, ça devient bien trop technique pour moi J'ai juste un petit serveur HP à la maison, le datacenter ce sera pour l'autre maison !
Chaque disque est un datastore et je gère tous les disques virtuels directement dans les VM, je fais juste attention à bien mettre des disques virtuels sur des disques physiques différents.

Je réessaierai LVM à l'occasion, c'est utilisé au boulot et ça me fait chier de pas savoir comment ça fonctionne (même si ça me regarde pas, c'est toujours sympa de comprendre) avec ce petit pavé j'y vois un peu plus clair... Et je sais que si je bloque, quelqu'un pourra m'apporter les réponses
J'avoue que je traîne un peu trop là dedans et que j'aime faire l'effort d'expliquer, ça me permet de remettre mes idées au clair
Mais c'est, à mon avis, un truc intéressant à comprendre, au moins l'abstraction device physique | volume logique, car c'est quelque chose qu'on retrouve(ra) partout.
Ça y est. En trois commandes, j'ai upgradé sur Debian 10.
Merci flatpak & Steam qui m'ont rempli /var/lib tant qu'il n'a pas suffi de les désinstaller, mais en urgence y aller du rm -r /var/lib/flatpak/repo, rm -r /var/lib/flatpak/runtimes en plein milieu du dist-upgrade, avec le système qui braillait : y a plus que 90 Mo sur /var !
En pleine montée d'O.S., bon...

Je suis pas sûr de vouloir le réinstaller un jour, ce flatpak-là.
Les partitions c'est tabou, on en viendra tous à bout.
Tu fais du desktop, mono-utilisateur, t'en as rien à foutre que tel ou tel répertoire dépasse les XX% de ton disque dur, si t'as besoin de place tu sais quelles données tu peux supprimer.
C'est pas faux...

/dev/sda1 * 2048 48828415 48826368 23,3G 83 Linux
/dev/sda2 48830462 500117503 451287042 215,2G 5 Étendue
/dev/sda5 48830464 68360191 19529728 9,3G 83 Linux (/var à la con, tout plein)
/dev/sda6 68362240 131227647 62865408 30G 82 partition d'échang (/swap)
/dev/sda7 131229696 135133183 3903488 1,9G 83 Linux (/tmp trop petit)
/dev/sda8 135135232 500117503 364982272 174G 83 Linux (/home)


Ça se merge, les partitions ?
Je peux regrouper sda5...sda8 en une seule ?
Ça me plairait bien !

Y a des gens qui proposent d'y aller au symlink...
Je ne sais pas si ça marche vraiment, mais on perd la place des partitions que l'on abandonne, puisqu'on va juste ailleurs.
C'est un peu sale, non ?

Dernière modification par Caniveau Royal ; 19/09/2019 à 22h27.
C'est sale oui.
Ton /home il est sauvegardé ailleurs ?
Si oui, et que ton /var rentre dans la partition de / (fais de la place en vidant les caches, apt en particulier) le plus simple à mon goût c'est de faire ainsi :
boot en single mode
mount -o remount,rw / (pour pouvoir écrire sur la racine)
mount /dev/sda5 /mnt (pour pouvoir accéder aux données du ton /var)
rsync -avn /mnt /var (un rsync et pas un cp pour conserver les droits, et fais gaffe à bien mettre /mnt et non /mnt/ )
vérifie le contenu de /var (si il contient var, tu t'es planté, faut que tu mv /var/var/* /var/ )
vi /etc/fstab et tu commentes le point de montage de /var, /tmp, /home, et le swap

Tu reboot normalement et tu vérifies si ça fonctionne toujours (tu auras un nouveau /home vide, donc tes réglages habituels ont disparu, mais tu as une sauvegarde ;p )
Si c'est le cas, tu vas pouvoir faire la suite avec gparted en graphique.
Tu supprimes tout sauf sda1
Tu agrandis sda1 en gardant la place pour ton swap à la fin du disque.
Tu crées ta partition de swap
Tu modifies /etc/fstab pour faire pointer ton swap au bon endroit
Tu récupères la sauvegarde de ton /home
Tu reboot pour vérifier que tout fonctionne.

enjoy, tu n'as plus qu'une partition + swap, fini les emmerdes de partition pleine.
Citation :
Publié par Caniveau Royal
C'est pas faux...

/dev/sda1 * 2048 48828415 48826368 23,3G 83 Linux
/dev/sda2 48830462 500117503 451287042 215,2G 5 Étendue
/dev/sda5 48830464 68360191 19529728 9,3G 83 Linux (/var à la con, tout plein)
/dev/sda6 68362240 131227647 62865408 30G 82 partition d'échang (/swap)
/dev/sda7 131.229696 135133183 3903488 1,9G 83 Linux (/tmp trop petit)
/dev/sda8 135.135232 500.117503 364.982272 174G 83 Linux (/home)


Ça se merge, les partitions ?
Je peux regrouper sda5...sda8 en une seule ?
Ça me plairait bien !

Y a des gens qui proposent d'y aller au symlink...
Je ne sais pas si ça marche vraiment, mais on perd la place des partitions que l'on abandonne, puisqu'on va juste ailleurs.
C'est un peu sale, non ?
Ce bordel

du -H c'est mieux


Le plus simple c'est de booter sur du knoopix.

Pour /var, cela depend de ce que tu as dedans. Mettons que ce soit de l'apache, tu pointes sur les /home des users ou tu dis que le root est dans /home/www par exemple.
Sinon, mount -bind est ton ami
Merci ! Mais ça me fait quand même stresser toutes ces opérations-là. J'ai l'impression de ne pas encore avoir le niveau.

Ce matin, alors que l'apt autoremove avait fait peu de choses, j'ai lancé un apt autoclean qui a libéré 1,2 Go, puis un apt clean, qui a libéré 3.0 Go, vidant le cache.
Ignorant qu'il fallait aller jusque-là, je n'avais jamais exécuté cette dernière commande depuis l'installation de Debian 9, il y a quelques mois. Or, je l'ai fait vivre, et passé Debian 10 dessus.

Bilan : aujourd'hui :
/var = 0,8 Go.
/usr/lib = 13.2 Go

Le jour de la partition pleine :
/var/cache = 4,6 Go
/var/lib = 4.8 Go
avec flatpak + steam dedans pour environ 4 Go.

Mes conclusions :
- Gare au cache, donc.

- /var avec 0,8 Go me semble bien plus ok et vivable à long terme ; s'il reste dans ce sillage, il ne sera pas nécessaire de changer cette partition.

- Tant que je parviens à faire s'installer les logiciels dans /usr/lib et pas dans /var/lib, je prendrai de l'espace sur /home et ça ira bien.

- Si je réinstalle de nouveau Steam, j'hésiterai à reprendre flatpak. Le principe d'un logiciel qui met un repo Git dans /var/lib = , surtout quand celui-ci fait 3 Go et augmente au fil des mises à jour d'on ne sais pas quoi, mais qui ne nous concerne pas forcément. Si je le fais, il faudra que je le force à s'installer ailleurs.

Il me reste à traiter le problème de /tmp pour être confortable :
Aujourd'hui j'ai dévié un programme Spark très consommateur de fichiers temporaires sur un répertoire /data/tmp créé sur /sdb par ses properties de programme.
À lire ce post, je pourrais faire un
Code:
sudo mount -B /tmp /data/tmp
(un autre posteur répond en faisant un braillou qui dit qu'il faut faire plutôt un -M, mais le premier a douze votes, le second, deux).

Pour tenter l'expérience le temps d'une session : j'enlève mes propriétés, je lance le programme, et vois mon répertoire /data/tmp se remplir. Mais ce que ne dit pas le post, c'est :
===> Ne faut-il pas supprimer /tmp avant pour que cette commande marche ? Ça voudrait dire reboot et plantage d'emblée, non ?
lsof +D /tmp/ me donne six processus dessus : deux roots, deux gnome, un ssh-agent, et mon éditeur Eclipse qui l'emploient. Je ne me vois pas les casser (sauf le dernier).

===> Comment je pérennise ça sur mon /etc/fstab ? Actuellement, j'ai cela :
Code:
# /tmp was on /dev/sda7 during installation
UUID=65fc4d66-da96-4973-a81d-d6b63df92412 /tmp            ext4    defaults        0      2
Une entrée /etc/fstab de /tmp vers /data/tmp, comment s'écrit-elle ?
Globalement les Unix sont flexibles en ce qui concerne le partitionnement. Et puis du moment que t'as un backup, pas la peine de se stresser (c'est en faisant des conneries qu'on apprend ).

Surtout le dossier tmp, c'est du temporaire comme son nom l'indique (tu peux le vider à l'arrache, ça cassera rien, d'ailleurs je crois que c'est le cas entre les boots). Je m'emmerderai pas à ta place, tu bootes sur un gparted sur USB, tu fusionnes les partitions que tu veux, tu les vires de ton fstab, et t'auras un dossier "tmp" classique sur ta partition "/".

Dernière modification par Dr. Troy ; 22/09/2019 à 13h48.
Entre 2 boot oui, mais en temps réel c'est plus aléatoire.

Franchement, je capte pas le délire de caniveau, c'est une usine à gaz et cela va devenir encore plus une usine à gaz. La solution pour une remise au propre a déjà été donné.
Citation :
Publié par Caniveau Royal
[...]
Dis toi que ta situation actuelle est le résultat de ton choix, non recommandé par l'installer Debian, de séparer /tmp et /var, et que grâce à ce choix à l'époque tu réalises mieux à présent ce que ça implique.
Donc t'as appris un truc, tu as compris que ça sert dans certains cas mais que ça engendre des merdes si on ne prend pas tout en compte.

C'est cool, tu peux cocher la cas "je sais ce que ça fait de faire plein de partitions", maintenant tu peux faire comme c'est recommandé, tout mettre dans la même partition.

Si vraiment ça te chagrine, refais une install en LVM/BTRFS/ZFS, tu pourras à nouveau t'amuser comme un fou avec des montages pleins qui te bloquent, mais ce sera plus souple à débloquer.
Sinon :
mkdir /home/bordel
mkdir /home/bordel/var
mkdir /home/bordel/tmp
mount --bind /home/bordel/var /var
mount --bind /home/bordel/tmp /tmp

(que tu rajoutes dans fstab à la place des lignes prévu).

Ensuite, pour ne pas perdre de la place, je te conseilles de faire :
mount /dev/sda7 /var/log
Parce que bon, faut pas gacher.

Et si tu utilises beaucoup ton navigateur :
mount /dev/sda5 /home/$USER/.cache

Et tu es paré pour encore 10ans !
Citation :
Publié par Eyce Karmina
Les partitions c'est tabou, on en viendra tous à bout.
Tu fais du desktop, mono-utilisateur, t'en as rien à foutre que tel ou tel répertoire dépasse les XX% de ton disque dur, si t'as besoin de place tu sais quelles données tu peux supprimer.
Mais tellement, je débarque sur la page, et le seul truc qui me vient à l'esprit c'est un bon gros WTF. Même en prod j'ai jamais vu autant de complexité inutile.
Hello à tous !

Madame possède un vieux laptop qui peine beaucoup trop sous Windows 10. Je lui ai proposé d'installer linux, elle semble d'accord. N'étant pas une spécialiste j'aimerais lui mettre une distrib facile d'utilisation et light, j'ai pensé à Lubuntu. J'ai juste ?

Specs de son laptop :
1,4GHz dual core i3-2365M
4 Go de RAM
Windows 10 x64

Je pensais lui mettre une petite partition pour l'OS linux (genre 20 Go) et garder toutes ses données sur sa partition Windows, comme ça j'en touche le moins possible. Elle gardera Windows en dual boot pour la suite Office.

Lubuntu est assez simple d'usage pour quelqu'un ne connaissant pas Linux, ou avez-vous d'autres distros légères et facile d'utilisation en tête ?

Merci
Citation :
Publié par Discworld
Hello à tous !

Madame possède un vieux laptop qui peine beaucoup trop sous Windows 10. Je lui ai proposé d'installer linux, elle semble d'accord. N'étant pas une spécialiste j'aimerais lui mettre une distrib facile d'utilisation et light, j'ai pensé à Lubuntu. J'ai juste ?

Specs de son laptop :
1,4GHz dual core i3-2365M
4 Go de RAM
Windows 10 x64

Je pensais lui mettre une petite partition pour l'OS linux (genre 20 Go) et garder toutes ses données sur sa partition Windows, comme ça j'en touche le moins possible. Elle gardera Windows en dual boot pour la suite Office.

Lubuntu est assez simple d'usage pour quelqu'un ne connaissant pas Linux, ou avez-vous d'autres distros légères et facile d'utilisation en tête ?

Merci
Lubuntu tourne sur 512mo sans problème, a vrai dire c'est pt la seule interface que j'ai utilisé sur linux...


Après, vu la bécane tu fais tourner n'importe qu'elle distribution linux, l'environnement ubuntu donc debian (l'ubuntu étant un dérivé de debian) bénéficie d'énormément de documentation Fr.

Mais sache qu' hormis certaines distrib orienté vraiment pour les spécialistes linux (arch,gentoo) qui sont plus que déconseillé pour un nouveau venu, il n'y pas vraiment de différence dans la facilité d'utilisation qu'on soit sur debian,linux ou dans l'univers redhat(centos/fedora).
L'avantage d'ubuntu c'est qu'étant donné leurs politiques... tu trouvera plus facilement le pilote pour faire fonctionner certains périphériques d'utilisation courantes.

Bref tiens toi en a Ubuntu/debian et choisi l'interface qu'il te plait (gnome,kde..)

Citation :
Publié par Erlum
Mais tellement, je débarque sur la page, et le seul truc qui me vient à l'esprit c'est un bon gros WTF. Même en prod j'ai jamais vu autant de complexité inutile.
Surtout pas en prod...

Une partition pour le /home, une pour les backup et une ensuite pour le reste... sinon tu devient fou à maintenir tout ca.

Plus c'est simple moins tu y passe de temps dessus..

Citation :
Publié par Metalovichinkov
Oula, ça devient bien trop technique pour moi J'ai juste un petit serveur HP à la maison, le datacenter ce sera pour l'autre maison !
Chaque disque est un datastore et je gère tous les disques virtuels directement dans les VM, je fais juste attention à bien mettre des disques virtuels sur des disques physiques différents.

Je réessaierai LVM à l'occasion, c'est utilisé au boulot et ça me fait chier de pas savoir comment ça fonctionne (même si ça me regarde pas, c'est toujours sympa de comprendre) avec ce petit pavé j'y vois un peu plus clair... Et je sais que si je bloque, quelqu'un pourra m'apporter les réponses
et encore.. attend ils ont pas abordés ceph qui est tous simplement génial d'ailleurs.

Dernière modification par derioss ; 28/09/2019 à 01h39. Motif: Auto-fusion
Message supprimé par son auteur.
Un de tes éléments matériel est mort comme tu a pu t'en rendre compte tout seul.
Le seul choix qui te reste, c'est de trouver un poth qui a une CG compatible ce qui m'a fois vu la gen ne sera pas bien compliqué.

Tu la met.. tu boot et si ta tjrs des soucis.. tu teste qu'avec une seule barrette de ram puis l'autre. si ta tjrs des merdes c'est forcément la CM.

Un disque dur qui merde, c'est facile à identifier, tu prend une distri bootable usb de diagnostic et tu scan ton disque.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés