Description of problem: When upgrading using fedup and using the RC1 upgrade.img, there's no plymouth splash displayed, but just console output. But when I've built my own upgrade.img and tried to use it, I see nice fedup splash showing progress. There has to be a problem somewhere either in fedup-dracut or in the upgrade.img build process. The build process seems plausible, because when I build the upgrade.img locally and don't have fedup-dracut-plymouth package installed, I see this: modifying plymouthd.conf: Theme=fedup grep: /usr/share/plymouth/themes/fedup/fedup.plymouth: No such file or directory The default plymouth plugin () doesn't exist So maybe fedup-dracut-plymouth is not installed on the machine (in the chroot) where upgrade.img is being built? Version-Release number of selected component (if applicable): fedup-dracut-0.9.2-1.fc22 How reproducible: always Steps to Reproduce: 1. run `fedup --network 22 --instrepo http://dl.fedoraproject.org/pub/alt/stage/22_RC1/Workstation/x86_64/os/` , see no splash 2. build your own upgrade.img on F22 using `/usr/share/doc/fedup-dracut/makefeduprepo myrepo` 3. share myrepo over http 4. run `fedup --network 22 --instrepo http://localhost/myrepo`, see splash
Created attachment 1027643 [details] fedup with theme This is how upgrade process looks like with a fedup theme.
Created attachment 1027644 [details] fedup without theme This is how upgrade process looks like without fedup theme.
I think we should consider this as a final blocker, because we're not able to fix this with an update. After the upgrade.img is built, it's set in stone. Unless rel-eng is OK with building a fixed version separate from the RC, and then overwrite it/host it elsewhere and update Mirror Manager (which I don't consider likely).
Changing to distribution, we likely need to see fedup-dracut build logs from RC1. Dennis, or someone else with access, can you take a look?
Created attachment 1027646 [details] upgrade.log from RC1 upgrade This is the upgrade.log from RC1 upgrade which doesn't show the splash. In case it helps debugging why it wasn't shown.
FWIW, I tried using this branched daily compose, which is the last one having images/ directory correctly created: http://koji.fedoraproject.org/mash/branched-20150517/22/x86_64/os/ And the fedup splash is not shown either, even though the build log seems to indicate that fedup-dracut-plymouth was correctly installed: http://koji.fedoraproject.org/mash/branched-20150517/logs/x86_64/x86_64.log But I don't see makefeduprepo output there, so I can't really say if that's the right place where the upgrade.img process happens or not.
Please note that if we don't have this splash, but use console, we're affected by bug 1173135, which might confuse some users and potentially cause data loss - they might get the idea that the upgrade process got broken/corrupted and reset the system in the middle of the operation.
My custom upgrade.img is here, if you want to try out the fedup splash easily, or compare the changes: https://kparal.fedorapeople.org/bugs/rhbz_1223344/repo/
This sounds to me more like a Freeze Exception request than a Blocker bug, to me. It's not any worse than it was in Fedora 21 and the upgrade criteria only states: "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." I'm +1 FE for this if we have a solution in time for the RC2 request today. I'm definitely -1 blocker. There's no reason to delay specifically for this.
Adding FE proposal.
After thinking more about this, I'm retracting the blocker proposal. It is not serious enough to block the release on, it just doesn't paint us a nice picture. However, since we need RC2 anyway, I'd be really glad if this got resolved in it, even if we had to delay the RC2 compose for a few hours. It'd be worth it.
RC1 compose logs are here: https://ausil.fedorapeople.org/22_RC1/ fedup-dracut-plymouth seems to be installed.
plymouth-populate-initrd is supposed to modify etc/plymouth/plymouthd.conf to set Theme=fedup, but.. it isn't. You can check that like so: lsinitrd upgrade.img etc/plymouth/plymouthd.conf and you'll get: # Administrator customizations go in this file #[Daemon] #Theme=fade-in I'm going to attach a patch against plymouth git master that should fix the problem.
Created attachment 1027789 [details] 0001-plymouth-populate-initrd-fix-THEME_OVERRIDE-with-emp.patch Patch against plymouth master; should fix plymouth-populate-initrd so it correctly sets Theme=fedup.
I've tested the patch locally. Before patch: [wwoods@metroid ~]$ sudo PLYMOUTH_THEME_NAME=fedup dracut -f initrd.img && lsinitrd initrd.img etc/plymouth/plymouthd.conf modifying plymouthd.conf: Theme=fedup # Administrator customizations go in this file #[Daemon] #Theme=fade-in After patch: [wwoods@metroid ~]$ sudo PLYMOUTH_THEME_NAME=fedup dracut -f initrd.img && lsinitrd initrd.img etc/plymouth/plymouthd.conf modifying plymouthd.conf: Theme=fedup # Administrator customizations go in this file #[Daemon] #Theme=fade-in [Daemon] # theme modified by plymouth-populate-initrd Theme=fedup halfline has given me the green light to apply and build, so.. imma do that.
+1 FE here.
+1 here as well.
plymouth-0.8.9-9.2013.08.14.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/plymouth-0.8.9-9.2013.08.14.fc22
Package plymouth-0.8.9-9.2013.08.14.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing plymouth-0.8.9-9.2013.08.14.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8625/plymouth-0.8.9-9.2013.08.14.fc22 then log in and leave karma (feedback).
I see a graphical splash when upgrading using RC2 upgrade.img. Yay!
plymouth-0.8.9-9.2013.08.14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.