Project

General

Profile

Bug #3158

hwdata: /usr/share/hwdata/pci.ids exists in filesystem (owned by hwids)

maddox - about 2 years ago - . Updated about 2 years ago.

Status:
not-a-bug
Priority:
bug
Assignee:
-
% Done:

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

#1

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.

#2

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

#3

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

#4

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

#5

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

#6

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.

#7

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

#8

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

#9

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.

#10

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

Also available in: Atom PDF