Bug 904253 - Fedup boot image doesn't load
Summary: Fedup boot image doesn't load
Status: CLOSED DUPLICATE of bug 896010
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-01-25 21:02 UTC by Aaron Luchko
Modified: 2013-05-21 19:43 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2013-05-21 19:43:17 UTC

Attachments (Terms of Use)
Picture of the boot error (101.80 KB, image/jpeg)
2013-01-25 21:02 UTC, Aaron Luchko
no flags Details
Picture of the fedup boot configuration (91.41 KB, image/jpeg)
2013-01-25 21:05 UTC, Aaron Luchko
no flags Details
Picture of a regular fedora boot configuration (which works) (99.66 KB, image/jpeg)
2013-01-25 21:06 UTC, Aaron Luchko
no flags Details
Fedora fstab (950 bytes, application/octet-stream)
2013-01-26 00:37 UTC, Aaron Luchko
no flags Details
Ubuntu Grub (10.52 KB, application/octet-stream)
2013-01-26 00:42 UTC, Aaron Luchko
no flags Details

Description Aaron Luchko 2013-01-25 21:02:12 UTC
Created attachment 687677 [details]
Picture of the boot error

Description of problem:
The system is a dual boot Ubuntu/Fedora system where Ubuntu running grub2 is responsible for the boot loader. Ubuntu is able to load the other Fedora kernels but the Fedup kernel crashes during the boot, I can't find the logs anywhere but I transcribed a bit and attached (blurry) pictures of the boot

[ OK ] Started Show Plymouth Boot Screen
[OK] Reached target Basic System
 EXT4-fs (dm-0) mounted filesystem with ordered data mode. 0pts: (null)
 EXT4-fs (dm-0) mounted filesystem with ordered data mode. 0pts: (null)
 EXT4-fs (dm-0) re-mounted. 0pts: (null)
 EXT4-fs (dm-0) re-mounted. 0pts: (null)
 systemd-journald[60]: Received SIGTERM

Note the command used to set up the update is 'fedup-cli --network 18 --debuglog fedupdebug.log' the 

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. Have my weird boot setup
2. Try booting

Comment 1 Aaron Luchko 2013-01-25 21:05:48 UTC
Created attachment 687678 [details]
Picture of the fedup boot configuration

The grub configuration created by the ubuntu grub2

Comment 2 Aaron Luchko 2013-01-25 21:06:56 UTC
Created attachment 687679 [details]
Picture of a regular fedora boot configuration (which works)

Comment 3 Will Woods 2013-01-25 22:32:37 UTC
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?

Comment 4 Aaron Luchko 2013-01-26 00:37:35 UTC
Created attachment 687766 [details]
Fedora fstab

Comment 5 Aaron Luchko 2013-01-26 00:42:18 UTC
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.

Comment 6 Aaron Luchko 2013-01-26 00:51:39 UTC
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

Comment 7 Will Woods 2013-01-26 03:07:40 UTC
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:


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).

Comment 8 Aaron Luchko 2013-01-26 03:32:40 UTC
I'll have to check when I'm back on campus Monday but that sounds like it should work.

Comment 9 Aaron Luchko 2013-01-29 03:12:15 UTC
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

Comment 10 Aaron Luchko 2013-01-30 23:47:54 UTC
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

Comment 11 Will Woods 2013-01-31 15:13:17 UTC
> 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)?

Comment 12 Aaron Luchko 2013-01-31 18:27:52 UTC
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)

Comment 13 Aaron Luchko 2013-01-31 20:31:58 UTC
# 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 {
        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)

Comment 14 Aaron Luchko 2013-01-31 20:42:24 UTC
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)

Comment 15 Aaron Luchko 2013-03-10 22:22:57 UTC
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.

Comment 16 Will Woods 2013-05-21 19:43:17 UTC

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

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