Installation d'une Debian testing sur un Laptop Dell Studio XPS - Page 1

yop,


J'ai une distro fraiche, l'installeur m'a donc demandé de créer un compte. Parfait.

J'ai créé un autre utilisateur, dans le même groupe (j'ai, au passage, supprimé le groupe créé en rab par kuser).

J'ai modifié mon fstab pour avoir ma partoche de données dans /mnt/Data.

Jusque là tout va bien.


Par contre, là où ça coince :
Les fichiers de /mnt/Data appartiennent à moi, et leur permissions ne leur permettent ni d'être vus ni d'être modifiés par les autres utilisateurs de mon groupe. J'ai donc instantanément plongé dans chown (useless) et chmod (ça doit être le bon ce coup-ci) pour trouver la phrase magique à dire à bash pour intercéder pour moi auprès du file system. Mais la page de man est tellement mystérieuse, et j'ai tellement rien envie de foutre en l'air, que je viens vers vous pour vous demander quel est le groupe de chiffre octal magique qui permettra à mes deux users du même groupe de jouir sans souci de tous ls fichiers de mon /mnt/Data .

Merci d'avance.

oué, tu as :
chmod g pour group
chmod u pour user
etc
C'est un peu plus parlant que l'octal

Un grand merci.

Si je comprends bien, on prend avec g les autorisations existantes, on va les copier avec +, et en autoriser l'écriture et la lecture, voire l'exécution si elle est déjà autorisée pour un autre utilisateur, avec rwX

Je pensais qu'il fallait faire :
chmod -R u+o, pour prendre les permissions de l'utilisateur actuel et les donner à tous les autres. J'ai bien fait de pas lancer la commande

Merci encore ^^


(cross)

Oué c'est ça.
Par exemple, chmod u-w retire les droits en écriture à l'utilisateur qui exécute la commande sans toucher au reste.
Tu ne t'es jamais servi de chmod ? C'est marrant, j'aurais pensé que c'était une commande souvent utilisée sous un linux.
Je m'en sers assez souvent quand je dois configurer un truc

(oui, je suis surpris aussi que Folco ne maîtrise pas ça sur le bout des doigts ^^)

Tout simplement parce que les installs des distros font ça tout seul quand il n'y a qu'un user de configuré, donc habituellement, je ne m'occupais de rien.

Bon, je vais pas refaire un troisième topic pour cette install, donc je modifie le titre et on continue...


Je suis donc sur une debian testing.
J'ai eu aujourd'hui une maj des drivers X11, notamment des drivers ati et radeon. Je n'utilise pas le driver proprio.
Avant ça, j'étais en 1920x1080, détecté automatiquement. C'est en effet la résolution nominale de l'écran.

Depuis la maj, KDE ne me propose plus que du 1440x1050, ce qui est assez gênant. Impossible de revenir à la version précédente des pilotes par Synaptic (Paquet -> Forcer la version).

Comment réparer ça svp ?

Vérifie d'abord si tu es encore en train d'utiliser le bon pilote ou si c'est le pilote vesa qui est chargé à la place (et dans ce dernier cas, pourquoi).

Je sais même pas comment faire pour vérifier quel est le driver utilisé en ce moment, et suite à ça le changer pour le bon

(lshw ne m'a pas aidé)

C'est du virtualisé, non ?
VirtualBox ?
=> Réinstalles les guest additions

Non, c'est pas du virtualisé. Et je vois quelques messages d'erreur/warning au boot du kernel, je ne sais pas où se trouvent les logs... Probablement dans /var/qqchose j'imagine ?

(Ah OK, je croyais que tu virtualisais tes linux maintenant)

glxinfo | grep string
Ça donne quelque chose comme:

server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 (RV280 5964)  TCL DRI2
OpenGL version string: 1.3 Mesa 9.2.0

Ici, c'est pour une vieille Radeon 9200SE (AGP) avec le pilote radeon.

S'il y a écrit llvmpipe ou softpipe dans le OpenGL renderer string, il y a quelque chose qui ne va pas.

server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 128 bits)
OpenGL version string: 2.1 Mesa 9.1.6OpenGL shading language version string: 1.20

Bon, ben c'est pas le bon driver. j'imagine que mv ati vesa ça fera rien ?

Pen² -> yep, mais pas sur cette machine en fait

Bon, dans /var/log/kern.log, j'ai ça :

Sep 1 15:20:51 Weygand kernel: [ 5.968345] [drm] radeon kernel modesetting enabled.Sep 1 15:20:51 Weygand kernel: [ 5.968479] [drm:radeon_pci_probe] *ERROR* radeon kernel modesetting for R600 or later requires firmware-linux-nonfre e.

Malheureusement, je n'arrive pas à activer de dépôt non-free dans Synaptic, je n'ai que main et contrib à disposition, sur le mirroir de Debian testing chez OVH. Je suppose que le pépin vient de là, non ?

Bon, ben on fait comment quand c'est comme ça ? On change de distro et on a 4 ou 5 heures d'installation et de config dans la vue ?

(OK)

Bon, et bien, bien que les paquets soient suffixés par nonfree, c'est non-free qu'il faut écrire dans le sources.list. Du coup j'ai installé le paquet, rebooté, et magie magie ça marche. Je sais pas comment je suis passé plus de quelques heures à côté d'une telle évidence

Tu n'avais qu'à utiliser une distribution qui a une politique "100% libre" raisonnable et n'essaie pas de l'appliquer au firmware.

J'ai pourtant rien installé de propriétaire, c'est ça que je comprends pas
C'est à la mise à jour que le firmware est devenu nécessaire, jusque là ça marchait avec le driver ati ou radeon sans que je touche à rien... D'habitude ça casse quand j'installe un truc proprio, pas quand j'utilise pour une fois le driver par défaut ?!?

Tu as installé Distro/KDE/GNU/Linux© c'est propriétaire!

Oui, mais ça appartient à la Liberté !!!!

Je suppose qu'avant, Debian ne s'était pas rendu compte qu'il y avait du firmware.

Bon, le portable n'a que 1/2 heure d'uptime, parce que le proc s'occupe de tout et chauffe comme un taré, du coup le PC se coupe par sécurité. pasglop :/
J'aimerais donc installer le driver proprio ATI pour le décharger. Problème, sous Debian, j'ai pété pas mal d'install comme ça, c'est pas une Ubuntu ou une Mint de ce côté...

Question : comment faire pour redémarrer, sans charger le module proprio si jamais celui-ci venait à me foutre l'installation en l'air ? Le but, en cas de pépin, serait de redémarrer au moins une fois pour le désinstaller. Il y a une option à filer au kernel pour ça ? Je me souviens avoir déjà chercher, mais pas trouvé...

Merci d'avance pour votre aide.

Tu démarres en mode non graphique et tu désinstalles à la main, comme un homme

j'allais le dire

hmmm... Faut que je trouve le script qui lance X afin d'y caller un sleep pour pouvoir faire un Ctrl-C alors. Bien vu, merci.

edit -> à moins de faire ça directement dans un tty ? Ca devrait pas poser de souci, donc.