fedora 11 worst then ever release

Ralf Corsepius rc040203 at freenet.de
Mon Jul 27 11:38:09 UTC 2009


On 07/27/2009 11:25 AM, drago01 wrote:
> On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepius<rc040203 at freenet.de>  wrote:
>> On 07/26/2009 09:28 PM, Björn Persson wrote:
>>>
>>> Ralf Corsepius wrote:
>>>>
>>>> On 07/26/2009 02:37 PM, Seth Vidal wrote:
>>>>>
>>>>> On Sat, 25 Jul 2009, Alan Cox wrote:
>>>>>>
>>>>>> "all of my system has a wrong openssl version"
>>>>>>
>>>>>> all these symptoms sound like your upgrade went horribly wrong. I've
>>>>>> seen preupgrade mash up a box by half upgrading like that. It's the
>>>>>> main
>>>>>> reason
>>>>>> I don't think preupgrade is actually safe to use yet.
>>>>>
>>>>> Preupgrade's process is to depsolve - using the same method anaconda
>>>>> does, download the pkgs it solves out. Put them in a cachedir. Download
>>>>> a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
>>>>> allow anaconda to do the install.
>>>>>
>>>>> Specific issues we've had with preupgrade are related to not being able
>>>>> to find a mirror and/or not being able to get pkgs.
>>>>
>>>> Mine were
>>>> * preupgrade running out of diskspace on / when trying to fill
>>>> /var/cache/yum (my "/"'s tend to be minimized/small)
>>>
>>> You're not blaming Preupgrade for the partition being too small, are you?
>>
>> Well, to some extend, I am blaming it, because
>> a) filling '/' may easily kill a system and may easily cause further damage
>> (processes running in parallel to preupgrade might be malfunctioning due
>> lack of diskspace).
>>
>> b) I expect an installer to be able to check whether sufficient space is
>> available in advance, rsp. not to leave a system in an unusable state in
>> case of something going wrong.
>>
>> In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183
>> I questioned whether using /var/cache/yum is a good choice for preupgrade's
>> package cache. Though I meanwhile know that this BZ is was a side-effect of
>> the nfs-parser bugs in anaconda, I still think using /root or /tmp would be
>> better choices.
>
> No, some people (me included) use tmpfs for /tmp , so this would
> result into reboot, no packages found (if it did not hit a space
> problem either).
Your problem, if you are using a non-reboot persistant /tmp

On my machines, various subdirs of /var are nfs mounted and spread 
across a network.

> /root is not supposed to be used by random apps.
This is not a random app permanently using a filesystem.

It is the user "root" running an application to set up a personal 
temporary filesystem to be used exclusively by him.

Ralf





More information about the devel mailing list