[UDev]... la syntaxe a changé, que faire avant reboot ?

[Cactus]

Bonjour à tous,

Je viens de faire ma MAJ, et udev signale un changement énorme sur la syntaxe.
N'étant pas très doué pour le faire à la main, le risque d'erreur étant flagrant, que faut-il mieux faire ?

Merci pour vos avis...

[wain]

quel est le message ?
Dans le doute, réinstalle la version précédente qui se trouve dans /var/cache/pacman/pkg/udev-*-*.pkg.tar.gz

J'ai pas fait la mise à jour, mais il semble que udev ne pose pas de problème.

[Cactus]

Voici le message :

Code : Tout sélectionner

ATTENTION UDEV:
----------
udev >=098 rules syntax has changed, please update your own rules.
udev >=099 Added persistent network and CD/DVD Symlink generator rules.
Please read the instructions carefully before reboot.
They are located in /etc/udev/readme-udev-arch.txt

Et le readme-udev-arch.txt (enfin, un extrait, car bcp de balbla aussi) :

Code : Tout sélectionner

---------------
* Udev Changes:
---------------
- The syntax of udev rules has been changed in >=098 release, please update your rules.
  --- Snip Changelog Udev 098
  Renaming of some key names:
  BUS -> SUBSYSTEMS
  ID -> KERNELS
  SYSFS -> ATTRS
  DRIVER -> DRIVERS
  ATTR{file}="value" can be used now, to write to a sysfs file of the
  event device. Instead of:
    ..., SYSFS{type}=="0|7|14", RUN+="/bin/sh -c 'echo 60 > /sys$$DEVPATH/timeout'"
  we now can do:
    ..., ATTR{type}=="0|7|14", ATTR{timeout}="60"
  All the PHYSDEV* keys are deprecated and will be removed from a
  future kernel:
    PHYDEVPATH -    is the path of a parent device and should not be
                    needed at all.
    PHYSDEVBUS -    is just a SUBSYSTEM value of a parent, and can be
                    matched with SUBSYSTEMS==
    PHYSDEVDRIVER - for bus devices it is available as ENV{DRIVER}.
                    Newer kernels will have DRIVER in the environment,
                    for older kernels udev puts in. Class device will
                    no longer carry this property of a parent and
                    DRIVERS== can be used to match such a parent value.
  Note that ENV{DRIVER} is only available for a few bus devices, where
  the driver is already bound at device event time. On coldplug, the
  events for a lot devices are already bound to a driver, and they will have
  that value set. But on hotplug, at the time the kernel creates the device,
  it can't know what driver may claim the device after that, therefore
  in most cases it will be empty.
  --- snap Changelog Udev 098
- optional udev >= 099 Persistent rules generator for network and cd/dvd devices was added.

Alors, ton avis, Wain ? (ou les autres )

[_alexmyself]

j'ai eu aucun problème,
a mon avis si t'as pas crée toi même des règles udev ça craint pas

[warnaud]

Ouais pareil, pas de problèmes (à part revenir en 2.6.17-emission pour d'autres problèmes).

[Cactus]

bah si, j'en ai créé pour qq périph usb et ma carte réseau je crois (ça fait loin, trou de mémoire).
Mais si je n'ai que ça à corriger, je devrais m'en sortir...
Je n'ai pas envie de rebooter ce soir, on verra demain si ça redémarre...

Par contre, il y a plein de fichiers .rules dans le répertoire, les anciens et le nouveau (udev.rules avec la nouvelle syntaxe). Ca risque pas de merder ?

Merci à vous 2...

[Cactus]

Bon, j'ai redémarré...
La règle udev semble marche pour ma clé usb, donc probablement pour le reste... EDIT : ça marche aussi pour camescope (=APN).
NB : j'ai évidemment édité mes règles perso... enfin, j'ai ouvert (et modifié si nécessaire) chaque ficher .rules.

[MSeb]

Que risque t-on d'upgrader udev, et de rester avec un noyau plus ancien ?
Je tourne avec le 2.6.16

Argumentez !
Je reprends les copies dans deux heures

[chipster]

Que risque t-on d'upgrader udev, et de rester avec un noyau plus ancien ?
Je tourne avec le 2.6.16

Argumentez !
Je reprends les copies dans deux heures

Si il y a un problème tu risques tout simplement de ne plus pouvoir rebooter ta machine

[MSeb]

c'est bien ce que je pensais.

donc j'ai le choix entre un kernel qui bouffe mon cpu, ou un système hs, ou un système que je n'upgrade plus

[wain]

Que risque t-on d'upgrader udev, et de rester avec un noyau plus ancien ?
Je tourne avec le 2.6.16

Argumentez !
Je reprends les copies dans deux heures

Aucun soucis. Chez moi les maj d'udev sont bloquées depuis un moment, et ça m'empêche pas d'utiliser les dernières versions des kernels beyond et emission

[chipster]

c'est bien ce que je pensais.

donc j'ai le choix entre un kernel qui bouffe mon cpu, ou un système hs, ou un système que je n'upgrade plus

S'il mange ton cpu, installe powernowd, fait un modprobe cpufreq-userspace et powernow-k8 (pour les x64) et ensuite lances le daemon et tu consommeras beaucoup moins

[MSeb]

Merci Chipster pour ton astuce.

Je viens d'installer le dernier udev avec mon noyau perso 2.6.16.28

Tout se passe bien !

Le kernel 2.6.18 est un vraie catastrophe pour moi, avec un cpu qui tourne seuleument à 80% idle alors que rien n'est lancé

A l'occasion je m'en ferai un maison avec patch ck;

[Cactus]

Pas de soucis conso CPU en 2.6.18 pour moi...