Description of problem: One of my laptops won't upgrade to heisenbug. Instead of upgrading, it simply starts services up to the point where the usual DE is loaded and the login screen appears. If I login from there, I've noticed that stuff like wifi won't work, but anyway, I can still boot to f19 where everything is still fine. Version-Release number of selected component (if applicable): 0.8.0-3.fc19 How reproducible: Always. I've tried to clear the boot partition, reinstall fedup and even clean the rpm/ramfs cache but it consistently behaves as described. Steps to Reproduce: 1. sudo yum upgrade 2. sudo yum install fedup 3. sudo fedup --network 20 4. reboot the machine Yeah I know I love sudo :) Actual results: Login on a partially broken environment (eg. wifi not working). Expected results: Heisenbug, like my other laptop ^^ Additional info: Since I don't know what would be useful, I'll wait and stop trying to upgrade until you ask me.
(In reply to Dridi Boukelmoune from comment #0) > Description of problem: > Instead of upgrading, it > simply starts services up to the point where the usual DE is loaded and the > login screen appears. Dridi, does the FedUp option appear in the grub menu? There is a common bug where an old grub uses an old configuration that is not modified by FedUp. I'm having a similar problem but F18 -> F19, and fedup-0.8.0-3.fc18.noarch and I do : sudo fedup-cli --nogpgcheck --network 19 --debuglog fedup.log I get the new fedup entry in the grub menu but the system starts up mostly normally. When I examine /boot/grub2/grub.cfg I see that there is no upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0 option added to the kernel arguements.
(In reply to Kevin Hobbs from comment #1) > Dridi, does the FedUp option appear in the grub menu? Yes it does. > When I examine /boot/grub2/grub.cfg I see that there is no > > upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0 > > option added to the kernel arguements. In grub.cfg I have this: menuentry 'System Upgrade (fedup)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-UUID1' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos5' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 --hint='hd0,msdos5' UUID2 else search --no-floppy --fs-uuid --set=root UUID2 fi echo 'Loading System Upgrade (fedup)' linux /vmlinuz-fedup root=/dev/mapper/my_vg-root_lv ro rd.lvm.lv=my_vg/usr_lv rd.md=0 rd.dm=0 vconsole.keymap=fr rd.luks=0 rd.lvm.lv=my_vg/root_lv rhgb quiet LANG=en_US.UTF-8 echo 'Loading initial ramdisk ...' initrd /initramfs-fedup.img }
For upgrades to F20, those boot arguments aren't required anymore. So something else is going on. F18→F19 is a different problem - see bug 1054988. Otherwise this seems to be the same as bug 1046347. *** This bug has been marked as a duplicate of bug 1046347 ***