Bug 1099299 - fedup fails to upgrade F20 to F21 or later - infinite loop when starting udev
Summary: fedup fails to upgrade F20 to F21 or later - infinite loop when starting udev
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1146140 1146219 (view as bug list)
Depends On:
Blocks: F21BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2014-05-20 03:55 UTC by austinenglish
Modified: 2014-11-21 20:53 UTC (History)
43 users (show)

Fixed In Version: systemd-216-5.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-30 05:30:22 UTC


Attachments (Terms of Use)
screenshot (3.47 MB, image/jpeg)
2014-05-20 08:13 UTC, austinenglish
no flags Details
journalctl -b output (90.33 KB, text/plain)
2014-05-21 03:45 UTC, austinenglish
no flags Details
dmesg output (61.62 KB, text/plain)
2014-08-21 16:35 UTC, Simon Gerhards
no flags Details
Fedup log (2.60 MB, text/plain)
2014-10-29 14:35 UTC, Lukas Brabec
no flags Details
Photo of fail messages (216.09 KB, image/jpeg)
2014-10-29 14:36 UTC, Lukas Brabec
no flags Details

Description austinenglish 2014-05-20 03:55:16 UTC
Description of problem:
When rebooting after running fedup, the system goes into an infinite loop while attempting to start udev kernel device manager.

Version-Release number of selected component (if applicable):
$ yum list installed | grep -e fedup -e systemd -e udev
fedup.noarch                           0.8.0-3.fc20                    @updates 
fedup-dracut.x86_64                    0.8.0-2.fc20                    @fedora  
libgudev1.i686                         208-16.fc20                     @updates 
libgudev1.x86_64                       208-16.fc20                     @updates 
libgudev1-devel.i686                   208-16.fc20                     @updates 
libgudev1-devel.x86_64                 208-16.fc20                     @updates 
python-pyudev.noarch                   0.15-5.fc20                     @fedora  
system-config-printer-udev.x86_64      1.4.4-1.fc20                    @updates 
systemd.x86_64                         208-16.fc20                     @updates 
systemd-devel.i686                     208-16.fc20                     @updates 
systemd-devel.x86_64                   208-16.fc20                     @updates 
systemd-libs.i686                      208-16.fc20                     @updates 
systemd-libs.x86_64                    208-16.fc20                     @updates 
systemd-python.x86_64                  208-16.fc20                     @updates 
systemd-python3.x86_64                 208-16.fc20                     @updates 

How reproducible:
Every time

Steps to Reproduce:
1. sudo fedup --network rawhide --nogpgcheck --instrepo http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/ 
2. reboot

Actual results:
Infinite loop

Expected results:
Upgrade to rawhide is performed

Additional info:
System has LVM encryption.

Comment 1 austinenglish 2014-05-20 03:57:37 UTC
Also, to separate this from bug 1095891, this is real hardware, an i5 laptop (cat /proc/cpuinfo shows 4 processors).

Linux localhost.localdomain 3.14.4-200.fc20.x86_64 #1 SMP Tue May 13 13:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Comment 2 austinenglish 2014-05-20 08:13:00 UTC
Created attachment 897495 [details]
screenshot

Comment 3 Will Woods 2014-05-20 17:04:52 UTC
If the upgrade gets stuck after the reboot, then the packages on your system aren't really relevant; the important question is what packages were used when building upgrade.img.

'journalctl -b' output would help here, but I'd guess this is just a duplicate of bug 1095891.

Comment 4 austinenglish 2014-05-21 03:45:49 UTC
Created attachment 897798 [details]
journalctl -b output

Comment 5 Helge 2014-06-25 20:21:56 UTC
Same problem here on Acer TravelMate 8202WLMi today.

I did a yum update, then 
fedup --network rawhide --nogpgcheck --instrepo http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/

(Also had to refresh grub manually to get the feddup menu item to show up)

Comment 6 Johan Swensson 2014-07-25 20:03:22 UTC
Experiencing same problem on freshly installed F20 as well, nothing done except a yum update -y and reboot before running fedup. Hardware is a Thinkpad T410 if it helps.

