Reprise du message précédent :
Vous savez si c'est possible de chainload un MBR depuis un grub lancé en UEFI ?

n'ayant pas la possibilité d'utiliser du UEFI ( pas de carte mère compatible chez moi ) il se passe quoi concretement quand on utilise grub en mode "UEFI" ?
 
on a toujours un menu grub de selection au boot ?
 
si oui alors il suffit d'ajouter comme d'hab une entrée supplémentaire dans le grub.cfg en le régénérant, avec les mots clés habituels pour lui dire où se trouve le secteur de boot de l'OS à charger  

Oui oui, c'est "juste" que tu passes ensuite au noyau les infos UEFI nécessaires pour modifier les options de boot depuis l'espace utilisateur.
J'ai essayé betement  

et ça me donne un "invalid EFI <je sais plus quoi >

 
Bah en fait, KDE fait un sync quand tu démontes la clé proprement.
Par contre, si t'as 16Go à écrire au moment du sync et que ça prend trois plombes, tu peux te prendre une belle erreur.

bon à part ça, c'est quoi cette update foireuse de driver video intel là
https://bugs.archlinux.org/task/38518?project=1
 
J'avais des petits bugs graphiques un peu partout, j'ai fini par downgrader

mince, j'ai fait une MAJ de ce paquet (xf86-video-intel), et j'ai nettoyé ma base de données depuis (yaourt -Sc)...
Savez-vous où je peux retrouver ce paquet ? car ARM est apparemment plus mis à jour...
Merci !

EDIT : en fait, j'ai rebooté depuis, et pas de bug en vue... donc wait & see... enfin, si qq'un sait où je peux retrouver l'ancien paquet (2.21.15-1), je prends !

   
 
D'ailleurs y a t il un réel intérêt à ne pas passer par pacman à part aimer le danger ?
Les paquets construits par yaourt sont mis dans le cache de pacman ?

Quel danger ? Jamais eu de problèmes avec yaourt

Laisse tomber, il y connais rien, y compile tout à partir des sources lui

mais dans un DESTDIR  

moi ce que j'ai compris de yaourt c'est que c'était surtout pratique pour ceux qui avaient beaucoup de paquet provenants du dépôt aur,

pour les autres qui ont très peu ou pas de paquets aur cette surcouche à pacman a moins d'utilité,

de toutes façons sur ce topic yaourt est mal vu , car souvent c'est associé à des gens qui ont fait les bourrins en installant un max de paquets de aur, comme ce dépôt est à risque ils ont alors souvent des problèmes de stabilité, bugs en tout genre

1. je pense avoir posé une question sur un paquet de extra... on peut en rester là  et oublier cette guéguerre débile à propos de yaourt ?
2. J'ai très peu de paquets aur, et si j'ai envie d'en installer, c'est MON problème. Donc merci d'oublier tout ça.
3. yaourt est bien plus pratique que pacman pour une utilisation courante, c'est pour cela que je l'utilise.
4. oubliez ma demande sur le fichier, tout semble stable...
 
Cactus, sur Arch depuis 6 ou 8 ans (je ne m'en souviens même plus tellement c'est loin), et toujours maitre de mon PC, merci...
 
pffff, z'êtes des gamins avec vos histoires de puristes alakon (c) .

susceptible le cactus
 

Mais je ne trollais pas (complètement), quelqu'un peut répondre sérieusement à mes questions ?  
Et faire un bisou à cactus pour le calmer ?

