Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 585563 - system not upgradable with preupgrade
system not upgradable with preupgrade
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 588540 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-24 14:54 EDT by Pavol Šimo
Modified: 2011-06-27 11:51 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 11:51:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
requested log files (7.73 KB, application/x-bzip2)
2010-04-25 07:12 EDT, Pavol Šimo
no flags Details
logs from run in comment 8 (7.00 KB, application/x-bzip2)
2010-08-19 16:22 EDT, Patrick C. F. Ernzer
no flags Details
Anaconda log - F14 (5.95 KB, application/octet-stream)
2010-11-06 06:55 EDT, Arun S A G
no flags Details

  None (edit)
Description Pavol Šimo 2010-04-24 14:54:29 EDT
Description of problem:
I want to upgrade the newer Fedora system to Fedora 13 (Branch, as stated at the preupgrade screen). It has failed before, when the newer system was Fedora 11 and I was trying to upgrade to Fedora 12.

/dev/sda3 - Fedora 8
/dev/sda6 - Fedora 12
grub is setup from /dev/sda3, is able to load both systems

Trying to run preupgrade fails after reboot with message "product Fedora version 8 found on /dev/sda3 is not upgradable".

relevant grub entry:
    root (hd0,5)
    kernel /boot/upgrade/vmlinuz preupgrade repo=hd:UUID=3754ee98-d642-428c-8151-5218f03d25f0:/var/cache/yum/preupgrade stage2=hd:UUID=3754ee98-d642-428c-8151-5218f03d25f0:/boot/upgrade/install.img ks=hd:UUID=3754ee98-d642-428c-8151-5218f03d25f0:/boot/upgrade/ks.cfg
    initrd /boot/upgrade/initrd.img

/boot/upgrade/ks.cfg:
# ks.cfg generated by preupgrade
lang sk_SK.UTF-8
keyboard us
bootloader --upgrade --location=none
upgrade --root-device=UUID=3754ee98-d642-428c-8151-5218f03d25f0
reboot
Comment 1 Pavol Šimo 2010-04-24 14:56:56 EDT
The device with UUID 3754ee98-d642-428c-8151-5218f03d25f0 is /dev/sda6, as seen in /dev/disk/by-uuid/
Comment 2 Chris Lumens 2010-04-24 22:21:11 EDT
Please attach /tmp/anaconda.log and /tmp/storage.log to this bug report so we can get some data as to what's going on here.
Comment 3 Pavol Šimo 2010-04-25 07:12:03 EDT
Created attachment 408936 [details]
requested log files

Attached anaconda.log and storage.log from unsuccessful anaconda run
Comment 4 Chris Lumens 2010-05-03 17:57:32 EDT
*** Bug 588540 has been marked as a duplicate of this bug. ***
Comment 5 Iván Jiménez 2010-05-03 18:08:55 EDT
Chris: any additional info I can provide to help debug it? It's strange because I upgraded from f11 to f12 without problems (when I had a boot partition, which I get rid of because of low space problems). When I relocated /boot to root fs I did grub-install /dev/sda6, which I think now is wrong, could that be related to this problem?
Comment 6 Iván Jiménez 2010-05-03 23:30:31 EDT
I upgraded to f13 by moving anaconda's files (vmlinuz, initrd.img and install.img) to /home (sda5);  I did so because of line 1251 of http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=storage/__init__.py;h=06049164b13904de72a6abff3ae36807b921e319;hb=refs/heads/f13-branch

1250         if device.protected:
1251             # can't upgrade the part holding hd: media so why look at it?
1252             continue

which I assume refers to the fs holding stage{1,2}.

Pavol, you could try moving vmlinuz, initrd.img and install.img to sda3 (no need to move /var/cache/yum/preupgrade) and point grub at the new location. My grub.conf entry was:

title Upgrade to Fedora 13 (Branch)
	root (hd0,4)
	kernel /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade stage2=hd:sda5:/upgrade/install.img ks=hd:sda5:/upgrade/ks.cfg
	initrd /upgrade/initrd.img

and ks.cfg (root-device= points to sda6):