Comment 7 Sergio Monteiro Basto 2014-08-09 23:52:31 UTC
hi, 
I got same problem : stops at a start job is running for udev Kernel device manager .
with fedup-0.8.1-1.fc20 and doing:
fedup --network 21 --initrepo http://mirrors.eu.kernel.org/fedora/development/21/x86_64/os/

but switch to tty2 with crtl + alt + F2 and do 

systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket 

fedup performs the upgrade , although doesn't wrote almost anything in console , I just knew that is performing the upgrade following process and observing that hd is working hard , as usual in this situations .

Comment 8 D. Charles Pyle 2014-08-16 23:14:40 UTC
Add me to the list.  I have the very same issue trying to upgrade F20 to rawhide/branched (F21).  Infinite loop involving udev/systemd.  Started process. Went to bed. After several hours the process still is looped from failure to failure and system isn't upgraded.  It is a fresh, bare metal install using btrfs.

Comment 9 D. Charles Pyle 2014-08-16 23:16:05 UTC
Forgot to list Fedup version.

fedup-0.8.1-1.fc20.noarch

Comment 10 D. Charles Pyle 2014-08-16 23:42:25 UTC
Upgraded to Fedup-0.8.1-2.fc21 but the failure continues.  About to attempt it again, using:

fedup --network 21 --instrepo http://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/ --nogpgcheck

Comment 11 James Hogarth 2014-08-18 10:15:41 UTC
Thanks Sergio that workaround worked for me...

The journal service kept continuously restarting itself during the upgrade and journalctl -b states there are no journal files...

This is on an i3 laptop.

Comment 12 D. Charles Pyle 2014-08-18 23:27:06 UTC
That workaround in comment 7 also worked for me on a Dell Inspiron 560 desktop.

Comment 13 Simon Gerhards 2014-08-21 16:35:38 UTC
Created attachment 929266 [details]
dmesg output

I'm experiencing the same issues.
Here is my dmesg output for further debugging.

Comment 14 Sergio Monteiro Basto 2014-08-23 06:51:46 UTC
(In reply to James Hogarth from comment #11)
> and journalctl -b states there are no journal files...

I have that problem too , I find out /var/log doesn't exist , so make something like mkdir /var/log ( I don't remember) puts journalctl -b  working 


