Cauldron won't update: Installation failed: rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-2.1.9-18.mga3.x86_64 There are over a dozen other pkgs that won't update as the require filesystem >= 2.1.9-18 rpmlib is not a known package. **Manual attempts also fail as follows: # rpm -ef --nodeps filesystem-2.1.9-17.mga2 # rpm -if --nodeps filesystem-2.1.9-18.mga3.x86_64.rpm error: unpacking of archive failed on file /bin: cpio: rename failed - Is a directory error: filesystem-2.1.9-18.mga3.x86_64: install failed 2.1.9-17 was removed to prevent conflict above.
Severity: normal => major
CC: (none) => digigold808
CC: (none) => notecx
Have you followed the UsrMove procedures? (They were announced in the dev ML.) https://wiki.mageia.org/en/Feature:UsrMove#Release_Notes
(In reply to comment #1) > Have you followed the UsrMove procedures? > (They were announced in the dev ML.) exactly, as all major change like this one are annouced, you should subscriber to the mailing (for at least the ANNOUCE/ANN/etc thread)
Status: NEW => RESOLVEDResolution: (none) => INVALID
CC: (none) => kristoffer.grundstrom1983
Let's see whether I can assign a closed report to coling :-) I have this problem on the 2nd system I performed the usrmove on (taking the same steps as on the 1st system). Everything seems to have gone well, except for not being able to update and getting this: Installation failed: rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-2.1.9-18.mga3.i586 [marja@localhost /]$ ls -l total 240 lrwxrwxrwx 1 root root 7 Aug 6 19:27 bin -> usr/bin/ drwxr-xr-x 4 root root 4096 Aug 6 20:09 boot/ drwxr-xr-x 22 root root 4096 Jul 1 18:45 CauldronLXDE/ -rw------- 1 root root 166565 Aug 5 15:01 dead.letter drwxr-xr-x 19 root root 3980 Aug 6 20:09 dev/ drwxr-xr-x 122 root root 12288 Aug 6 20:44 etc/ drwxr-xr-x 6 root root 4096 Mar 13 11:59 home/ drwxr-xr-x 2 root root 4096 Mar 13 11:59 initrd/ lrwxrwxrwx 1 root root 7 Aug 6 19:27 lib -> usr/lib/ drwx------ 2 root root 16384 May 12 15:28 lost+found/ drwxr-xr-x 2 root root 4096 Jun 14 20:52 media/ drwxr-xr-x 2 root root 4096 Mar 13 11:59 mnt/ drwxr-xr-x 2 root root 4096 Mar 13 11:59 opt/ dr-xr-xr-x 153 root root 0 Aug 6 20:08 proc/ drwxr-x--- 12 root root 4096 Aug 6 20:48 root/ drwxr-xr-x 17 root root 620 Aug 6 21:01 run/ lrwxrwxrwx 1 root root 8 Aug 6 19:27 sbin -> usr/sbin/ drwxr-xr-x 2 root root 4096 Mar 13 11:59 srv/ dr-xr-xr-x 12 root root 0 Aug 6 20:09 sys/ drwxrwxrwt 18 root root 440 Aug 6 20:57 tmp/ drwxr-xr-x 13 root root 4096 Aug 6 19:27 usr/ drwxr-xr-x 17 root root 4096 Aug 6 19:27 var/ [marja@localhost /]$
CC: (none) => marja11Assignee: bugsquad => mageia
Reopening, I did an extra reboot right after rpm -a zapata (probably because a newer kernel was installed), but don't see how that can have caused the update problem /root/.bash_history : urpmi --auto-update --skip '/filesystem|ncurses/' urpmi --auto-select urpmi dracut rpm -e zapata reboot dracut -f -a convertfs reboot urpmi --auto-select urpmi --auto-update 2>&1 | tee Updates/201208061930 dracut -f I tried auto-update because auto-select failed, but auto-update failed just as hard.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
you have make dracut -f -a convertfs on the kernel you are using ?
(In reply to comment #5) > you have make dracut -f -a convertfs on the kernel you are using ? Yes, I couldn't install a newer kernel since (and that shouldn't make a difference, once the conversion is done, anyway). In case you mean: did you include the conversion script in the initrd for the correct kernel, then the answer is "yes" too. The conversion was successful, you can see above that /bin /lib and /sbin are links now, if I had included it in the initrd for the wrong kernel there wouldn't have been a conversion. Right after the conversion, so while 100% sure still using the same kernel, I already had the error when trying to update
(In reply to comment #3) > Let's see whether I can assign a closed report to coling :-) > > I have this problem on the 2nd system I performed the usrmove on (taking the > same steps as on the 1st system). Everything seems to have gone well, except > for not being able to update and getting this: > > Installation failed: rpmlib(X-CheckUnifiedSystemdir) is needed by > filesystem-2.1.9-18.mga3.i586 What is the version of your rpm package?
CC: (none) => sander.lepik
(In reply to comment #7) > > What is the version of your rpm package? rpm-4.10.0-2.mga3
Last weekend I did something unusual, though, I "upgraded" this cauldron with boot-nonfree.iso, because I needed to check our test drakx-installer-help files. https://bugs.mageia.org/show_bug.cgi?id=5086#c24
(In reply to comment #8) > (In reply to comment #7) > > > > > What is the version of your rpm package? > > rpm-4.10.0-2.mga3 Hmm, that's weird. Latest seems to be rpm-4.10.0-10.mga3. Filesystem check was added in 5th release, so you should first update your rpm. No idea why it was not updated by urpmi. Are your mirrors up-to-date?
This is a known issue and has been discussed a bit on the list. The problem is that to install the latest rpm package, it somehow pulls in the new filesystem rpm (likely due to a perl dep) and as such it hits a cyclical loop. The same issue affects an upgrade from mga2 (sans updated rpm from updates/testing) to cauldron. This is on the infinite todo list. Likely just a matter of relaxing a require somewhere or other but it's easily the kind of thing that could pop up again. How to resolve this properly really depends on how we'll end up supporting upgrades - e.g. if we insist that your Mga(n-x) install is fully up-to-date first then this won't be an issue and it becomes a cauldron-only issue which is easily ignored :p In order to update, assuming you can manually verify the conversion is OK (check symlinks in /{bin,sbin,lib,lib64} and /var/{run,lock}) then just download and manually install the latest filesystem rpm with --nodeps. Ugly but it's safe enough (assuming you really did do the conversion and the checks first!)
(In reply to comment #11) > In order to update, assuming you can manually verify the conversion is OK > (check symlinks in /{bin,sbin,lib,lib64} and /var/{run,lock}) then just > download and manually install the latest filesystem rpm with --nodeps. Ugly but > it's safe enough (assuming you really did do the conversion and the checks > first!) Thx, Colin :-D That did the trick, although I had to use --allow-nodeps ;)
fixed for a log date
Status: REOPENED => RESOLVEDResolution: (none) => FIXEDSource RPM: (none) => rpm