I've had the following problems on a fresh install of FC6T1:
1) The graphical installer barfs on my LVM/XFS root partition (manually formatted via rescue mode before running the installer) - the volume is 300G, and the graphical installer insists that the volume is larger than it is supposed to be at 256GiB. The partition *is* correctly sized, and the text mode installer has no problems with this.
2) Trying to run an update is NEEDLESSLY PAINFUL - can we either a) make YUM deal with conflicts in a more intelligent fashion that "Conflict-DIE!", b) fix it so the damn repositories DON'T HAVE CONFLICTS, or c) drop-kick YUM and use something better like APT for RPM?
3) After updating, when I reboot, the system fails to fsck my XFS partitions, claiming there is a "permission denied" error running fsck.xfs. However, when I am then dropped into the recovery shell, I can execute this command without problems, and I see no differences between /sbin/fsck.xfs and any of the other fsck.* programs (i.e. ls -laZ shows no obvious differences). I worked around this by adding a "noxfs" to the fsck parameters in rc.sysinit - and this might not be a bad idea anyway, seeing as how fsck.xfs is a no-op anyway.
4) I don't know if this is a Wine error or a Fedora/SELinux error, but - I pulled down the latest wine CVS (28 July 2006), and installed it to /usr/bin/wine/* (e.g. the main executable is /usr/bin/wine/wine) (so that when I want to wipe all the wine binaries for a new clean install I can do so easily) (and I am not installing from RPM as a) I want the latest Wine and b) I occasionally do a bit of Wine hacking). I relabled all the /usr/bin/wine/* and /usr/lib/wine/*so files (e.g. -rwxr-xr-x root root system_u:object_r:wine_exec_t /usr/bin/wine/wine -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/wine/activeds.dll.so ) but I still get a "wine_main_preload_info not found" from wine when it starts. The Wine source leads me to believe this is because Wine is not able to load the wine-preloader. I've check to see if I have any audit denies and I am not seeing any in the system logs.
David D. Hagood wrote:
- Trying to run an update is NEEDLESSLY PAINFUL - can we either a)
make YUM deal with conflicts in a more intelligent fashion that "Conflict-DIE!", b) fix it so the damn repositories DON'T HAVE CONFLICTS, or c) drop-kick YUM and use something better like APT for RPM?
when does it die? before the transaction starts or after starting the update? 2nd may result into a broken system... also anaconda should ignore conflicts and just go on, just logs them to a file so that the admin/user can deal with them after the update is completed.
dragoran wrote:
David D. Hagood wrote:
- Trying to run an update is NEEDLESSLY PAINFUL - can we either a)
make YUM deal with conflicts in a more intelligent fashion that "Conflict-DIE!",
when does it die? before the transaction starts or after starting the update?
By "DIE" I mean "Let's take several minutes downloading headers, resolving dependencies, downloading more headers, etc. and then decide that since there are conflicts due to some subset of the packages, throw all that work away rather than simply removing the offending packages from the transaction set until we have a consistent transaction set and doing the install of whatever will work."
On Sat, 2006-07-29 at 12:58 -0500, David D. Hagood wrote:
dragoran wrote:
David D. Hagood wrote:
- Trying to run an update is NEEDLESSLY PAINFUL - can we either a)
make YUM deal with conflicts in a more intelligent fashion that "Conflict-DIE!",
when does it die? before the transaction starts or after starting the update?
By "DIE" I mean "Let's take several minutes downloading headers, resolving dependencies, downloading more headers, etc. and then decide that since there are conflicts due to some subset of the packages, throw all that work away rather than simply removing the offending packages from the transaction set until we have a consistent transaction set and doing the install of whatever will work."
Try the first script at the bottom of the page here:
http://fedoraproject.org/wiki/Tools/yum
On Sat, Jul 29, 2006 at 12:58:08PM -0500, David D. Hagood wrote:
... and then decide that since there are conflicts due to some subset of the packages, throw all that work away
Change 'keepcache=0' in your /etc/yum.conf to 'keepcache=1' and that, at least, will not remove all what you retrieved so far. This will give you what is described as a default in 'man yum.conf'. Dumping caches at the slightest provocation is trully maddenning when your connection is somewhat worse than T1. OTOH then you have to make sure yourself that these caches will not grow too big over time.
rather than simply removing the offending packages from the transaction set until we have a consistent transaction set and doing the install of whatever will work."
It seems that yum indeed has enough information to behave in such way, or at least to have an option to turn on such behaviour. Unfortunately it is not doing this. Still there are scripts which allow to achieve that goal and location of some of these was mentioned on this list a number of times. Basically you try to update possible candidates one by one instead of all of them at the same time. 'keepcache=1' is actually helpful here.
Michal
David D. Hagood wrote:
I've had the following problems on a fresh install of FC6T1:
- The graphical installer barfs on my LVM/XFS root partition
(manually formatted via rescue mode before running the installer) - the volume is 300G, and the graphical installer insists that the volume is larger than it is supposed to be at 256GiB. The partition *is* correctly sized, and the text mode installer has no problems with this.
fill a bug
- After updating, when I reboot, the system fails to fsck my XFS
partitions, claiming there is a "permission denied" error running fsck.xfs. However, when I am then dropped into the recovery shell, I can execute this command without problems, and I see no differences between /sbin/fsck.xfs and any of the other fsck.* programs (i.e. ls -laZ shows no obvious differences). I worked around this by adding a "noxfs" to the fsck parameters in rc.sysinit - and this might not be a bad idea anyway, seeing as how fsck.xfs is a no-op anyway.
any selinux avc's ?
-
David Hagood -
dragoran -
Michal Jaegermann -
Stanton Finley