[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: fedora 11 worst then ever release



On Mon, Jul 27, 2009 at 1:38 PM, Ralf Corsepius<rc040203 freenet de> wrote:
> On 07/27/2009 11:25 AM, drago01 wrote:
>>
>> On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepius<rc040203 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

What kind of argument is that?
"Your problem for not using a big enough /var partition" ;)

I don't care about the stuff in /tmp across reboots, and this has been
no issue for now.

Well the best way to solve this is default to /var/cache/yum but make
it configureable for people that insists on another location.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]