Description of problem: Context: Upgrading Fedora 17 64bit (KDE Spin) to Fedora 18 (stable) using fedup and an ISO located in /home. After reboot and selection of "System upgrade" in grub, the upgrade fails with "failed to start initialize storage subsystem". The command 'journalctl -n' tells -- Logs begin at Mon, 2013-01-21 10:09:50 CET, end at Mon, 2013-01-21 10:47:11 CET. -- Jan 21 10:43:38 fedora-64 systemd[1]: Failed to start Initialize storage subsystems (RAID, LVM, etc.). Jan 21 10:43:38 fedora-64 systemd[1]: Unit fedora-storage-init.service entered failed state Jan 21 10:47:11 fedora-64 systemd[1]: Starting Initialize storage subsystems (RAID, LVM, etc.)... Jan 21 10:47:11 fedora-64 fedora-storage-init[1252]: Setting up Logical Volume Management: Invalid argument for --available: ay Jan 21 10:47:11 fedora-64 fedora-storage-init[1252]: Error during parsing of command line. Jan 21 10:47:11 fedora-64 fedora-storage-init[1252]: [FAILED] Jan 21 10:47:11 fedora-64 systemd[1]: fedora-storage-init.service: main process exited, code=exited, status=3/NOTIMPLEMENTED Jan 21 10:47:11 fedora-64 systemd[1]: Failed to start Initialize storage subsystems (RAID, LVM, etc.). Jan 21 10:47:11 fedora-64 systemd[1]: Unit fedora-storage-init.service entered failed state Version-Release number of selected component (if applicable): fedup 0.7.2 release 1.fc17 (Fedora 17) How reproducible: I cannot boot either the "System upgrade" nor the older kernel in Grub. So the bug does not vanish. Steps to Reproduce: 1. Install Fedora 17 64 bit 2. Partition scheme (I know it is weird): /dev/sda1 /boot ext3; /dev/sda2 LVM2; LVM2/root / ext4; LVM2/home /home btrfs 3. Copy in /home the Fedora 18 DVD ISO 4. Install and launch fedup using the --iso switch 5. Reboot and choose "System upgrade" Actual results: Boot fails, thus upgrade fails. All Grub entries are affected, all entries fail with the same error. Expected results: Upgrade succesfull Additional info: I have done a bit of investigation and I have narrow it down to the error message. My file '/lib/systemd/fedora-storage-init' contains the following entry which IMHO is incorrect: l. 42 - action $"Setting up Logical Volume Management:" /sbin/lvm vgchange -a ay --sysinit vgchange has a '-a' (short for --available) option which can have (according to the installed man page) [e|l]{y|n}. Obviously 'ay' is not possible, which is what the error message reported by 'journalctl -n' stated. I am not sure if this will fix my problem, but will send an update soon if this work out. Once I will have the machine up and running again, I will post other attachment (dmesg, etc.).
I did get further than previously. But I have after that another blocking bug where the boot is interrupted and I need to enter maintenance mode. On the console I can see: [ TIME ] Timed out waiting for device dev-mapper-vg_fs\x2dhome.device. [DEPEND] Dependency failed for /home. [DEPEND] Dependency failed for Local File Systems. I will try to get the file (journalctl -b) out of the VM. Strangely once entering maintenance mode, if I execute 'mount /home' it is done successfully! But then 'systemctl default' hangs display thousands of line per minute containing: systemd[1]: dbus.service start request repeated too quickly, refusing to start.
Created attachment 684233 [details] Here are the logs after I corrected the /lib/systemd/fedora-storage-init file.
Created attachment 684234 [details] Logs and configuration when first reported the bug.
(In reply to comment #1) > I did get further than previously. But I have after that another blocking > bug where the boot is interrupted and I need to enter maintenance mode. > Just wanted to report on this second bug, I have added a new disk to my VM, formated it as btrfs directly (so no LVM, which also makes more sense) and copied over my previous home to this new one. I updated fstab and rebooted. The upgrade this time picked up and ended successfully ... or almost KDE cannot start because it does not find libudev.so.0 (I have now libudev.so.1). But any that's another bug. However, my bug report stand still and it seems that I have spotted the bug. So I will upload the patch soon.
So I am now finally with a usable system. I have check the man page of vgchange once more and I can see that now it is supporting the '-a ay' option. So during the upgrade process there is a problem that systemd seems to be upgrade to a newer release of LVM2 which support new switches on the command line BUT LVM2 is not upgraded to this newer release. Hence the upgrade problem I have faced when using the ISO image. I guess the correction is either to upgrade LVM2 before the 1st reboot, or to have an intermediate 'systemd' support with still the old switches (aka. '-a y').
Thanks for your work tracing the problem! Here's where I'm confused. /lib/systemd/fedora-storage-init comes from the 'initscripts' package. Every version of initscripts in F17 does 'vgchange -a y'. This was changed to 'vgchange -a ay' in F18 - see bug 873565. So the question is: why was your F17 system trying to run vgchange -ay? There's also: Jan 21 11:43:34 fedora-64 udevd[377]: starting version 182 Jan 21 11:43:34 fedora-64 systemd-udevd[393]: starting version 195 ... Jan 21 11:43:35 fedora-64 udevd[377]: unknown key 'RUN{builtin}' in /usr/lib/udev/rules.d/80-drivers.rules:10 ...which shouldn't happen unless you have both F17 udev and F18 systemd installed. Did you update part of your system to F18 version somehow before running the upgrade? Or did you have to run fedup multiple times? Maybe one of those attempts partially upgraded your system to F18?
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.