4:35 p.m.
Hi,
I'm thinking about upgrade of my devel (php, python2, python3,
postgres, mysql, firebird, cherokee, apache, git, some xorg related
libs etc) system from F13 to F14Beta+. I've seen recently some bug
reports about serious bugs associated with glibc, gcc, kernel. Do
these problems has been eliminated? Are there any known serious
outstanding issues?
Regards,
Michal
4:58 p.m.
On Sun, Oct 03, 2010 at 23:35:20 +0200,
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
Hi,
I'm thinking about upgrade of my devel (php, python2, python3,
postgres, mysql, firebird, cherokee, apache, git, some xorg related
libs etc) system from F13 to F14Beta+. I've seen recently some bug
reports about serious bugs associated with glibc, gcc, kernel. Do
these problems has been eliminated? Are there any known serious
outstanding issues?
I believe that the gcc and glibc stuff is fixed, at least with testing
enabled. I am not sure which kernel problem you are referring to. There
was some recent security updates that affected pretty much all versions.
I haven't run into any f14 specific problems recently.
5:16 p.m.
W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
<bruno(a)wolff.to> napisał:
On Sun, Oct 03, 2010 at 23:35:20 +0200,
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
> Hi,
>
> I'm thinking about upgrade of my devel (php, python2, python3,
> postgres, mysql, firebird, cherokee, apache, git, some xorg related
> libs etc) system from F13 to F14Beta+. I've seen recently some bug
> reports about serious bugs associated with glibc, gcc, kernel. Do
> these problems has been eliminated? Are there any known serious
> outstanding issues?
I believe that the gcc and glibc stuff is fixed, at least with testing
enabled.
How should I use testing with preupgrade? Is it enough that I turn on
this repo by default in /etc/yum.repos.d/fedora-updates-testing.repo ?
I am not sure which kernel problem you are referring to.
There were some problems with system boot after upgrade - I'm not
quite sure whether it was specifically kernel or glibc problem.
There
was some recent security updates that affected pretty much all versions.
I haven't run into any f14 specific problems recently.
Good to know. I'll try to update system. I will let know if there are
any problems
Regards,
Michal
6:58 p.m.
On Mon, Oct 04, 2010 at 00:16:18 +0200,
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
How should I use testing with preupgrade? Is it enough that I turn on
this repo by default in /etc/yum.repos.d/fedora-updates-testing.repo ?
Upgrade first and then enable afterwards. I usually edit
/etc/yum.repos.d/fedora-updates-testing.repo and set enabled=1 .
There's a way todo it from a GUI as well.
There were some problems with system boot after upgrade - I'm
not
quite sure whether it was specifically kernel or glibc problem.
The glibc issue caused problemswith booting. So that's probably what you were
thinking of.
6:10 a.m.
W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com> napisał:
W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
<bruno(a)wolff.to> napisał:
> There
> was some recent security updates that affected pretty much all versions.
> I haven't run into any f14 specific problems recently.
>
Good to know. I'll try to update system. I will let know if there are
any problems
I noticed a problem with preupgrade-cli. I rebooted system, preupgrade
updated it, but then the system does not respond to ping - I turned
off it by pressing power button. I connected box to the TV to see what
happens, but the system started correctly. Strange. Do physical access
to the machine is required when using preupgrade?
Apart from that it seems that everything went well.
Regards,
Michal
8:04 a.m.
On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote:
W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com> napisał:
> W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
> <bruno(a)wolff.to> napisał:
>> There
>> was some recent security updates that affected pretty much all versions.
>> I haven't run into any f14 specific problems recently.
>>
>
> Good to know. I'll try to update system. I will let know if there are
> any problems
I noticed a problem with preupgrade-cli. I rebooted system, preupgrade
updated it, but then the system does not respond to ping - I turned
off it by pressing power button. I connected box to the TV to see what
happens, but the system started correctly. Strange. Do physical access
to the machine is required when using preupgrade?
Apart from that it seems that everything went well.
Should not be required, but hard to say without more details. I suspect
it the installer stopped and was prompting you for some information
(perhaps language or keymap)? Do you have access to the installer logs
from the preupgrade attempt?
Alternatively, as Bruno points out, you may have been a victim of the
glibc issue.
Thanks,
James
8:28 a.m.
2010/10/4 James Laska <jlaska(a)redhat.com>:
On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote:
> W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
> <mkkp4x4(a)gmail.com> napisał:
> > W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
> > <bruno(a)wolff.to> napisał:
> >> There
> >> was some recent security updates that affected pretty much all versions.
> >> I haven't run into any f14 specific problems recently.
> >>
> >
> > Good to know. I'll try to update system. I will let know if there are
> > any problems
>
> I noticed a problem with preupgrade-cli. I rebooted system, preupgrade
> updated it, but then the system does not respond to ping - I turned
> off it by pressing power button. I connected box to the TV to see what
> happens, but the system started correctly. Strange. Do physical access
> to the machine is required when using preupgrade?
>
> Apart from that it seems that everything went well.
Should not be required, but hard to say without more details. I suspect
it the installer stopped and was prompting you for some information
(perhaps language or keymap)? Do you have access to the installer logs
from the preupgrade attempt?
Yes, I've got some logs from installation. I can post it - it's about 226 kb.
Alternatively, as Bruno points out, you may have been a victim of the
glibc issue.
Hmmm, but system booted fine later.
Thanks,
James
Regards,
Michal
9:03 a.m.
On Mon, 2010-10-04 at 15:28 +0200, Michał Piotrowski wrote:
2010/10/4 James Laska <jlaska(a)redhat.com>:
> On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote:
>> W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
>> <mkkp4x4(a)gmail.com> napisał:
>> > W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
>> > <bruno(a)wolff.to> napisał:
>> >> There
>> >> was some recent security updates that affected pretty much all
versions.
>> >> I haven't run into any f14 specific problems recently.
>> >>
>> >
>> > Good to know. I'll try to update system. I will let know if there are
>> > any problems
>>
>> I noticed a problem with preupgrade-cli. I rebooted system, preupgrade
>> updated it, but then the system does not respond to ping - I turned
>> off it by pressing power button. I connected box to the TV to see what
>> happens, but the system started correctly. Strange. Do physical access
>> to the machine is required when using preupgrade?
>>
>> Apart from that it seems that everything went well.
>
> Should not be required, but hard to say without more details. I suspect
> it the installer stopped and was prompting you for some information
> (perhaps language or keymap)? Do you have access to the installer logs
> from the preupgrade attempt?
Yes, I've got some logs from installation. I can post it - it's about 226 kb.
I wouldn't mind seeing the logs (fpaste.org). Can you
paste /root/upgrade.log, /root/install.log and /var/log/anaconda.log?
> Alternatively, as Bruno points out, you may have been a victim
of the
> glibc issue.
Hmmm, but system booted fine later.
Did the install ever complete? Or did you force reboot it before it
ever started/completed? When preupgrade reboots into the installer, it
sets up a boot-next grub target which will boot into the installer
*only* for the next reboot. If you reboot multiple times before
starting the installer, it will boot back into your previously defined
default boot target.
Thanks,
James
9:26 a.m.
2010/10/4 James Laska <jlaska(a)redhat.com>:
On Mon, 2010-10-04 at 15:28 +0200, Michał Piotrowski wrote:
> 2010/10/4 James Laska <jlaska(a)redhat.com>:
> > On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote:
> >> W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
> >> <mkkp4x4(a)gmail.com> napisał:
> >> > W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
> >> > <bruno(a)wolff.to> napisał:
> >> >> There
> >> >> was some recent security updates that affected pretty much all
versions.
> >> >> I haven't run into any f14 specific problems recently.
> >> >>
> >> >
> >> > Good to know. I'll try to update system. I will let know if there
are
> >> > any problems
> >>
> >> I noticed a problem with preupgrade-cli. I rebooted system, preupgrade
> >> updated it, but then the system does not respond to ping - I turned
> >> off it by pressing power button. I connected box to the TV to see what
> >> happens, but the system started correctly. Strange. Do physical access
> >> to the machine is required when using preupgrade?
> >>
> >> Apart from that it seems that everything went well.
> >
> > Should not be required, but hard to say without more details. I suspect
> > it the installer stopped and was prompting you for some information
> > (perhaps language or keymap)? Do you have access to the installer logs
> > from the preupgrade attempt?
>
> Yes, I've got some logs from installation. I can post it - it's about 226
kb.
I wouldn't mind seeing the logs (fpaste.org). Can you
paste /root/upgrade.log, /root/install.log and /var/log/anaconda.log?
anaconda.log
http://fpaste.org/FFnR/
anaconda.program
http://fpaste.org/jNYH/
anaconda.storage
http://fpaste.org/u5mA/
anaconda.syslog
http://fpaste.org/AqTK/
anaconda.xlog
http://fpaste.org/gWwP/
anaconda.yum
http://fpaste.org/CqmZ/
upgrade.log
http://fpaste.org/Lzn4/
upgrade.log.syslog
http://fpaste.org/2KtM/
That's all I have - I deleted install.log one and a half years ago.
Did the install ever complete?
I don't know - this box is not attached to any display - I was not
able to verify it.
According to this
http://fpaste.org/Lzn4/
packages was installed.
Or did you force reboot it before it
ever started/completed?
I ran preupgrade - it downloaded all packages, then I reboot system. I
waited for almost two hours before I turned off it manually. System at
that time did not respond to ping.
When preupgrade reboots into the installer, it
sets up a boot-next grub target which will boot into the installer
*only* for the next reboot. If you reboot multiple times before
starting the installer, it will boot back into your previously defined
default boot target.
It seems to me that the system is properly upgraded.
Thanks,
James
Regards,
Michal
9:59 a.m.
Thanks for posting your logs. See comments below.
On Mon, 2010-10-04 at 16:26 +0200, Michał Piotrowski wrote:
2010/10/4 James Laska <jlaska(a)redhat.com>:
> On Mon, 2010-10-04 at 15:28 +0200, Michał Piotrowski wrote:
>> 2010/10/4 James Laska <jlaska(a)redhat.com>:
>> > On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote:
>> >> W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
>> >> <mkkp4x4(a)gmail.com> napisał:
>> >> > W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
>> >> > <bruno(a)wolff.to> napisał:
>> >> >> There
>> >> >> was some recent security updates that affected pretty much all
versions.
>> >> >> I haven't run into any f14 specific problems recently.
>> >> >>
>> >> >
>> >> > Good to know. I'll try to update system. I will let know if
there are
>> >> > any problems
>> >>
>> >> I noticed a problem with preupgrade-cli. I rebooted system, preupgrade
>> >> updated it, but then the system does not respond to ping - I turned
>> >> off it by pressing power button. I connected box to the TV to see what
>> >> happens, but the system started correctly. Strange. Do physical access
>> >> to the machine is required when using preupgrade?
>> >>
>> >> Apart from that it seems that everything went well.
>> >
>> > Should not be required, but hard to say without more details. I suspect
>> > it the installer stopped and was prompting you for some information
>> > (perhaps language or keymap)? Do you have access to the installer logs
>> > from the preupgrade attempt?
>>
>> Yes, I've got some logs from installation. I can post it - it's about
226 kb.
>
> I wouldn't mind seeing the logs (fpaste.org). Can you
> paste /root/upgrade.log, /root/install.log and /var/log/anaconda.log?
anaconda.log
http://fpaste.org/FFnR/
Nice, this shows that it appears to have booted and completed a
preupgrade install.
Specifically, you can see it starts the installer with what appears like
a preupgrade scenario
23:21:44,897 INFO loader: kernel command line:
23:21:44,897 INFO loader:
ks=hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/ks.cfg
23:21:44,898 INFO loader: repo=hd::/var/cache/yum/preupgrade
23:21:44,898 INFO loader: preupgrade
23:21:44,898 INFO loader:
stage2=hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/install.img
23:21:44,898 INFO loader: Setting stage2 from
hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/install.img
23:21:44,899 INFO loader: method hd - UUID=0a3d18e7-9d53-499a-b572-feda3bafec21 |
/boot/upgrade/install.img
23:21:44,899 DEBUG loader: readNetInfo /tmp/s390net not found, early return
23:21:44,899 INFO loader: anaconda version 14.17.4 on x86_64 starting
Definitely the F-14-Beta installer version.
23:21:50,671 INFO loader: getting kickstart file
23:21:50,671 INFO loader: getting kickstart file from harddrive
23:21:50,671 INFO loader: Loading ks from device
UUID=0a3d18e7-9d53-499a-b572-feda3bafec21 on path /boot/upgrade/ks.cfg
23:21:50,672 INFO loader:
getFileFromBlockDevice(UUID=0a3d18e7-9d53-499a-b572-feda3bafec21, /boot/upgrade/ks.cfg)
23:21:50,783 INFO loader: Searching for file on path /tmp/mnt//boot/upgrade/ks.cfg
23:21:50,822 INFO loader: file copied to /tmp/ks.cfg
It found and used the kickstart file (ks.cfg) created by preupgrade.
23:21:53,607 INFO loader: got stage2 at url
hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21://boot/upgrade/install.img
It finds the install.img file copied to your local disk partition by preupgrade.
anaconda.program
http://fpaste.org/jNYH/
anaconda.storage
http://fpaste.org/u5mA/
anaconda.syslog
http://fpaste.org/AqTK/
anaconda.xlog
http://fpaste.org/gWwP/
anaconda.yum
http://fpaste.org/CqmZ/
upgrade.log
http://fpaste.org/Lzn4/
Shows the *good* version of glibc being installed
(glibc-2.12.90-14.x86_64). So you were *not* impacted by recent glibc
problems.
upgrade.log.syslog
http://fpaste.org/2KtM/
That's all I have - I deleted install.log one and a half years ago.
> Did the install ever complete?
I don't know - this box is not attached to any display - I was not
able to verify it.
I would have expected to see a line in your anaconda.log indicating that
the install completed, and it was rebooting. There are a few remaining
minor steps the installer does before completing, but I don't see a
mention of those.
I'm sorry to ask, but if still available, I'd love to see
your /boot/upgrade/ks.cfg file as well.
According to this
http://fpaste.org/Lzn4/
packages was installed.
> Or did you force reboot it before it
> ever started/completed?
I ran preupgrade - it downloaded all packages, then I reboot system. I
waited for almost two hours before I turned off it manually. System at
that time did not respond to ping.
Upgrades can take a *lot* longer than you anticipate. By design,
preupgrade does all the network activity (downloading kernel+initrd,
install.img and packages) from a running system. The upgrade itself is
done without networking. In scenarios where preupgrade doesn't have
sufficient /boot disk space for content, it will perform a network
upgrade. That doesn't seem to be the case from your logs.
In summary, in your case, I would not expect networking to be active
during the upgrade process.
> When preupgrade reboots into the installer, it
> sets up a boot-next grub target which will boot into the installer
> *only* for the next reboot. If you reboot multiple times before
> starting the installer, it will boot back into your previously defined
> default boot target.
It seems to me that the system is properly upgraded.
I suspect the upgrade completed and was waiting on user input, or was
still in the middle of performing package upgrade %scripts and rebooted.
Thanks,
James
10:21 a.m.
2010/10/4 James Laska <jlaska(a)redhat.com>:
Thanks for posting your logs. See comments below.
On Mon, 2010-10-04 at 16:26 +0200, Michał Piotrowski wrote:
> 2010/10/4 James Laska <jlaska(a)redhat.com>:
> > On Mon, 2010-10-04 at 15:28 +0200, Michał Piotrowski wrote:
> >> 2010/10/4 James Laska <jlaska(a)redhat.com>:
> >> > On Mon, 2010-10-04 at 13:10 +0200, Michał Piotrowski wrote:
> >> >> W dniu 4 października 2010 00:16 użytkownik Michał Piotrowski
> >> >> <mkkp4x4(a)gmail.com> napisał:
> >> >> > W dniu 3 października 2010 23:58 użytkownik Bruno Wolff III
> >> >> > <bruno(a)wolff.to> napisał:
> >> >> >> There
> >> >> >> was some recent security updates that affected pretty much
all versions.
> >> >> >> I haven't run into any f14 specific problems
recently.
> >> >> >>
> >> >> >
> >> >> > Good to know. I'll try to update system. I will let know
if there are
> >> >> > any problems
> >> >>
> >> >> I noticed a problem with preupgrade-cli. I rebooted system,
preupgrade
> >> >> updated it, but then the system does not respond to ping - I
turned
> >> >> off it by pressing power button. I connected box to the TV to see
what
> >> >> happens, but the system started correctly. Strange. Do physical
access
> >> >> to the machine is required when using preupgrade?
> >> >>
> >> >> Apart from that it seems that everything went well.
> >> >
> >> > Should not be required, but hard to say without more details. I
suspect
> >> > it the installer stopped and was prompting you for some information
> >> > (perhaps language or keymap)? Do you have access to the installer
logs
> >> > from the preupgrade attempt?
> >>
> >> Yes, I've got some logs from installation. I can post it - it's
about 226 kb.
> >
> > I wouldn't mind seeing the logs (fpaste.org). Can you
> > paste /root/upgrade.log, /root/install.log and /var/log/anaconda.log?
>
> anaconda.log
> http://fpaste.org/FFnR/
Nice, this shows that it appears to have booted and completed a
preupgrade install.
Specifically, you can see it starts the installer with what appears like
a preupgrade scenario
> 23:21:44,897 INFO loader: kernel command line:
> 23:21:44,897 INFO loader:
> ks=hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/ks.cfg
> 23:21:44,898 INFO loader: repo=hd::/var/cache/yum/preupgrade
> 23:21:44,898 INFO loader: preupgrade
> 23:21:44,898 INFO loader:
> stage2=hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/install.img
> 23:21:44,898 INFO loader: Setting stage2 from
hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21:/boot/upgrade/install.img
> 23:21:44,899 INFO loader: method hd - UUID=0a3d18e7-9d53-499a-b572-feda3bafec21 |
/boot/upgrade/install.img
> 23:21:44,899 DEBUG loader: readNetInfo /tmp/s390net not found, early return
> 23:21:44,899 INFO loader: anaconda version 14.17.4 on x86_64 starting
Definitely the F-14-Beta installer version.
> 23:21:50,671 INFO loader: getting kickstart file
> 23:21:50,671 INFO loader: getting kickstart file from harddrive
> 23:21:50,671 INFO loader: Loading ks from device
UUID=0a3d18e7-9d53-499a-b572-feda3bafec21 on path /boot/upgrade/ks.cfg
> 23:21:50,672 INFO loader:
getFileFromBlockDevice(UUID=0a3d18e7-9d53-499a-b572-feda3bafec21, /boot/upgrade/ks.cfg)
> 23:21:50,783 INFO loader: Searching for file on path /tmp/mnt//boot/upgrade/ks.cfg
> 23:21:50,822 INFO loader: file copied to /tmp/ks.cfg
It found and used the kickstart file (ks.cfg) created by preupgrade.
> 23:21:53,607 INFO loader: got stage2 at url
hd:UUID=0a3d18e7-9d53-499a-b572-feda3bafec21://boot/upgrade/install.img
It finds the install.img file copied to your local disk partition by preupgrade.
> anaconda.program
> http://fpaste.org/jNYH/
>
> anaconda.storage
> http://fpaste.org/u5mA/
>
> anaconda.syslog
> http://fpaste.org/AqTK/
>
> anaconda.xlog
> http://fpaste.org/gWwP/
>
> anaconda.yum
> http://fpaste.org/CqmZ/
>
> upgrade.log
> http://fpaste.org/Lzn4/
Shows the *good* version of glibc being installed
(glibc-2.12.90-14.x86_64). So you were *not* impacted by recent glibc
problems.
> upgrade.log.syslog
> http://fpaste.org/2KtM/
>
> That's all I have - I deleted install.log one and a half years ago.
>
> > Did the install ever complete?
>
> I don't know - this box is not attached to any display - I was not
> able to verify it.
I would have expected to see a line in your anaconda.log indicating that
the install completed, and it was rebooting. There are a few remaining
minor steps the installer does before completing, but I don't see a
mention of those.
I'm sorry to ask, but if still available, I'd love to see
your /boot/upgrade/ks.cfg file as well.
Unfortunately I don't have this file.
> According to this
> http://fpaste.org/Lzn4/
> packages was installed.
>
> > Or did you force reboot it before it
> > ever started/completed?
>
> I ran preupgrade - it downloaded all packages, then I reboot system. I
> waited for almost two hours before I turned off it manually. System at
> that time did not respond to ping.
Upgrades can take a *lot* longer than you anticipate. By design,
preupgrade does all the network activity (downloading kernel+initrd,
install.img and packages) from a running system.
I've got a self build kernel 2.6.35.6-34.fc13.x86_64. I am almost sure
that I have not seen kernel in the list of packages to upgrade.
The upgrade itself is
done without networking. In scenarios where preupgrade doesn't have
sufficient /boot disk space for content, it will perform a network
upgrade. That doesn't seem to be the case from your logs.
In summary, in your case, I would not expect networking to be active
during the upgrade process.
> > When preupgrade reboots into the installer, it
> > sets up a boot-next grub target which will boot into the installer
> > *only* for the next reboot. If you reboot multiple times before
> > starting the installer, it will boot back into your previously defined
> > default boot target.
>
> It seems to me that the system is properly upgraded.
I suspect the upgrade completed and was waiting on user input,
It seemed to me that preupgrade process should not require any user
interactions. I've used this tool twice on this system and I do not
recall that I had to provide any user input.
or was
still in the middle of performing package upgrade %scripts and rebooted.
Maybe. However, it seems to me that the update of 420 packages should
not take so long. That's why I turned off the box.
Unfortunately, on my laptop virtualization is not working too fast, so
it'll not check whether preupgrade actually works well. But maybe
someone else will find the time to check.
Thanks for your analysis.
Thanks,
James
Regards,
Michal
11:07 a.m.
On Mon, 2010-10-04 at 17:21 +0200, Michał Piotrowski wrote:
It seemed to me that preupgrade process should not require any user
interactions. I've used this tool twice on this system and I do not
recall that I had to provide any user input.
Preupgrade should, preupgrade itself is the tool that prepares the
system for an upgrade. But preupgrade should prepare a system that
performs an unattended upgrade. From what I can tell, all indications
are that was what was happening, and then the system was rebooted.
> or was
> still in the middle of performing package upgrade %scripts and rebooted.
Maybe. However, it seems to me that the update of 420 packages should
not take so long. That's why I turned off the box.
Again, just my best guesses based on your logs. The best way to find
out is to actively monitor the upgrade process first-hand.
Unfortunately, on my laptop virtualization is not working too fast,
so
it'll not check whether preupgrade actually works well. But maybe
someone else will find the time to check.
Thanks for your analysis.
Anytime, thanks for sharing your experiences and logs!
Thanks,
James
8:06 a.m.
On Sun, 2010-10-03 at 23:35 +0200, Michał Piotrowski wrote:
Hi,
I'm thinking about upgrade of my devel (php, python2, python3,
postgres, mysql, firebird, cherokee, apache, git, some xorg related
libs etc) system from F13 to F14Beta+. I've seen recently some bug
reports about serious bugs associated with glibc, gcc, kernel. Do
these problems has been eliminated?
Are there any known serious
outstanding issues?
The blocker list is always a good reference to answer that question.
https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Blocker&hide...
Thanks,
James
8:33 a.m.
2010/10/4 James Laska <jlaska(a)redhat.com>:
The blocker list is always a good reference to answer that question.
https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Blocker&hide...
Thanks.
It seems that nothing on this list is relevant for this system.
Thanks,
James
Regards,
Michal
5005
days inactive
5006
days old
13 comments
3 participants
participants (3)
-
Bruno Wolff III -
James Laska -
Michał Piotrowski