Good morning... Any guidance on this problem? Thank you. :)

Here is additional information that I found in the journal. It *appears* similar to what was reported in Bub IDS "1044086" and "873459" (which are mount name space related). But in this case we are talking about FC20 and the latest version of fedup (v0.8.0-3.fc19). See below. Thank you.
	

user@linux$ journalctl --since "2014-01-07" (Ran today to attempt upgrade).

[ ... snip ... ]
Jan 07 10:46:37 p170hm systemd[1]: Started Tell Plymouth To Write Out Runtime Data.
Jan 07 10:46:37 p170hm systemd[1]: Starting System Initialization.
Jan 07 10:46:37 p170hm systemd[1]: Reached target System Initialization.
Jan 07 10:46:37 p170hm systemd[1]: Starting Prepare Upgrade Image...
Jan 07 10:46:37 p170hm systemd[1]: Starting System Upgrade.
Jan 07 10:46:37 p170hm systemd[1]: Reached target System Upgrade.
Jan 07 10:46:37 p170hm systemd[1]: Starting Stop Read-Ahead Data Collection 10s After Completed Startup.
Jan 07 10:46:37 p170hm systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup.
Jan 07 10:46:40 p170hm systemd[1]: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1062 (upgrade-prep.sh)
Jan 07 10:46:40 p170hm systemd[1]: Mounting Arbitrary Executable File Formats File System...
Jan 07 10:46:40 p170hm mount[1063]: mount: unknown filesystem type 'binfmt_misc'
Jan 07 10:46:40 p170hm systemd[1]: proc-sys-fs-binfmt_misc.mount mount process exited, code=exited status=32
Jan 07 10:46:40 p170hm systemd[1]: Failed to mount Arbitrary Executable File Formats File System.
Jan 07 10:46:40 p170hm systemd[1]: Unit proc-sys-fs-binfmt_misc.mount entered failed state.
Jan 07 10:46:40 p170hm upgrade-prep.sh[978]: moving mounts into /system-upgrade-root
Jan 07 10:46:40 p170hm upgrade-prep.sh[978]: mount: /system-upgrade-root is not mountpoint or bad option
Jan 07 10:46:40 p170hm upgrade-prep.sh[978]: In some cases useful info is found in syslog - try
Jan 07 10:46:40 p170hm upgrade-prep.sh[978]: dmesg | tail or so.
Jan 07 10:46:40 p170hm upgrade-prep.sh[978]: mount: mount point /system-upgrade-root/sysroot does not exist
Jan 07 10:46:40 p170hm upgrade-prep.sh[978]: couldn't bind / into upgrade dir
Jan 07 10:46:40 p170hm systemd[1]: upgrade-prep.service: main process exited, code=exited, status=1/FAILURE
Jan 07 10:46:40 p170hm systemd[1]: Failed to start Prepare Upgrade Image.
Jan 07 10:46:40 p170hm systemd[1]: Startup finished in 8.068s (kernel) + 515ms (initrd) + 4.632s (userspace) = 13.216s.
Jan 07 10:46:40 p170hm systemd[1]: Unit upgrade-prep.service entered failed state.
Jan 07 10:46:40 p170hm systemd[1]: Triggering OnFailure= dependencies of upgrade-prep.service.
Jan 07 10:46:40 p170hm systemd[1]: Starting LSB: Supports the direct execution of binary formats....
Jan 07 10:46:40 p170hm systemd[1]: Starting Show Plymouth Reboot Screen...
Jan 07 10:46:40 p170hm systemd[1]: Stopping Forward Password Requests to Plymouth Directory Watch.
Jan 07 10:46:40 p170hm systemd[1]: Stopped Forward Password Requests to Plymouth Directory Watch.
Jan 07 10:46:40 p170hm systemd[1]: Stopping Debug shell on tty2...
Jan 07 10:46:40 p170hm systemd[1]: Stopping Stop Read-Ahead Data Collection 10s After Completed Startup.
Jan 07 10:46:40 p170hm systemd[1]: Stopped Stop Read-Ahead Data Collection 10s After Completed Startup.
Jan 07 10:46:40 p170hm systemd[1]: Stopping System Upgrade.
Jan 07 10:46:40 p170hm systemd[1]: Stopped target System Upgrade.
Jan 07 10:46:40 p170hm systemd[1]: Stopping System Initialization.
[ ... snip ... ]

Good morning. Any ideas on this would be appreciated. I cannot upgrade to FC20 and I am currently having (potentially kernel related) temperature problems with the latest FC19 kernel. So I really need to try to upgrade. Thank you! :)

Can someone help with this? This bug happened before but on a previous version of fedup. Can someone suggest what to try at least, I need to upgrade. Why is this simply rebooting and not starting the upgrade. What to to look for and try. Thanks.

Could you attach your /etc/fstab and the output of the `lsblk` command?

Thanks Will. Here you go...


