Bug 1046040
Summary: | fedup boots to my desktop environment instead of upgrading to f20 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dridi Boukelmoune <dridi.boukelmoune> |
Component: | fedup | Assignee: | Will Woods <wwoods> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | charkins, kevin.hobbs.1, rshutt, tflink, wwoods |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-01-17 22:45:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dridi Boukelmoune
2013-12-23 11:05:10 UTC
(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 *** |