(In reply to Simon Gerhards from comment #13)
> Created attachment 929266 [details]
> dmesg output
> 
> I'm experiencing the same issues.
> Here is my dmesg output for further debugging.

File /var/log/journal/df0e93939e8049039c89dc73e551dd64/system.journal corrupted or uncleanly shut down, renaming and replacing.

is the same problem /var/log doesn't exist .

Comment 15 Matthias 2014-09-23 09:00:49 UTC
The issue still happens when trying to upgrade from F20 to F21 Alpha RC1.

Comment 7 helps to solve the issue.

Comment 16 Rick Elrod 2014-09-24 06:00:14 UTC
+1, this happened to me as well. Comment 7 worked around it.

Comment 17 Adam Williamson 2014-09-27 01:23:26 UTC
*** Bug 1146219 has been marked as a duplicate of this bug. ***

Comment 18 Adam Williamson 2014-09-27 01:25:49 UTC
Proposing as a Beta blocker, https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Upgrade_requirements :

"For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."

also, we should commonbugs this for now.

Comment 19 Bill Gianopoulos 2014-09-27 12:11:03 UTC
OK I think I understand the issue here.  The error messages indicated and issue with /dev/log.  Under rawhide this is a symlink, in fedora 20 it is not.

Fedora20:

[wag@server ~]$ ls -l /dev/log
srw-rw-rw-. 1 root root 0 Sep 27 07:58 /dev/log

Rawhide:

[wag@rawhide-maine ~]$ ls -l /dev/log
lrwxrwxrwx. 1 root root 28 Sep 27 02:32 /dev/log -> /run/systemd/journal/dev-log

Comment 20 Will Woods 2014-09-30 22:01:34 UTC
(In reply to Bill Gianopoulos from comment #19)
> OK I think I understand the issue here.  The error messages indicated and
> issue with /dev/log.  Under rawhide this is a symlink, in fedora 20 it is
> not.

I don't think this is the root cause of the hang, although it is what's causing the logging problems.

F20 systemd (v205) has `systemd-journald.socket`, which creates /dev/log.
F21 systemd (v215) has `systemd-journald-dev-log.socket`, which creates /run/systemd/journal/dev-log and symlinks /dev/log to it.
So when we switch from F20 to F21, systemd-journald-dev-log.socket fails because it can't make the symlink.

But fixing the sockets doesn't make the upgrade start, so I'm pretty sure this is a separate problem, and will need to be tracked in a separate bug.

Comment 21 Will Woods 2014-09-30 22:18:39 UTC
As far as I can tell, the problem is that systemd never gets notification that udevd (and/or journald?) have started - which is why systemd keeps trying to restart it.

strace shows that udevd is unlinking /run/udev/queue and doing epoll_wait(), so it's definitely gotten into the mainloop. But systemctl shows the status as "activating (start)", which I'm pretty sure means it's still waiting for the sd_notify(1, "READY=1")..

But then eventually the watchdog timeout hits, and systemd kills the existing job and tries to restart udevd. Hence the loop.

Comment 22 Hubert Figuiere 2014-10-01 17:07:18 UTC
Dupe of bug 1146140 ?

Comment 23 Adam Williamson 2014-10-01 18:11:50 UTC
rather the other way around, as this one is four months older and has much more detail and corroboration. I will close that as a dupe of this.

Comment 24 Adam Williamson 2014-10-01 18:13:03 UTC
*** Bug 1146140 has been marked as a duplicate of this bug. ***

Comment 25 Hubert Figuiere 2014-10-01 18:26:01 UTC
but had I asked on the other bug, I'm not sure somebody would have confirmed ;-) either way doesn't matter.

Comment 26 Adam Williamson 2014-10-03 18:15:34 UTC
Discussed at 2014-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-03/f21-blocker-review.2014-10-03-15.58.log.txt . Accepted as a blocker, this clearly violates the criteria as cited in c#18.

Comment 27 Adam Williamson 2014-10-08 17:44:32 UTC
Ping systemd devs - are you aware this is a Beta release blocker and needs attention with priority? Thanks!

Comment 28 Zbigniew Jędrzejewski-Szmek 2014-10-16 00:33:23 UTC
Sorry, I somehow missed this bug. I'll look into it.

Comment 29 Zbigniew Jędrzejewski-Szmek 2014-10-16 16:42:26 UTC
(In reply to Will Woods from comment #20)
> (In reply to Bill Gianopoulos from comment #19)
> > OK I think I understand the issue here.  The error messages indicated and
> > issue with /dev/log.  Under rawhide this is a symlink, in fedora 20 it is
> > not.
> 
> I don't think this is the root cause of the hang, although it is what's
> causing the logging problems.
> 
> F20 systemd (v205) has `systemd-journald.socket`, which creates /dev/log.
> F21 systemd (v215) has `systemd-journald-dev-log.socket`, which creates
> /run/systemd/journal/dev-log and symlinks /dev/log to it.
> So when we switch from F20 to F21, systemd-journald-dev-log.socket fails
> because it can't make the symlink.
> 
> But fixing the sockets doesn't make the upgrade start, so I'm pretty sure
> this is a separate problem, and will need to be tracked in a separate bug.
Yep, it seems your analysis is right. I'll add a ExecStartPre=/bin/rm -f /dev/log to the socket unit. This should be enough to fix the socket issue.

But as you say, this is a side thing, not the root cause of problems.

> (In reply to Will Woods from comment #21)
> As far as I can tell, the problem is that systemd never gets notification
> that udevd (and/or journald?) have started - which is why systemd keeps
> trying to restart it.
systemd notify socket is not opened properly. From the attached logs:

May 21 03:38:59 localhost.localdomain systemd[1]: bind() failed: Address already in use

I think that this is the real problem. Most likely, the notify socket is serialized but not deserialized properly, so the second systemd has it open but is not aware of it. The code seems correct (and also seems to function correctly most of the time), so I'm really at loss what could be going on
here.

I'll apply a big hammer here and unlink the socket path and attempt to bind again. This might cause a loss of some notify messages, but we should survive that.

> strace shows that udevd is unlinking /run/udev/queue and doing epoll_wait(),
> so it's definitely gotten into the mainloop. But systemctl shows the status
> as "activating (start)", which I'm pretty sure means it's still waiting for
> the sd_notify(1, "READY=1")..
> 
> But then eventually the watchdog timeout hits, and systemd kills the
> existing job and tries to restart udevd. Hence the loop.
This is consistent with systemd not receiving notify messages.

Comment 30 Will Woods 2014-10-16 19:12:59 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #29)
> > (In reply to Will Woods from comment #21)
> > As far as I can tell, the problem is that systemd never gets notification
> > that udevd (and/or journald?) have started - which is why systemd keeps
> > trying to restart it.
> systemd notify socket is not opened properly. From the attached logs:
> 
> May 21 03:38:59 localhost.localdomain systemd[1]: bind() failed: Address
> already in use
> 
> I think that this is the real problem. Most likely, the notify socket is
> serialized but not deserialized properly, so the second systemd has it open
> but is not aware of it. The code seems correct (and also seems to function
> correctly most of the time), so I'm really at loss what could be going on
> here.

Keep in mind that upgrades involve two versions of systemd - the initramfs is F21 (systemd v215ish) but the system root has systemd v205 (or older), and that's what's doing the deserialization.

Is it possible there have been changes to that code since v205? Or maybe other system changes that would make the bind() fail? Different socket paths? SELinux policy changes?

> I'll apply a big hammer here and unlink the socket path and attempt to bind
> again. This might cause a loss of some notify messages, but we should
> survive that.

If I can help find a more precise fix, let me know.. but otherwise.. hammer away! And thanks for looking into this.

Comment 31 Zbigniew Jędrzejewski-Szmek 2014-10-16 21:12:33 UTC
(In reply to Will Woods from comment #30)
> Keep in mind that upgrades involve two versions of systemd - the initramfs
> is F21 (systemd v215ish) but the system root has systemd v205 (or older),
> and that's what's doing the deserialization.
I was think so too, but actually in the posted logs both versions are the
same (212). The location of the socket and other things changed in between
systemd version, but I don't think this is relevant here.

Comment 32 Will Woods 2014-10-17 00:42:01 UTC
Right, but the logs might not be reliable - aren't we not getting logs from v205 because of the /dev/log funnies? The entire process goes:

F21 initramfs -> F20 system (bring up disks) -> F21 initramfs (start upgrade)

So we'd normally expect to see v212 starting up twice with v205 in the middle, but if v205 can't log properly..

Comment 33 Zbigniew Jędrzejewski-Szmek 2014-10-17 01:49:59 UTC
A test build is here http://koji.fedoraproject.org/koji/taskinfo?taskID=7889255.

So, systemd that has issues is the one from the fedup initramfs. I'm not sure how to test that this now. Normal F21 installation boots fine with this update, so I'd be inclined to just push it and assume that it fixes this bug. It only contains for patches, one to increase logging, one for the /dev/log issue from this bug, and two for other issues. Please advise.

Comment 34 Jaroslav Reznik 2014-10-17 08:25:11 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #33)
> A test build is here
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7889255.
> 
> So, systemd that has issues is the one from the fedup initramfs. I'm not
> sure how to test that this now. Normal F21 installation boots fine with this
> update, so I'd be inclined to just push it and assume that it fixes this
> bug. It only contains for patches, one to increase logging, one for the
> /dev/log issue from this bug, and two for other issues. Please advise.

What are two other issues? Just to avoid surprises if it's anything bigger that can affect Beta. And thanks for attention to this bug!

Comment 35 Zbigniew Jędrzejewski-Szmek 2014-10-17 13:05:34 UTC
From the attached logs:

From this bug:
May 21 03:38:59 localhost.localdomain systemd[1]: bind() failed: Address already in use

Patch #1 removes the notification socket and binds again.

From 1146140 (one of the duplicates):

Jan 13 20:37:03 raptor systemd[1]: Switching root.
Jan 13 20:37:03 raptor systemd[1]: Failed to umount old root dir /system-upgrade-root/mnt: No such file or directory
Jan 13 20:37:03 raptor systemd[1]: Failed to switch root, ignoring: No such file or directory

Patch #2 only warns about the unmount failing and continues to boot from the new root.

From comment #20:
F20 systemd (v205) has `systemd-journald.socket`, which creates /dev/log.
F21 systemd (v215) has `systemd-journald-dev-log.socket`, which creates /run/systemd/journal/dev-log and symlinks /dev/log to it.
So when we switch from F20 to F21, systemd-journald-dev-log.socket fails because it can't make the symlink.

Patch #3 removes /dev/log before attempting to create the symlink.

Patch #4 replaces some log_debug with log_warning.

Comment 36 Adam Williamson 2014-10-17 19:34:08 UTC
releng should be able to build a test upgrade image for us, I believe, if we ask. CCing releng folks.

Comment 37 Adam Williamson 2014-10-17 19:34:39 UTC
changing version to 21, as the fix needs to go in 21/Rawhide AIUI, not 20.

Comment 38 Kevin Fenzi 2014-10-19 16:58:57 UTC
(In reply to Adam Williamson (Red Hat) from comment #36)
> releng should be able to build a test upgrade image for us, I believe, if we
> ask. CCing releng folks.

I think the easiest way to test this would be to submit an update with the fix, and add a buildroot override, then check the next days nightly compose. I think the compose should use the buildroot override version and you should be able to test the upgrade.img there.

Comment 39 Adam Williamson 2014-10-20 23:38:48 UTC
I tried testing this with a locally-built upgrade.img but it segfaults, I'm guessing I just don't have a full/clean creation environment. zbysek, could you just submit the build as an update and we'll run the next TC/RC build with it and hope it does the job? Thanks.

Comment 40 Fedora Update System 2014-10-21 11:58:15 UTC
initscripts-9.56.1-2.fc21, systemd-216-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/FEDORA-2014-12688/initscripts-9.56.1-2.fc21,systemd-216-5.fc21

Comment 41 Fedora Update System 2014-10-21 17:25:05 UTC
Package initscripts-9.56.1-2.fc21, systemd-216-5.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.56.1-2.fc21 systemd-216-5.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12688/initscripts-9.56.1-2.fc21,systemd-216-5.fc21
then log in and leave karma (feedback).

Comment 42 Patrick 2014-10-24 01:34:13 UTC
I'm confused about how to test it. The problem is that fedup won't upgrade from 20 to 21, and I'm still on 20. I don't see how I can install initscripts and systemd from 21's updates-testing repository when I'm not on 21.

Comment 43 Zbigniew Jędrzejewski-Szmek 2014-10-24 01:39:20 UTC
When updates systemd is in upgrade.img, the upgrade should succeed. So the test is to wait for upgrade.img to be released and then try to upgrade. I'm not sure when the updated upgrade.img will be crated.

Comment 44 Adam Williamson 2014-10-24 01:53:52 UTC
There will be an updated upgrade.img as part of the 21 Beta RC1 compose, inside the 21 Beta RC1 tree in stage/. The upgrade.img in the development/21 tree on the mirrors will get the change once it reaches stable. Assuming the fix works, the /releases/test/21-Beta tree on the mirrors will also contain a fixed upgrade.img when it comes into being (at the release of Beta).

Comment 45 Adam Williamson 2014-10-24 10:26:59 UTC
I confirmed this is fixed with Beta RC1. A fedup run against the Beta_RC1 tree works successfully.

Comment 46 Fedora Update System 2014-10-28 21:49:26 UTC
initscripts-9.56.1-2.fc21, systemd-216-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 47 Bill Gianopoulos 2014-10-28 22:52:37 UTC
This bug need to be reopened until you are either willing or able to provide a fedup command that will actually work.  The one I complained about in bug 1146219 still fails with the same issue.

Comment 48 Bill Gianopoulos 2014-10-28 22:53:49 UTC
Oh and the one you suggested does not work either because the repository does not exist.

Comment 49 Bill Gianopoulos 2014-10-28 22:55:15 UTC
I don;t intend to be a hard-ass about this but it is close to beta release and I could test this on various platforms if you would explain exactly how that is actually possible.

Comment 50 Bill Gianopoulos 2014-10-28 23:17:06 UTC
I submitted Bug 1158246 on this issue.

Comment 51 Adam Williamson 2014-10-28 23:31:43 UTC
fedup --network 21 --instrepo https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/

Comment 52 Adam Williamson 2014-10-28 23:36:24 UTC
Note that if you try that and have any issue *other* than the loop when starting udev, that is not the same bug as this one. There are some other known issues in fedup at present that are not this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1038413
https://bugzilla.redhat.com/show_bug.cgi?id=1153816

if you hit one of those, please follow that report. If you hit something else, please check https://bugz.fedoraproject.org/fedup and if you don't see it there, file a new report. Thanks.

Comment 53 Bill Gianopoulos 2014-10-29 00:19:34 UTC
OK no that is what I would have liked to have seen in the bug close report.  Going to beta in a week need to get enough info to people like me to test before then.  Just tying to say, this is an open source project with an open attitude towards who can contribute. Especially in a situation where we took more time for this release than normal and the release is months behind.  now that we are within a week of the release better to get input than to look really stupid.

Comment 54 Bill Gianopoulos 2014-10-29 00:20:51 UTC
Oh just to give a frame of reference I do work on another open source project where we also look stupid  in this same manner.  just trying to say we need to try to avoid this issue.

Comment 55 Adam Williamson 2014-10-29 01:30:24 UTC
The fedup test cases do actually include the instructions:

https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop

Comment 56 Bill Gianopoulos 2014-10-29 01:36:34 UTC
I did use the instructions here and that worked for me.  But I do feel that my bug 1146219 was duped to this and therefore closed without what I feel was an adequate answer.  You can easily disagree but my feeling is this is an open source project and if people complain about an issue and are trying to help get things resolved before beta you should help instead of hinder their efforts.

 Just my opinion,  I am probably wrong!

Comment 57 Adam Williamson 2014-10-29 01:55:24 UTC
I'm sorry, but I don't know what 'adequate answer' you were expecting - that bug is clearly the same bug as this bug, I thought that was sufficiently self-evident not to need a comment.

Comment 58 Hubert Figuiere 2014-10-29 08:20:39 UTC
I confirm that this specific problem has been addressed. It lead to a bunch of others, but that's another story.

Comment 59 Bill Gianopoulos 2014-10-29 11:03:33 UTC
(In reply to Adam Williamson (Red Hat) from comment #57)
> I'm sorry, but I don't know what 'adequate answer' you were expecting - that
> bug is clearly the same bug as this bug, I thought that was sufficiently
> self-evident not to need a comment.

I apologize.  I had misread a comment and thought this was also fixed in the current test/21-Alpha build.

Comment 60 Lukas Brabec 2014-10-29 14:34:09 UTC
Reopening, this bug is still/again in F21 Beta RC2 (encountered with colleague on bare metal and virtualized).

Comment 61 Lukas Brabec 2014-10-29 14:35:12 UTC
Created attachment 951811 [details]
Fedup log

Comment 62 Lukas Brabec 2014-10-29 14:36:44 UTC
Created attachment 951812 [details]
Photo of fail messages

Comment 63 Zbigniew Jędrzejewski-Szmek 2014-10-29 16:17:55 UTC
(In reply to Lukas Brabec from comment #62)
> Created attachment 951812 [details]
> Photo of fail messages
It's the old systemd that is failing, I guess when it switches back to F20 system to mount stuff. It seems that I should do an update for F20 with those patches which were applied to F21. Should be ready tonight.

Comment 64 Adam Williamson 2014-10-29 16:50:48 UTC
It turns out the problem here was a SNAFU in RC2 compose: due to an unfortunate timing overlap, RC2 got the old systemd / initscripts builds without the fix for this. There's no work to do for the devs here, we just need to spin a new RC with the fix properly included.

Comment 65 Zbigniew Jędrzejewski-Szmek 2014-10-30 05:30:22 UTC
'fedup --network 21 --instrepo ...RC4/...' seems to work fine.

Comment 66 Petr Schindler 2014-10-30 08:13:52 UTC
It works for me with RC4. I tried fedup 0.9.


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