user@linux$ cat /etc/fstab
# /etc/fstab
# Created by anaconda on Wed Mar  9 16:28:54 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
tmpfs        /dev/shm  tmpfs   defaults        0 0
devpts       /dev/pts  devpts  gid=5,mode=620  0 0
sysfs        /sys      sysfs   defaults        0 0
proc         /proc     proc    defaults        0 0
#
/dev/sda2    /                       ext4    defaults,user_xattr        1 1
/dev/sdb1    /drives.d/1TBssd-sdb1.d ext4    defaults,user_xattr        1 1
#
LABEL=1TBusbPRI /drives.d/1TBusbPRI.d    ext4    defaults        1 1
LABEL=1TBusbSEC /drives.d/1TBusbSEC.d    ext4    defaults        1 1


user@lunux$ sudo lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 894.3G  0 disk 
├─sda1   8:1    0   256G  0 part 
└─sda2   8:2    0 638.3G  0 part /
sdb      8:16   0 894.3G  0 disk 
└─sdb1   8:17   0 894.3G  0 part /drives.d/1TBssd-sdb1.d
sdc      8:32   0 931.5G  0 disk 
└─sdc1   8:33   0 931.5G  0 part /drives.d/1TBusbSEC.d
sdd      8:48   0 931.5G  0 disk 
└─sdd1   8:49   0 931.5G  0 part /drives.d/1TBusbPRI.d
sr0     11:0    1  1024M  0 rom

By the way, here is a FedoraForum post yesterday of someone else having the same issue (but on FC18 trying to go to FC19 or FC20):

http://forums.fedoraforum.org/showthread.php?t=296585


And here's my own FedoraForum post is here (in case some interesting information is added by someone):

http://forums.fedoraforum.org/showthread.php?p=1684718#post1684718

Thank you!

Wait - what version of fedup are you using? 

If it's not 0.8.0, please update and try again.

See https://fedoraproject.org/wiki/Common_F20_bugs#fedup-07-fail for details.

If you're sure that you've got 0.8.0, you should do:

  su -c 'mv /var/lib/fedora-upgrade /var/lib/system-upgrade'
  su -c 'mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade'

and then re-run fedup like before, and confirm that:

  /system-upgrade-root exists, and is a directory, and
  /system-upgrade exists, and is a symlink

Does that all check out? Does the upgrade work if you check that stuff?

Thanks Will...

I'm using "v0.8.0-3.fc19" (as mentioned at the top), and here verification:

=================================
user@linux$ rpm -qi fedup
=================================
Name        : fedup
Version     : 0.8.0
Release     : 3.fc19
Architecture: noarch
Install Date: Thu 02 Jan 2014 01:14:46 PM EST
Group       : Unspecified
Size        : 242715
License     : GPLv2+
Signature   : RSA/SHA256, Thu 12 Dec 2013 10:22:34 AM EST, Key ID 07477e65fb4b18e6
Source RPM  : fedup-0.8.0-3.fc19.src.rpm
Build Date  : Tue 10 Dec 2013 07:03:27 PM EST
Build Host  : buildvm-08.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://github.com/wgwoods/fedup
Summary     : The Fedora Upgrade tool
Description :
fedup is the Fedora Upgrade tool
===========================


I was also aware of the bug you pointed out. Everything is as it should be
with respect to your Comment-9, shown here:

=========================
user@linux$ ls -ald /var/lib/fedora-upgrade /var/tmp/fedora-upgrade
ls: cannot access /var/lib/fedora-upgrade: No such file or directory
ls: cannot access /var/tmp/fedora-upgrade: No such file or directory

user@linux$ ls -ald /var/lib/system-upgrade /var/tmp/system-upgrade
drwxr-xr-x 2 root root 237568 Jan 16 13:50 /var/lib/system-upgrade
drwxr-xr-x 17 root root 4096 Jan 16 13:45 /var/tmp/system-upgrade

user@linux$ ls -lad /system-upgrade-root /system-upgrade
lrwxrwxrwx 1 root root 23 Jan 16 13:50 /system-upgrade -> /var/lib/system-upgrade
drwxr-xr-x 3 root root 4096 Jan  3 15:24 /system-upgrade-root
=========================

The above structure was/is already in place when failure occurred.

Perhaps the same issue has crept into "v0.8.0-3" of fedup?


Thanks!

I also have this problem and would like to see a solution. I posted my problem here:

http://forums.fedoraforum.org/showthread.php?t=296585

Maybe my grub.cfg is the problem? It seems to not be able to initialize the initramfs-fedup.img image.

Here is the Fedup-related part of the grub.cfg:

menuentry 'System Upgrade (fedup)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4d0bc71d-cbb4-4b94-9ce0-627883a3d2b5' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  ef027a25-297b-42e7-8c00-1313f0baa5b5
        else
          search --no-floppy --fs-uuid --set=root ef027a25-297b-42e7-8c00-1313f0baa5b5
        fi
        echo 'Loading System Upgrade (fedup)'
        linux   /vmlinuz-fedup root=/dev/mapper/fedora_homeserver-root ro nomodeset rd.lvm.lv=fedora_homeserver/swap rd.md=0 rd.dm=0  rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora_homeserver/root rhgb quiet 3 LANG=en_US.UTF-8
        echo 'Loading initial ramdisk ...'
        initrd /initramfs-fedup.img

