-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 27 Jul 2009, Ralf Corsepius wrote:
On 07/27/2009 11:26 AM, David Cantrell wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 27 Jul 2009, Ralf Corsepius wrote:
On 07/27/2009 07:33 AM, David Cantrell wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 26 Jul 2009, 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? If
you want a small root partition you should put /var/cache/yum on
another
partition.
Do you mean Preupgrade didn't handle the lack of disk space well?
* anaconda failing during reboots due not being able to process fstab
correctly (FC11's anaconda misparses fstab and is unable able to
process
bind-mounts nor nfs-mounts).
Bind mounts are fixed, as far as I know:
https://bugzilla.redhat.com/show_bug.cgi?id=496406
For NFS mounts, I believe it's fixed in commit
40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That
should
carry over NFS mounts listed in /etc/fstab if you are doing an upgrade.
Well, to my knowledge these are "FIXED RAWHIDE", only.
That's true. anaconda is unique in that the only way a new one can be
released to fix installation issues for users is to generate new media.
Exactly => this bug is _not fixed_.
We continue to fix problems reported against Fedora 11's anaconda in
rawhide,
but for users needing the fix in the latest stable release, consider Fedora
Unity. Fedora Unity generates new spins of the latest stable release
including backports of anaconda fixes:
http://www.fedoraunity.org/
With all due respect to fedoraunity and you. To me it is a serious Fedora
management and rel-eng mistake causing major harm to fedora's and RH's
reputation to not provide updated media, thus to expose users to known bugs.
Openly said, I think this management mistake is one of the culprits for the
poor shape of Fedora.
Another one is not having banned "FIXED RAWHIDE/UPSTREAM".
The problem here is when do you stop generating new media to fix bugs in
F-11's installer and start working on F-12? Never? A week after F-11 GA?
What determines if an installer bug gets a fix in F-11 vs. not?
It's a gigantic waste of time for the installer team to release updates to
F-11's installer. We can address those bugs in rawhide and have them fixed in
the next stable release. Generating new media for an existing release is not
a great solution. The mirrors are already synced up with the GA release.
Here's what we do and I think it works best for now given the incredibly short
(and damn near impossible to work with) planning and development windows for
Fedora releases:
1) Major installation problems are documented on the Common Bugs wiki page for
the Fedora release in question. Either a workaround or updates.img file is
provided to fix the issue.
2) New bugs come in and we address them in rawhide. Where we run in to issues
here is asking people to test the next build of rawhide. Not everyone wants
to do that (or can, has time, etc). But spending our time producing new media
and/or updates.img files for F-11 takes away from our time to work on F-12.
This is where I think Fedora Unity can bridge the gap. They can pick up fixes
for F-11 installation problems and roll new media for users. That provides a
non-rawhide solution for the reporter, lets the bug at least get some testing,
and frees us [installer team] from having to produce media or updates.img
files for F-11.
A larger problem we have is that we don't get the wide testing on the Alpha,
Beta, or Release Candidate releases of the upcoming Fedora release. The same
group of people generally test things out and the QA team performs their
tests, but we never get the same testing exposure that a GA release does.
Most users are sitting around waiting for the GA release and when they find a
bug, it's too late for us to do anything about it in that release.
Maybe if we lengthened the development cycle for a Fedora release and renamed
Alpha, Beta, and RC to .0, .1, and .2, users would think differently of each
release.
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpuAuQACgkQ5hsjjIy1Vkn5KACaAnsQG9dR1+JMIwyLXLKpR9Cs
HQcAn08eYetKLYGPgXIH5hk30DlEqrcD
=AVY1
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
