Shouldn’t EndeavourOS base change exfat-utils package to exfatprogs, since the last uses the native kernel driver for exfat?
exfatprogs is needed if you have to handle exfat partitions on gparted.
Shouldn’t EndeavourOS base change exfat-utils package to exfatprogs, since the last uses the native kernel driver for exfat?
exfatprogs is needed if you have to handle exfat partitions on gparted.
online installs getting it from pacstrap … and you are right… it has the old one… thats bad… i do not know how this come sin there again…
or where you find it?
I used the online installation.
Yes thanks for the hint!
We will fix this as fast as we can, sadly we can not fix this without rebuilding the ISO, but we already work on a solution to be able to fix such issues immediately after detection without having to re-create the ISO.
And i just test to use a exfat partition created with gparted and installing system does not fail also the old package is used…
That kind of response is what makes EndeavourOS thrive! Thank you!
As a temporary workaround, we could add exfatprogs
as a dependency of
eos-bash-shared
. That way users will get exfatprogs
on their current installs.
And this dependency will be removed from eos-bash-shared
after we release the next ISO.
EDIT: did this workaround, please report if it causes any problems!
So I just got this update. What should I do now?
Arch & EndeavourOS update check:
:: Searching Arch & EndeavourOS for updates...
eos-bash-shared 1.9.8-1 -> 1.9.9-1
…
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
:: exfatprogs and exfat-utils are in conflict. Remove exfat-utils? [y/N]
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: exfatprogs and exfat-utils are in conflict
Should I select Remove exfat-utils? [y/N]
(y)es or (N)o?
From what I have seen in this thread, say(Y)es - and you will have exfatprogs instead, without further action required.
Edit: I just did
Yes.
We just noticed that this change causes problems for the ISO installer.
Already installed systems are OK, nothing more to do than normal updates.
So I removed the dependency, and eos-bash-shared is as it was before.
If installs failed today, this can be the reason.
Sorry about this, my bad. And a lesson learned, again.
Hah! I sneaked in in the middle, while the solution was available! I suppose the ISO can’t handle the Replace (Y/n) on the fly?
Anyway - I’m all good
That’s the problem, unfortunately.
So now what we can do is to inform people to change package exfat-utils
to exfatprogs
until the next ISO is released.
And looks like offline install mode is not affected.
Fortunately this is not a big issue. But with exfat partitions it may cause problems.
And also there is support for exfat with exfat-utils package also it is only using a different method.