On 12/11/10 22:04, John Pilkington wrote:
Hi: I'm new to this list and haven't found a searchable
archive, but I
haven't seen this topic in Google.
My box came with MS Vista and I initially added f10, which was fully
updated until near EOL. Later I added a second disk and f12, and
recently I used preupgrade for f12-to-f13. That went well, and I
decided to try f10-to-f14. The packages were identified and put into
cache and after I had copied the new lines in grub.conf from disk 1 to
disk 2 the upgrade entry appeared in the Grub menu. The kernel boots
but I don't think it sees the preupgrade cache and the only option
offered is to upgrade the f13 system. I don't want to do that.
I've tried various modifications to grub.conf without success. One
recent iteration is below. The f10final and f13 entries, and the MS
related ones, all work and I've left the f10release entry in case it
holds useful data. I downloaded the f14 installer and when I specify
its location on disk 2, (/dev/sdb1 /install.img) it runs. Again, the
location specified in grub.conf apparently doesn't get used, although
it's there too.
TIA, John P.
-----------------
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd1,1)
# kernel /vmlinuz-version ro root=/dev/mapper/VolGroup-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=1
timeout=15
splashimage=(hd1,1)/grub/splash.xpm.gz
# hiddenmenu
title Upgrade to Fedora 14 (Laughlin)
root (hd0,2)
kernel /upgrade/vmlinuz preupgrade
root=UUID=db9d32af-2d48-42bc-beed-2ed149eb21a1
repo=/var/cache/yum/preupgrade stage2=/var/cache/yum/install.img
initrd /upgrade/initrd.img
title Fedora (2.6.34.7-61.fc13.x86_64)
root (hd1,1)
kernel /vmlinuz-2.6.34.7-61.fc13.x86_64 ro
root=/dev/mapper/VolGroup-lv_root LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk rhgb quiet
elevator=deadline
initrd /initramfs-2.6.34.7-61.fc13.x86_64.img
title Fedora10final (2.6.27.41-170.2.117.fc10.x86_64)
root (hd0,2)
kernel /vmlinuz-2.6.27.41-170.2.117.fc10.x86_64 ro
root=/dev/VolGroup00/LogVol00 rhgb quiet elevator=deadline
initrd /initrd-2.6.27.41-170.2.117.fc10.x86_64.img
title Fedora10release (2.6.27.5-117.fc10.x86_64)
root (hd0,2)
kernel /vmlinuz-2.6.27.5-117.fc10.x86_64 ro
root=UUID=db9d32af-2d48-42bc-beed-2ed149eb21a1 rhgb quiet
initrd /initrd-2.6.27.5-117.fc10.x86_64.img
title Vista_sp1
rootnoverify (hd0,1)
makeactive
chainloader +1
title GatewayRecovery
rootnoverify (hd0,0)
makeactive
chainloader +1
-----------------------
I had several responses to this, all essentially saying that skipping
releases in preupgrade was likely to cause grief. That's probably true,
but I thought I would persevere and tried f10 > f12; in doing so I found
the reason why my previous attempt had failed when it did, which was, as
I suspected, that the right partitions were not being accessed. Partly
I wasn't clear which system was active at each stage.
The box has two /boot partitions, one on each disk. Preupgrade writes
to only one, and in this case the active version of grub.conf was the
other one, so some editing was needed. The f10 > f12 preupgrade created
different addressing information and I was able to piece together a
working grub.conf entry as follows:
----------------------------
title Upgrade to Fedora 12 (Constantine)
root (hd0,2)
kernel /upgrade/vmlinuz preupgrade
repo=hd:UUID=db9d32af-2d48-42bc-beed-2ed149eb21a1:/var/cache/yum/preupgrade
stage2=hd:UUID=1421679d-390e-4d2a-9fe9-9bc5c4701721:/upgrade/install.img
ks=hd:UUID=1421679d-390e-4d2a-9fe9-9bc5c4701721:/upgrade/ks.cfg
initrd /upgrade/initrd.img
-----------------------------
Here the repo UUID was that of the target /root partition, and the
stage2 and ks UUIDs were that of the target /boot partition (aka
(hd0,2)), which this time also (just) held the downloaded install.img.
I hadn't been able to create a working syntax for the earlier attempt,
and it rather looks as if ks.cfg got lost somewhere.
The system booted and the upgrade went ahead, but didn't update either
of the grub.conf files, so I modified the old f10 entries to identify
the new kernel.
The new system works, but not yet perfectly - I still have some
nouveau/nvidia conflicts to sort out. It looks hopeful but there may
still be trouble ahead. I shall never know whether f10 > f14 could have
worked!
John P