(In reply to Lucas from comment #11)
> I also have this problem and would like to see a solution. I posted my
> problem here:

That's a different problem. This bug is about F19->F20 upgrades.
See bug 1054988 for F18->F19 problems.

Will you are correct that "Comment 11" describes a different problem.

Is there any progress on mine (i.e. this one). There is no other way to get from FC19 to FC20 without reinstalling -- something I really don't want to do.

Thank you!

I am encountering virtually the same issue on upgrade from F19 to F20. My dependency failures after running fedup are:

WARNING: problems were encountered during transaction test:
  broken dependencies
    kmod-wl-3.13.9-100.fc19.x86_64-6.30.223.141-1.fc19.27.x86_64 requires kernel-3.13.9-100.fc19.x86_64
    kmod-nvidia-3.13.9-100.fc19.x86_64-1:331.67-1.fc19.x86_64 requires kernel-3.13.9-100.fc19.x86_64
    kmod-VirtualBox-3.13.9-100.fc19.x86_64-4.3.6-2.fc19.14.x86_64 requires kernel-3.13.9-100.fc19.x86_64

I checked the filesystem entries as per Comment 9 and everything looks good. I am on fedup-0.8.0-4

Thinking that this was originally an nvidia driver issue, i tried removing the nouveau blacklist from the kernel parameters on bootup but this also did not change much.

I should add here that, on trying another reboot but adding selinux=0 enforcing=0 it seems I was able to get through the setup despite the warnings above after running fedup. At this point I have no idea what was, if anything, my original issue, but I am upgraded finally to F20 so I am happy.

(In reply to Alex Tomic from comment #14)
> I am encountering virtually the same issue on upgrade from F19 to F20. My
> dependency failures after running fedup are:
> 
> WARNING: problems were encountered during transaction test:
>   broken dependencies
>     kmod-wl-3.13.9-100.fc19.x86_64-6.30.223.141-1.fc19.27.x86_64 requires
> kernel-3.13.9-100.fc19.x86_64
>     kmod-nvidia-3.13.9-100.fc19.x86_64-1:331.67-1.fc19.x86_64 requires
> kernel-3.13.9-100.fc19.x86_64
>     kmod-VirtualBox-3.13.9-100.fc19.x86_64-4.3.6-2.fc19.14.x86_64 requires
> kernel-3.13.9-100.fc19.x86_64

These are unrelated to the original problem (i.e. the failure to start the upgrade).

Those messages are just informational - it's letting you know that the listed packages may not work after the upgrade.

(In reply to Alex Tomic from comment #15)
> I should add here that, on trying another reboot but adding selinux=0
> enforcing=0 it seems I was able to get through the setup despite the
> warnings above after running fedup.

Then you probably had a different problem.

If adding "selinux=0 enforcing=0" fixed your problem, there's a couple of likely causes:

* If you had SELINUX=disabled (or no "selinux-policy-targeted" installed) that's bug 1044484.

* If you have multiple encrypted partitions, that's bug 1045864.

But AFAICT none of that is relevant to this particular problem.

Created attachment 889837 [details]
upgrade-prep.sh

(In reply to nmvega from comment #6)
> /dev/sda2    /                       ext4    defaults,user_xattr        1 1
> /dev/sdb1    /drives.d/1TBssd-sdb1.d ext4    defaults,user_xattr        1 1
> #
> LABEL=1TBusbPRI /drives.d/1TBusbPRI.d    ext4    defaults        1 1
> LABEL=1TBusbSEC /drives.d/1TBusbSEC.d    ext4    defaults        1 1

/drives.d is interesting - that's not a standard part of the filesystem layout, so it doesn't normally exist inside the upgrade image.

So it's possible that's where the "couldn't bind / into upgrade dir" message comes from - we can't bind /drives.d/1TBssd-sdb1.d into /system-upgrade-root because there's no /system-upgrade-root/drives.d.

I'm attaching an updated upgrade-prep.sh which should (in theory) create any missing directories in the upgrade image. If you replace your existing /usr/libexec/upgrade-prep.sh with this, does the upgrade start?

(Be sure to back up the existing one first, and make sure you chmod 755 /usr/libexec/upgrade-prep.sh!)

Thank you Will. Sadly, I no longer have a FC19 environment to try. I eventually had to undertake the upgrade process by installing FC20 from scratch.

Ah well. I actually just set up a test system with /drives.d to confirm my theory, but it turns out to be incorrect - the upgrade proceeded just fine.

Since the system in question no longer exists and I can't reproduce the problem on my own, I don't think we're going to be able to figure out what happened here.

Sorry for the inconvenience.