Description of problem: Via bz 736318 I was made aware that the initrd.img now contains both the initrd for the kernel as well as the installer that could be downloaded separately in previous preupgrade situations. See http://fedoraproject.org/wiki/How_to_use_PreUpgrade#Troubleshooting for relevant backgrounds and workarounds. Version-Release number of selected component (if applicable): Latest and greatest for Fedora 15. How reproducible: preupgrade-cli "Fedora 16 Branched Pre-release (Verne)" Steps to Reproduce: 1. 2. 3. Actual results: preupgrade tries to download an initrd.img (e.g. http://nl.mirror.eurid.eu/fedora/linux/development/16/x86_64/os/images/pxeboot/initrd.img) that is 128M in size. https://bugzilla.redhat.com/show_bug.cgi?id=736318#c2 explains: It's not corrupted, it's two concatenated cpio images: [xz-compressed dracut initramfs][uncompressed cpio with /squashfs.img] So by not keeping the actual initrd and the install.img separated you are taking upgrade options away from us. Systems get upgraded and upgraded and upgraded. Partitions like one for /boot do not grow over time. Combine this with the apparent refusal to improve the RAID upgrade possibilities and you see what this is coming to. Just one outdated upgrade path that is supported: booting from and optical disc. Expected results: More flexibility, more proactivity, more customer satisfaction Additional info: I do think this is a serious issue if you take a broader look than just the initrd choice here. Fedora does NOT look ahead while considering the users if you look at this choice, the RAID situation, the bugs right after upgrading, etc. No real thought and communication appears in the bugs open for these issues. (just defensive posts) No progress. And while that is happening we see this bug appear...
The whole stage2 stuff at http://fedoraproject.org/wiki/How_to_use_PreUpgrade#Troubleshooting needs some adjusting too, due to all this.
This is not a preupgrade bug. Actually I don't think it's not a bug at all. Preupgrade does work. Moving to distribution although I think bugzilla is not the place for this discussion.
(In reply to comment #2) > This is not a preupgrade bug. Actually I don't think it's not a bug at all. Oops. I meant: I don't think it's a bug at all.
This is the only place I know to communicate this stuff. The decisions mentioned were not communicated. I just have to find out stuff someway by coincidence...
So just explain how to file 'issues' w.r.t. a decision (?) that works on stuff surrounding preupgrade?
We have mailing lists and IRC channels for that. Anyway, I don't see how this choice made upgrading the system harder.
Don't? One bigger file instead of two smaller ones? Let alone that stage 2 could be downloaded later? See the original filing of this 'bug'. And please, oh please, try to see this from the viewpoint of a user of this distro, not as a developer or whatever role in the fedora process one has.
Before we continue our way and close this bz with stuff like NOTABUG, WONTFIX, etc: - Can you please prove my explanation of the stage2 situation wrong? - Can you please point me to documentation that shows me that no upgrading flexibility was lost? Thanks.
(In reply to comment #8) > Before we continue our way and close this bz with stuff like NOTABUG, WONTFIX, This isn't the place for discussion about a feature. Please send email to fedora-devel and we'll discuss there. Thanks. Richard.
Not one response on fedora-devel to my email there. See http://lists.fedoraproject.org/pipermail/devel/2011-October/date.html So that route does not work.
W.r.t. comment #8: These comments could also be seen as remidners to update mentioned info on the fedora website. Also I could be viewed as someone with care for the fedora product and concern about the paths to the future
Concluding we can say that the process as intended does not work. The problems brought under attention are not explained, not commented on, not changed or whatsoever. Still we sit here with a distro that is making weird decisions without good explanation, which make it appear arrogant.
> Systems get upgraded and upgraded and upgraded. Many of us do not recommend upgrading at all, ever. Separate your user data (ie: /home and /srv) from your system data (everything else, usually) and then reinstalling a new version of Fedora becomes easy, including adjusting your system storage in most cases. > Partitions like one for /boot do not grow over time. Eventually you have to update your partition layout. This may require making some backups, possibly using some temporary external storage. Things need updating periodically. Nobody ever promised that your partition layout from Fedora 4 would be suitable for Fedora 16. > Combine this with the apparent refusal to improve the RAID upgrade > possibilities and you see what this is coming to. > Just one outdated upgrade path that is supported: booting from and optical > disc. Or a non-optical disk, like USB. Suddenly not all that outdated. > > Expected results: > More flexibility, more proactivity, more customer satisfaction For someone who is talking about flexibility, you do not seem at all willing to update your methods to fit the changing/changed times. I'm just saying that the situation is not nearly as bad as you make it out to be. Yes, preupgrade has some limitations. So does anaconda. So does your system administration policy.
Starting in F17 or so we will be splitting up the initrd.img and runtime image again. Also - and more importantly - we'll be using dracut-built initramfs images, which means that the initrd.img is capable of mounting anything your normal system can mount. This means (with a little work) the anaconda runtime (previously called "stage2") won't need to be stored in /boot anymore. Sometimes the correct solution to a problem is the hard one. And sometimes hard problems take a while to solve. Your patience and good faith would be appreciated.
@Comment 14: Thanks for explaining. I just worry a bit about the 'or so' part. I do hope this issue gets fixed a.s.a.p. Does this imply a solution for the RAID issues?