Alan Schmitt <[EMAIL PROTECTED]> writes: > I wanted to install recent coreutils (in case it might solve some > strange things with latest urpmi have weird option for cp when doing > urpmi.update -a), but to do that I needed to upgrade makedev. When I > urpmi it (or rpm the cache), it gets stuck in the "preparing" stage, > taking 100 % cpu. I tried to strace it, and it seems to be looping: I > get a lot of:
> Am I doing something wrong ? you obviously update from a "< 9.0" release (like 8.2, 8.1, ...). > Should I not try to install makedev ? > Or is this a bug ? the problem come from the way rpm update a package: it stats all files from the package it'll remove (then it un-cpio all files from the new package by appending ";<random_number>" to their name. if all files were smoothly extracted, they're renamed to their normal name (withouth the ";<random>" part). the problem was that, when devfs is used, devfs mounted point "hides" the /dev/ entries from the old dev package, that were stored on the / fs, not on the virtual devfs /dev. when rpm try to stat old files, it makes the kernel communicate with devfsd, the latter being called for each files, trying to loading required modules for /dev/XYZ entry, and the like ... to resolve the conflict between dev+rpm vs devfs' /dev, since mdk9.0, we're replace dev and MAKEDEV with makedev (some kind of "back to the past" design). instead of owning (in the rpmdb meaning) files, the new makedev package dynamically create then when it's installed or updated. so, since mdk9.0, we can dynamically update /dev/ entries on live systems, whether they use devfs or not to nicely handle update from previous releases (eg: 8.x), one has either to do an update from drakx (non live update) or to: - kill devfsd before updating makedev, then restarting it after - do a "mount -t tmpfs none /dev", then updating, then umounting /dev - do "mkdir /root/root; mount --bind / /root/root; mount --bind; /root/root/dev /dev", then update makedev,