# ks.cfg generated by preupgrade
lang es_CO.UTF-8
keyboard la-latin1
bootloader --upgrade --location=none
clearpart --none
upgrade --root-device=UUID=f0147f01-5360-4ba3-a72f-84fc78b662e4
reboot

%post
grubby --remove-kernel=/boot/upgrade/vmlinuz
rm -rf /boot/upgrade /var/cache/yum/preupgrade*
%end

Conclusion: moving /boot to root fs is a bad idea, it's better to make boot part bigger. Shall I add it to preupgrade page on the wiki? and I still don't understand why to skip the part holding hd: media if it isn't going to be reformatted.
Comment 7 Andrew Meredith 2010-08-18 19:54:12 EDT
Would it be possible to have an explanatory warning during the preupgrade, setup sequence, at least? As it stands now, it does all the downloading and configuring, and just mysteriously ignores a partition that's right in front of it's nose, and then dies.

The trap here is that F13 is perfectly bootable with a combined boot/root partition, as have been Fedora <13 and RHL before it, going back years. Once physical the restriction on disk sizes went away, there was no longer any need to bother about separating them, for many use cases. Anaconda has been quite happy with this layout going way back. 

For the benefit of the others bitten by this one, may I ask am I right to summarise that previously anaconda's boot objects came on CDs or such, with the rest of anaconda in a filesystem that looked like root. Rather than let anaconda consider this root in it's plans, better to just ignore the file system that they were on. Now that preupgrade has moved the boot objects under the OS's /boot this assumption has been silently broken. /boot has always been allowed inside the root filesystem, it's /boot/upgrade that hasn't.

BTW Thanks to Iván for solving it and sharing the workaround. This one has been giving me a lot of trouble.
Comment 8 Patrick C. F. Ernzer 2010-08-19 16:22:01 EDT
(note, I am not an anaconda maintainer, just reproducing for testing on a private box)
FWIW, no separate /boot with preupgrade-1.1.4-1.fc13 and anaconda 14.15  is better, except for point 7. below

steps to reproduce
1. Install F13 x86_64 with
   - some swap
   - / rest of disk
   - no /boot
   - package selection: minimal
2. yum update
3. shutdown -r now #while we're at it
4. yum install preupgrade
5. preupgrade-cli "Fedora 14 (Laughlin)"
6. shutdown -r now
7. correct path in Select Partition dialog to match reality (/boot/upgrade/install.img)
9. Select 'Upgrade an Existing Installation'
10. rest defaults

Actual results:
apart from the snag at step 7 the upgrade procedure went fine
Comment 9 Patrick C. F. Ernzer 2010-08-19 16:22:57 EDT
Created attachment 439779 [details]
logs from run in comment 8
Comment 10 Bug Zapper 2010-11-03 12:23:06 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Andrew Meredith 2010-11-04 06:11:24 EDT
I just tried to use the preupgrade tool to get to Fedora 13 and spent a great deal of time and effort to get nowhere. Not only did preupgrade fail, but the DVD and the net install disks both failed to find the old OS, forcing me to do it by hand with yum; so yes, I can confirm it is still an issue with versions higher than F12.

I am not empowered to change the version, would the maintainer or reporter please do so.

Thanks
Comment 12 Patrick C. F. Ernzer 2010-11-04 15:39:39 EDT
seeing that this is an anaconda F13 bug, adjusting release.
Comment 13 Arun S A G 2010-11-06 06:55:49 EDT
Created attachment 458309 [details]
Anaconda log - F14
Comment 14 Arun S A G 2010-11-06 06:58:13 EDT
I can reproduce this bug when upgrading from F-13 to F-14.

My file system structure

/dev/sda1 root file system (/)
/dev/sda3/ home /home



# ks.cfg generated by preupgrade
lang en_US.UTF-8
keyboard us
bootloader --upgrade --location=none
clearpart --none
upgrade --root-device=None
reboot


%post
grubby --remove-kernel=/boot/upgrade/vmlinuz
rm -rf /boot/upgrade /var/cache/yum/preupgrade*
%end

##Note

I even changed the --root-device=uuid of /dev/sda1. It didn't work.
Comment 15 Bug Zapper 2011-06-02 10:54:34 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2011-06-27 11:51:02 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.