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): fedup-0.7.2-1.fc17.noarch How reproducible: Always Steps to Reproduce: 1. Have my weird boot setup 2. Try booting
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 ***