quand on vient chercher des poux sur la tête d'un chauve, oui...
(et mon pseudo n'a pas été choisi au hasard)

oui, yaourt n'est qu'une surcouche de pacman, donc les paquets sont stockés pareil.

NB : tant qu'on utilise pas l'option --aur, yaourt = pacman (avec une interface colorée plus intéressante pour repérer l'origine des paquets. Sinon, c'est strictement pareil, même avec un -Syu.
Merci de ne pas généraliser avec les "bourrins", chaque cas étant différent, et chacun étant libre d'utiliser sa distrib comme il l'entend.
Pour ma part, je ne suis pas venu pleurer sur un pb avec un paquet AUR, ni un pb de sécurité (et je ne me sers même plus de ces paquets, je finirai bien par les enlever, ça ne m'empêchera pas de préférer yaourt).

Vous allez vous piquer les lèvres avec mes épines...

la couleur est arrivée aussi avec les dernières versions de pacman

après pourquoi pas si yaourt te plait, mais quitte à privilégier le confort faut viser plus haut : une interface graphique

j'avoue que parfois ça me manque, quand j'utilisais mandriva c'était sympa d'utiliser certaines fonctionnalités comme le tri par catégorie, le moteur de recherche integré, la petite fenêtre qui donne le résumé du paquet, le change.log ( feature pas encore incorporée à pacman )

Il y avait un front-end pour pacman pour faire (presque ?) la même chose, mais je ne me rappelle plus du nom (EDIT : shaman je crois), et je ne sais pas s'il est encore maintenu.
EDIT : regarde ici : https://wiki.archlinux.org/index.ph [...] _Frontends

Sinon, la couleur est incomplète avec pacman. Lors de la liste des paquets à upgrader, ça reste monocolore. Avec yaourt, tu as le code couleur pour core/extra/etc... rien que ça, c'est tout con, mais j'apprécie et je cible de suite l'importance et/ou la catégorie du paquet mis à jour.

 
J'ai retrouvé sur arch rollback machine ( http://wiki.archlinux.fr/Arch_Rollback_Machine )
 

 
 
 
 
Sinon le troll yaourt, ça me fait doucement rire, on en a déjà discuté ici...
J'ai environ 80 package AUR, j'utilise arch depuis 7 ans, j'ai jamais crashé une install à cause d'AUR ou yaourt... C'est à dire que j'ai gardé des machines sous arch en appliquant les upgrade régulièrement pendant plus de 4 ans...
Du moment qu'on review les PKGBUILD (et scripts d'install) avant de les installer, c'est pas plus dangereux que de faire l'install à la main.

Ton expertise linux t'a permis d'éviter les paquets aur douteux, mais quid du ubuntien qui a migré chez arch et qui sera nettement moins vigilant ?
 
le dépot aur me sert que de modèle pour les pkgbuilds, je regarde ce qu'a fait le gars et j'apporte ensuite mes corrections en simplifiant certaines parties ou en rajoutant des options de compilations, ça a été le cas pour un pilote canon d'imprimante où le gars s'était compliqué la vie,
 
Après l'excès de paquets aur ne signifie pas forcément crash du système, le risque  c'est surtout un mauvais suivi, paquet orphelin, ou tout simplement un manque de pertinence au cas où une alternative existerait sur les dépots officiels

Mais    
Le seul truc qui m'interpellais sur yaourt c'est:
Utiliser yaourt pour nettoyer le cache, or pour moi les paquets AUR ne vont pas dans /var/cache/pacman/pkg donc je ne comprenais pas l’intérêt comparé à un pacman -Sc.
Mais apparemment, selon cactus, il y a un autre cache de packages (le même ?) géré par yaourt et donc ça aurait du sens.
 
C'est tout
 
Après y a le bon et le mauvais utilisateur de yaourt  

J'avais mal compris la question, alors je rectifie : les paquets AUR compilés par yaourt n'attérissent effectivement pas dans le cache de pacman. Par contre, les paquets des repos traditionnels le sont !

Elbarto : ce n'est pas parce que c'est dangereux que ça doit être banni. C'est aux utilisateurs de mesurer les conséquences. Quand tu utilises yaourt sur AUR, tu as un gros warning rouge. Alors ensuite, si les utilisateurs ne lisent pas...  
Un peu de responsabilité individuelle, bordel !

 
Et bah il apprendra et puis c'est tout
 

 
Yaourt t'avertis quand tu as un paquet orphelin, pour que tu puisses l'adopter. Après c'est pas interdit de s'inscrire sur la ml AUR et parler des problèmes, demander des merges, des disown, toussa et améliorer l'état d'AUR.

 
Je faisais ça sous gentoo (il y a... 9/10 ans :-( ) à l'époque avec mon overlay perso, mais v'là le temps que ça prend  

pour devenir un contributeur du dépôt AUR est-ce qu'il faut montrer "patte blanche" ( sélection rigoureuse des nouveaux membres sur invitation, critères spécifiques etc...) , ou bien n'importe qui peut mettre son paquet en ligne ?

sur le wiki fr ça semble opter pour la seconde réponse

théoriquement ça pourrait permettre à des gens malintentionnés de mettre des pkgbuilds délibérément "infectés" ( téléchargements de sources depuis un site non officiel, j'ai vu le cas pour le paquet fgrun où le téléchargement se faisait non pas sur le git officiel de fgrun mais sur un site de type bitshare/stockage perso de données ),

ça oblige à faire des vérifications, sauf à connaitre personnellement le mainteneur du paquet, d'où peut-être l’intérêt de "valider/certifier" l'utilisateur qui veut déposer quelque chose sur le dépôt aur, un système d'étoiles comme sur ebay/amazon ?

N'importe qui et c'est ce qui fait aussi son interet.
 
Et oui, pas plus tard que hier j'ai modifie un PKGBUILD qui allait chercher les sources ailleurs que sur le site officiel (meme si au final c'etait -tres probablement- le meme paquet puisque j'ai pas eu a modifier le hash).

N'importe qui. J'en ai déjà mis sur AUR sans avoir demandé quoi que ce soit pour autorisation
Une fonctionnalité qui traine depuis pas mal de temps à arriver mais qui est dans les cartons c'est la compilation sandboxée pour makepkg je crois.

sinon il existe la méthode "google" utilisée pour vérifier si la tonne d'applications déposées sur le google market ne sont pas vérolées : un robot qui va à la manière d'un antivirus scanner tout le bordel déposé afin de detecter un eventuel problème,
 
un tel système ( en plus simple ) pourrait être utilisé par les serveurs d'archlinux où se trouvent les pkgbuild de aur, un petit programme qui scannerait les fichiers à la recherche d'élements dangereux ( des sources qui ne pointent pas vers le site officiel mais vers un site douteux comme indiqué plus haut, des lignes de code maladroites type chmod/chown qui violeraient la cohérence du système, recherche de backdoor/cheval de Troie connus qu'un pkgbuild essaierait d'installer en douce etc... )

Complètement impossible en pratique ça.

un algo qui mettrait dans "une warning list" les pkgbuild suspects, puis une équipe de volontaires qui regarderaient en détail le contenu du pkgbuild,
 
un peu comme des modos qui répondraient à un clic de type , ça reste jouable si les vérifications sont quotidiennes, ça n'éliminerait pas 100% des paquets mal conçus mais ça ferait un peu le ménage

Ah oui là sur ce modèle c'est faisable, j'aime l'idée d'ailleurs.
En gros c'est un peu comme aurvote, mais dans l'autre sens

 
 
Je suis un peu newbie linux, et j'ai un soucis que je ne comprends pas et n'arrive pas à régler. Je ne sais pas trop où regarder pour en connaitre l'origine.
 
Contexte : j'ai installé Archlinux il y a quelques jours pour faire un vm windows utilisant le GPU passthrough sur ma machine.
Je suis sur le kernel 3.13-rc8 compilé sur ma machine avec quelques patchs pour corriger des soucis de fuites mémoires avec qemu et d'autres trucs en rapport avec le GPU passthrough, j'utilise gnome3 installé classiquement.
 
Je n'ai aucun soucis particulier sur Arch quand je m'en sers, ni sur ma vm windows quand elle est lancé, tout fonctionne au poil.
 
Le problème que j'ai apparait quand le pc est en idle depuis un petit moment, des fois il reste 1h en idle et je le retrouve exactement comme je l'ai laissé, pas de soucis.
Mais d'autres fois, et ça arrive souvent, je ne m'en sers pas pendant à peine 10 minutes, et quand je reviens je me retrouve sur le screen de login (et non de dévérouillage de session) comme si le pc avait rebooté, et toutes mes applications ont été fermées (notamment la vm quand elle est lancée).
Pourtant, le pc ne reboot pas entre temps (ça m'est arrivé y'a une demi-heure, j'étais à côté en train de faire autre chose, et je ne l'ai pas entendu rebooter (les ventilos soufflent fort au boot), de plus j'avais réduit la vitesse du ventilo du GPU via la vm, et il était encore à la vitesse fixée (mais la vm a été fermée)).
Je ne pense pas que ça soit lié au fait que la vm tourne ou non, car ça n'a jamais crashé quand je m'en servais, même à forte charge, et le problème est aussi arrivé alors que celle-ci n'était pas lancée.
 
Merci d'avance

Salut.
Surement X qui plante.
 
regarde les /var/log/X*
ou ~/.xsession-errors (ou un truc comme ça, je suis pas sur du GNU là)
Sinon, épluche aussi les logs en général et ceux qu noyau avec dmesg

Effectivement :
 
Xorg.0.log.old

Après le Xorg.0.log commence à 2791.506, rien d'anormal à première vue dans celui là.
 
dmesg

 
tu utilises un noyau en release candidate, c'est pas la version stable d'archlinux, possible que ça joue au niveau du bug    
 
essaie de voir si le bug se reproduit avec le paquet linux 3.12.7-2,
 
si tu ne lances pas qemu est-ce que le bug se produit ?
 
par élimination et en consultant les logs tu devrais trouver l’élément qui déclenche le bug

Je crois que les patchs pour que qemu fonctionne correctement avec le passthrough ne fonctionnent pas sur les noyaux <3.13-rc5.
D'où l'utilisation de celui-là.
 
Edit : C'est un problème entre Xorg et le driver Intel 2.99.907 apparemment, d'autres en parlent ici : https://bbs.archlinux.org/viewtopic.php?pid=1371185
https://bugs.archlinux.org/task/38335?opened=4955
https://bugs.freedesktop.org/show_bug.cgi?id=73224
 
Je viens de faire un pacman -Syu, et il y a une maj du driver intel vers le 2.99.907-2.
Apparemment une maj du driver a réglé le soucis pour les personnes l'ayant dans les messages au dessus, màj qu'ils ont faite le 02/01 ou le 03/01 (mais sur les dépôts testing) , et moi j'ai installé le 10/01. Le driver ne devait pas encore être passé sur les dépôts classiques.

Donc tout va bien se finir

J'espère.
 
Je reviendrais poster si le problème continue

Je plussoie le diagnostic, même si j'avoue avoir été surpris de ne pas avoir de bug avec ce nouveau piltote... enfin, je ne vais pas m'en plaindre !!! mais je trouve ça très chelou...

Je ne parviens pas à mettre à jour mon système à cause de GPG.
 

 
Ça c'est avec la commande pacman-key, pour tenter de régler le problème ; en fait j'ai toujours le souci avec libcrypt quelque soit la commande pour la mise à jour.
 
Une idée pour dépanner ?

pourquoi tu veux faire un pacman-key ?

car j'ai installé archlinux fin novembre, je me souviens que je n'avais pas eu besoin d'utiliser pacman-key,

j'ai simplement laissé tout par défaut au niveau de la configuration de pacman, puis un "pacman -Syu",

pour les messages d'erreur tu as quelle version pour le paquet libgcrypt ( la version actuelle est la 1.6.0-2 ) ?

et pour gpg c'est la version 2.0.22-2,

il faut que les versions de gpg et libgcrypt soient les dernières, un pacman -Syu donne quoi ?