<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 30, 2013, at 5:49 AM, Brian Hanks <<a href="mailto:bhanks@bhanks.net">bhanks@bhanks.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<pre wrap="">On Sun, 29 Dec 2013 22:47:07 -0700, Chris Murphy wrote:
</pre>
<blockquote>
<pre wrap="">You chose the fedup option in GRUB, but instead of getting text status of the progessing update, you got what appeared to be normal F19 boot?
If /var is a separate partition/LV instead of on rootfs, this behavior occurs. Please post your fstab if unsure. Do you have any encrypted partitions or volumes? Please post the result of lsblk if yes.
</pre>
</blockquote>
</blockquote>
<br>
I do not have any encrypted partitions, but /var is definitely
separate:</div></blockquote><br></div><div><a href="https://fedoraproject.org/wiki/Common_F20_bugs#Upgrade_fails_if_.2Fvar_is_a_separate_partition">https://fedoraproject.org/wiki/Common_F20_bugs#Upgrade_fails_if_.2Fvar_is_a_separate_partition</a></div><div><br></div><div>Make sure /var is actually being mounted with the existing fedup boot option (even though it doesn't start the upgrade). The bug itself reports a case where failure to mount is not accounted for in the workaround. The problem stems from /var mounting late, so the upgrade process doesn't begin because the upgrade files are in /var. If the upgrade files are located elsewhere, the upgrade process can start, but /var must eventually be mounted in order for its filed to be upgraded. So a failed /var mount is different than delayed /var mount.</div><div><br></div><div><br></div><div>Chris Murphy</div></body></html>