Red Hat Bugzilla – Bug 863702
Fedora 18 Alpha won't upgrade & won't share a disk
Last modified: 2012-11-22 21:54:10 EST
Description of problem:
I got a laptop with two partitions: a 525MB /boot partition, and
79.5 GB lvm; the lvm have a volume for swap, one for /home, and two
volumes for root; one for F14, and one for F17.
I want to upgrade the F14 to A18-Alpha.
Although the initial menue from the install DVD and a menue point for
install/upgrade, it doesn't seem like that is possible.
When for installation location, I just select the disk and go back,
the installer starts to scribble over the entire disk.
As I need my data, that's a non-starter.
So I restored from back-up and tried 'continue' after selecting the
hard drive. There's a prompt that assures me that there's plenty of
space and I the installer can do all the partitioning for me (well,
1 MB of free space and 80 GB of existing installations that the installer
is happy to indiscriminately wipe for me...) . Well, I insist on reviewing
& customizing the partitioning anyway ... so then it doesn't actually do
any partitioning and drops me into manual partitioning.
any and shows me disk
There's an options to create mount points automatically - which gets an
error, the 'details' have no details, and then it hangs...
So reboot for another try...
When I try to set mount points by hand, it only wants to know sizes,
not existing partitions or logical volumes.
When I try to request a /boot mount point with the size of the existing boot
partition, I get pop-up "An unknown error as occured".
The 'More info' shows multiple repetitions of
<timestamp> ERR systemd-udev: failed to execute '/usr/lib/udev/socket:/org/kernel/dm/multipath_event' 'socket:/org/kernel/dm/multipath_event': No such file or directory
On the last page, groups of two or four of these messages are prepended by:
<timestamp> INFO kernel:[ <threedigits.fivedigits> (the last one is 131.197620)]
SELinux: mounted filesystem with ordered data mode. opts:(null)
<timestamp> DEBUG kernel: <threedigits.fivedigits> (last is 131.197636)] SELinux: initialized (dev dm-1, type ext4), uses xattr
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. If necessary, power-cycle laptop to recover from failure. Well, once
quit actually seemed to work, I don't know what makes the difference between
hanging or not.
2. boot with install DVD, set keyboard, timezone, software, root password ...
don't try to use ntp, as then the install will surely hang.
3. and finally attempt to set install location
Entire disk wiped or lockup before install begins
upgrade one user-specified existing linux installation to the new version,
allowing me to use the existing home partition without it being wiped.
F15 (using openbox) worked mostly OK on this laptop, except sometimes it
would randomly switch from the selected UK keyboard layout to the German
layout (which happens to match the labels on the keys - but not C / Lisp
programming priorities). F17, in addition, has a broken Display menue,
and settings made with the equivalent KDE system settings menue will be
forgotten when a new openbox session is started (or when the current openbox session is ended? Same difference). More seriously (and compounding the
previous issue), after some use, the keyboard will stop accepting keystrokes
unless they auto-repeat, till new session is started. Or in the case of
an external USB keyboard, till it is hot-plugged.
I really wanted to check if F18 is any better on these issues, and how well
Mate works... but first I have to (be able to) install it.
I also have a F17 install on an external disk which won't boot (F17 won't
put a bootsector there - might be realated to bug 743136). I've done the
partitioning into bios boot / boot / vfat data / (lvm with root / root2 /
swap / home) to my liking, and in particular there's data in the vfat
Why can't I just tell the installer to re-use all the mount points from
the F17 installation there?
I've tried to delete & replace individual items there, but I don't see how
to make a new bios_boot partition.
That install attempt on the external disk doesn't even go far enough to
miss the bios_boot 'mount point' - it hangs in the 'preparing to install'
step. On VT4, there are again lots of laments for the missing multipath_event
file, and another error:
ERR kernel:[ 974.976094] DMA-API: debugging out of memory - disabling
on VT5, it says: FATAL: Module scsi_wait_scan not found.
Upgrading in F18 will be accomplished with some other process, not with anaconda. So there's nothing really to do there. If you need to do an upgrade, you should try going with yum (yes, I know that's against our usual advice).
For custom partition, that was also known for the alpha and should be much better in the beta. We've got other bugs tracking issues with that.
let's just close as WORKSFORME, as I think all the issues mentioned in that screed are addressed in other bugs.