Bug #3158
hwdata: /usr/share/hwdata/pci.ids exists in filesystem (owned by hwids)
0%
Description
After pacman -Syu:
your-freedom-20220114-1-any 18.4 KiB 24.2 KiB/s 00:01 [##########################################] 100%
zcash-4.6.0_1-1-x86_64 5.7 MiB 295 KiB/s 00:20 [##########################################] 100%
zeitgeist-1.0.3+3+g702fdbac-3-x86_64 382.5 KiB 327 KiB/s 00:01 [##########################################] 100%
zenity-3.41.0-1-x86_64 3.0 MiB 257 KiB/s 00:12 [##########################################] 100%
Total (107/107) 716.6 MiB 385 KiB/s 31:47 [##########################################] 100%
(695/695) checking keys in keyring [##########################################] 100%
(695/695) checking package integrity [##########################################] 100%
(695/695) loading package files [##########################################] 100%
(695/695) checking for file conflicts [##########################################] 100%
error: failed to commit transaction (conflicting files)
hwdata: /usr/share/hwdata/pci.ids exists in filesystem (owned by hwids)
hwdata: /usr/share/hwdata/pnp.ids exists in filesystem (owned by hwids)
hwdata: /usr/share/hwdata/usb.ids exists in filesystem (owned by hwids)
Errors occurred, no packages were upgraded.
History
Updated by maddox about 2 years ago
I have resolved this by installing hwdata package and by using --override flag. But it should not be that way.
Updated by bill-auger about 2 years ago
- Status changed from unconfirmed to not-a-bug
this bug was fixed recently #3157 - pacman -Syu should be clear for everyone today
Updated by maddox about 2 years ago
I don't see how it is fixed. I did pacman -Syu and that appeared. So what is the practical solution from the fixed bug? I cannot see any solution on #3157
Updated by maddox about 2 years ago
What to do to resolve this?
$ sudo pacman -Syu
:: Synchronizing package databases...
libre is up to date
core is up to date
extra is up to date
community is up to date
pcr is up to date
:: Starting full system upgrade...
warning: base: local (2-2.parabola1.nonsystemd2) is newer than libre (2-2.parabola1)
:: Replace hwids with core/hwdata? [Y/n]
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing hwids breaks dependency 'hwids' required by eudev
Updated by bill-auger about 2 years ago
your system is probably in an inconsistent state - you have nonsystemd/base installed; but you do not have the nonsystemd repo enabled - systemd and nonsystemd can not be mixed - you must decide and choose (potentially edit pacman.conf), then re-sync the system - if you want to use openrc, then enable the [nonsystemd] repo - if you are using openrc now, then normally it should be enabled already; but it is not by default perhaps?
whichever init-system you want, you must run this command (after configuring pacman.conf appropriately), to restore sanity to your system:
# pacman -Syyuu
one can expect more similar problems, generally for pacman's "local * is newer than" warnings, until they are resolved - un-maintained 'local' packages are as problematic (or moreso) as the more familiar "partial-upgrade" states
if parabpla has upgrades for any 'local' packages, one should rebuild/upgrade the local version, for whatever reason it appears as 'local' initially - for maximum robustness, it should be done whenever any dependency is upgraded, even if 'pkgver' has not unchanged
the above is good wiki food
Updated by maddox about 2 years ago
I have enabled nonsystemd repository in /etc/pacman.conf -- though I consider that bug itself as I have never seen that nonsystemd was enabled since I have installed Parabola with OpenRC.
The expectation was that /etc/pacman.conf was configured correctly by default. Though it seems it was probably not so.
I have now "upgraded" the system with nonsystemd packages by using:
sudo pacman -Syyuu --overwrite /usr/bin/sysusers --overwrite /usr/lib/sysusers.d/basic.conf --overwrite /usr/bin/tmpfiles --overwrite /etc/init.d/dbus --overwrite /etc/runlevels/default/dbus --overwrite /usr/local/share/man
I can just guess that my dbus applications will now work well without me doing dbus-launch, as it never worked in the first place.
And I am assuming that new OpenRC installation has the nonsystemd enabled, as I reiterate, I did not have it enabled since the original installation from ISO.
Updated by bill-auger about 2 years ago
IIRC there is an open bug report about that on the "installation media" tracker; and i wrote some of the needed code
Updated by bill-auger about 2 years ago
please stop using `--overwrite` workarounds; or at least refrain from publishing such danger-ish executable code snippets, as an acceptable solution for readers of the bug tracker to find and try - those snippets are rarely useful advice generally (to all parabola users), or long-term; but can trash any system beyond repair, with unpredictable results if run on another day, or on another out-dated or custom parabola system - the advice is short-lived/narrow-use-case and is best excluded from preservation for posterity
--overwrite workarounds are very naughty and/or indicate a severely broken system - they should not be used as a general fix for all "exists in filesystem" errors - doing so, makes those errors useless, and likely may break your system someday - i tend to delete <code>bad or uncommon/dubious/danger-ish advice</code>, as readily as i would to non-free ads, social kindness infractions, etc - this is why i mention it at all - do not be alarmed :)
the '--overwrite' option is used wisely in cases of a known bug requiring manual intervention, or otherwise usually cases of the user repairing own bugs/litter (while mucking around tracked system files, or if holding packages, for example)
the '--overwrite' option can prevent the system, WM/DE, etc from starting - it is not for normal use (like a fresh install or LiveISO) - when one of my systems has corrupted package DB, sigs, binaries, whatever so messed up, my first thought is to clobber the partition with a fresh OS install - post-natal pacstrap should be necessary, only in extreme distro-torture/distro-doctor cases - either are often easier/faster than solving whatever crazy state the system has gotten into, which would require such a vulgar repair on a relatively pristine system
Updated by maddox about 2 years ago
Was there any other solution? As I mentioned, OpenRC version of Parabola was in first place like that. Then when doing pacman -Syu I have to face that system is not upgradeable as there was conflict for hwids.
I wish I would not use --overwrite, but I have not found any better solution to the problem.
Updated by bill-auger about 2 years ago
comment # 5 is the solution - two convergent/divergent solutions, in fact - its the one with multiple "you must" admonitions - i do not offer use those glibly - parabola has very few such hard constraints, which would require similar warnings or words like "must" - this is one hard constraint:
- IFF systemd systems:
`pacman -Sy` would normally never show the term 'nonsystemd' to any user
`pacman -Syyuu` should NOT show the term 'nonsystemd' in any form, place, or time
- IFF openrc systems:
`pacman -Sy` would normally show: 'nonsystemd is up to date'
`pacman -Syyuu` should show 'nonsystemd' downloading to 100%
`pacman -S` would normally not install any package, with systemd (sans the non-prefix) in the name
- a supported parabola system must satisfy one of the previous two sets of constraints
no other parabola systems "alternate/hybrid/blend/whatever" are supported
one consequence of this, is that openrc + systemd can not co-exist in the standard way, nor used with known/reproducible confidence, although the upstream softwares all allow it - but in practice, expert users can co-habitualize even that rare combination, rather easily (with no assistence) - the OP's rogue (androgenous?) system is tennable - ive run parabola that way for months; but people should not open bug reports for such unsupported configurations