Bug 904253

Created attachment 687678 [details]
Picture of the fedup boot configuration

The grub configuration created by the ubuntu grub2

Created attachment 687679 [details]
Picture of a regular fedora boot configuration (which works)

Can you attach your /etc/fstab and /etc/grub2.cfg (both from Fedora, obviously)?

Is the GRUB2 installation using a different config than what Fedora sees in /etc/grub2.cfg? If so, where is the correct config?

What are the exact boot args used when booting Fedora? (check /proc/cmdline)

If you add 'rd.break=pre-pivot' to the fedup boot args, do you get a dracut shell? What's in /proc/cmdline there?

Created attachment 687766 [details]
Fedora fstab

Created attachment 687767 [details]
Ubuntu Grub

Attached is the Ubuntu grub.d/, the boot loader that actually does the work, the bits in 40_custom were from a previous configuration that I needed since the fedora /boot didn't have the /boot -> . symlink. Right now I use grub entries that the ubuntu grub2 loader autodetects.

For the current kernel /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.6.11-5.fc17.x86_64 root=/dev/dm-0

 
For fedup
BOOT_IMAGE=/boot/vmlinuz-fedup  root=/dev/dm-0 rd.break=rev-pivot

So here's the deal. fedup gets the upgrade to start by adding a few extra arguments to the boot commandline. Specifically, for upgrades to F18 it adds:

  upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup

You've apparentely got your system set up so Fedora can't manipulate the boot arguments. Which means there's no way fedup can possibly add these arguments and get the upgrade to start.

As a quick workaround, you could probably add the arguments yourself.

A long-term solution would probably involve changing Ubuntu's GRUB2 config so it boots Fedora by loading the Fedora GRUB2 config. I think the GRUB2 'configfile' command can do this - see the GRUB2 docs for details:

  http://www.gnu.org/software/grub/manual/grub.html

Can you confirm that adding the boot arguments above lets the upgrade start? (you can also add 'rd.upgrade.test' to make it run the upgrade in "test mode", where it won't actually upgrade anything).

I'll have to check when I'm back on campus Monday but that sounds like it should work.

I added the arguments and got no change, exact same crash and error as before.

When I added the rd.break arg I was able to get

BOOT_IMAGE=/boot/vmlinuz-fedup root=/dev/dm-0 upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup rd.break=rev-pivot

For reference this is a grub entry I've added (to ubuntu's /etc/grub.d/40_custom) that adds the Fedup entry with the upgrade targets (note, this configuration results in exactly the same boot error)

menuentry 'Fedup' --class fedora --class gnu-linux --class gnu --class os {
        insmod lvm
        insmod part_msdos
        insmod ext2
        set root='(vg_losgar-lv_fedora)'
        search --no-floppy --fs-uuid --set=root 33e28fcc-fe96-4de5-b63e-5d992e1b69b8
        linux   /boot/vmlinuz-fedup root=/dev/dm-0  upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup
        initrd  /boot/initramfs-fedup.img
}

> root=/dev/dm-0

I'm guessing from this that you have your Fedora partition encrypted? (That would have been a good thing to mention in the original bug report..)

1) You probably shouldn't be using hardcoded device names - see bug 895805.
2) If you have multiple encrypted partitions (e.g. / and /home) that's probably why the upgrade is hanging - that's bug 896010.

Can you paste the output of 'blkid' (as root, from Fedora)? 

If you have multiple crypto_LUKS partitions, could you try the workaround for bug 896010 (add 'enforcing=0' to the boot args)?

None of the partitions are encrypted.

The entry I just posted is identical to the automatic configurations that Ubuntu grub creates by scanning for other OSs, the only difference is the upgrade args I added to the end (I"ll add the blkid info once I'm on campus)

# blkid 
/dev/sda1: UUID="e1726ee3-9b60-4d74-8995-fe714e94aec0" TYPE="ext4" 
/dev/sda2: UUID="fWPngv-a8mW-BANz-SQZM-fx0N-vyFm-rjdAu1" TYPE="LVM2_member" 
/dev/mapper/vg_losgar-lv_fedora: UUID="33e28fcc-fe96-4de5-b63e-5d992e1b69b8" TYPE="ext4" 
/dev/mapper/vg_losgar-lv_home: UUID="abb32358-bffd-4839-9afc-4e1a8f5f6189" TYPE="ext4" 
/dev/mapper/vg_losgar-lv_ubuntu: UUID="0cdc18b3-1c09-4040-b0e1-5785b9712271" TYPE="ext4" 
/dev/mapper/vg_losgar-lv_swap: UUID="cc8d3092-bcf3-4422-a875-5a270d659284" TYPE="swap" 

Also when I originally installed fedora I think I tried installing a bootloader as well and I think Fedora might have tried to make its own boot partition, the Ubuntu grub auto-detect only really worked once I added the /boot -> . symlink, but before then I used manual entries like this (using the logical volume as the root instead of dm0) 

menuentry 'Fedora, with Linux 3.6.9-2' --class fedora --class gnu-linux --class gnu --class os {
        recordfail
        insmod gzio
        insmod lvm
        insmod part_msdos
        insmod ext2
        set root='(vg_losgar-lv_fedora)'
        search --no-floppy --fs-uuid --set=root e1726ee3-9b60-4d74-8995-fe714e94aec0
        linux   /vmlinuz-3.6.9-2.fc17.x86_64 root=/dev/mapper/vg_losgar-lv_fedora ro   quiet splash vt.handoff=7
        initrd  /initramfs-3.6.9-2.fc17.x86_64.img
}

(I'll test with the alternate root)

As expected the boot entry with the alternate root didn't change anything (ie normal kernals work with either dm-0 or /mapper/vg_losgar-lv_fedora, and the fedup kernel works with neither)

So it looks like I forgot to try the enforcing=0 fix.

Note, I don't have any encrypted partitions but setting enforcing=0 allows the upgrade to proceed.

*** This bug has been marked as a duplicate of bug 896010 ***