Bug 968267

Created attachment 754294 [details]
dmesg output after rebooting

It is also suspicious that I see /system-upgrade symlink, but systemd-system-update-generator.1 speaks about /system-update symlink.

Same issue for me :-(

(In reply to Honza Horak from comment #2)
> It is also suspicious that I see /system-upgrade symlink, but
> systemd-system-update-generator.1 speaks about /system-update symlink.

Upgrades and updates are different. systemd-system-update-generator is for updates, not upgrades. It's not relevant. More info here:
  http://freedesktop.org/wiki/Software/systemd/SystemUpdates/


Anyway: according to dmesg, your kernel command line is: 

BOOT_IMAGE=/vmlinuz-fedup root=/dev/mapper/vg_main-third_root ro log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg rhgb

Where's "systemd.unit=system-upgrade.target"? That's (currently) how we start the upgrade.

Does your grub.cfg/grub2.cfg have "systemd.unit=system-upgrade.target" in it?

Can you attach your fedup.log?

Hi, 
During the first reboot, when rpm transaction begin I saw a message about a readonly file system but is too fast to read since machine reboots.
Hopefully that this could help.

Created attachment 754513 [details]
fedup.log

Another detail: Expect that /boot partition, I've all partitions crypted with luks, in fact during system update boot it asks me password and goes on correctly.

(In reply to Will Woods from comment #4)
> (In reply to Honza Horak from comment #2)
> > It is also suspicious that I see /system-upgrade symlink, but
> > systemd-system-update-generator.1 speaks about /system-update symlink.
> 
> Upgrades and updates are different. systemd-system-update-generator is for
> updates, not upgrades. It's not relevant. More info here:
>   http://freedesktop.org/wiki/Software/systemd/SystemUpdates/
> 
> 
> Anyway: according to dmesg, your kernel command line is: 
> 
> BOOT_IMAGE=/vmlinuz-fedup root=/dev/mapper/vg_main-third_root ro
> log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg rhgb
> 
> Where's "systemd.unit=system-upgrade.target"? That's (currently) how we
> start the upgrade.
> 
> Does your grub.cfg/grub2.cfg have "systemd.unit=system-upgrade.target" in it?

It didn't, but I've found a reason and a work-around. The problem was that there was actually not even fedup entry in grub.cfg (I'm using grub2), so fedup didn't have a place to add system-upgrade.target. Actually, I have the same problem with new kernel - the grub2 menu is not recreated after installing a new kernel and I have to do i t manually.

So in case of fedup I fist re-created the grub2 menu (grub2-mkconfig -o /etc/grub2.cfg) and then run fedup egain and after it grub2.cfg includes even "systemd.unit=system-upgrade.target".

I'll proceed with upgrading later and see how it'll work, but a current question is -- who should actually upgrade grub2 menu after installing either vmlinuz-fedup image or new kernel? I don't see any grub2-mkconfig call in fedup code for example.

fedup calls `new-kernel-pkg`:

  https://github.com/wgwoods/fedup/blob/0.7.3/fedup/boot.py#L31

which (as you might guess) is the same thing that happens when you install a new kernel package. `new-kernel-pkg` figures out which bootloader you're using, and calls `grubby` as appropriate to update the bootloader config.

But if grubby doesn't understand your bootloader config, new-kernel-pkg *silently fails*. Which is what happened to you, I'm guessing.

Do you happen to have a copy of the grub2.cfg from *before* you re-ran grub2-mkconfig?

Created attachment 755353 [details]
grub.cfg file before running grub2-mkconfig

(In reply to Will Woods from comment #9)
> Do you happen to have a copy of the grub2.cfg from *before* you re-ran
> grub2-mkconfig?

I believe the attached is what you asked.

Hello,
I had also the problem of the /boot/grub2/grub.cfg file not updated by fedup :(
I've ran manually :
grub2-mkconfig -o /boot/grub2/grub.cfg
as explained on http://fedoraproject.org/wiki/GRUB_2
and everytime I run fedup there is no modification to the /boot/grub2/grub.cfg file
So now I'm trying to run manually new-kernel-pkg to see if it prints some error.
I've run grub2-mkconfig first because when I've installed the update of the kernel it didn't update the grub menu too :(

when I run this command :
new-kernel-pkg -v --initrdfile /boot/initramfs-fedup.img --banner "System upgrade" --kernel-args "upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0" --make-default --install fedup
it prints this error :
initrdfile is /boot/initramfs-fedup.img
found /boot/initramfs-fedup.img and using it with grubby
/etc/grub.conf does not exist, not running grubby for grub 0.97
adding fedup to /boot/grub2/grub.cfg
grubby fatal error: unable to find a suitable template
/etc/grub2-efi.cfg does not exist, not running grubby for grub 2 with UEFI
/etc/lilo.conf does not exist, not running grubby
/etc/extlinux.conf does not exist, not running grubby for extlinux

So it confirms grubby is unable to find a suitable place in the file generated by grub2-mkconfig

But when I run this command:
grubby --initrd=/boot/initramfs-fedup.img --title="System upgrade" --args="root=UUID=2604dc79-1112-4f84-b172-20abb9eaaa80 ro rootflags=subvol=root upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0" --add-kernel=/boot/vmlinuz-fedup --grub2

I don't have errors and it adds well this to /boot/grub2/grub.cfg :
menuentry 'System upgrade' --class gnu-linux --class gnu --class os {
 	linux /boot/vmlinuz-fedup root=UUID=2604dc79-1112-4f84-b172-20abb9eaaa80 ro rootflags=subvol=root upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0
 	initrd /boot/initramfs-fedup.img
}

So it seems to be bug in new-kernel-pkg and not in grubby itself. I suppose new-kernel-pkg calls grubby for GRUB1 and not for GRUB2.

I've added these lines just after the menuentry line because without them it can't find the files :(
        insmod part_msdos
        insmod btrfs
        set root='hd0,msdos5'
Sorry for spamming this bug report :P

(In reply to Honza Horak from comment #8)
> (In reply to Will Woods from comment #4)
> > Does your grub.cfg/grub2.cfg have "systemd.unit=system-upgrade.target" in it?
> 
> It didn't, but I've found a reason and a work-around. The problem was that
> there was actually not even fedup entry in grub.cfg (I'm using grub2), so
> fedup didn't have a place to add system-upgrade.target.

Potentially same problem as in bug 991822 (?)

> Actually, I have the
> same problem with new kernel - the grub2 menu is not recreated after
> installing a new kernel and I have to do i t manually.

Me, too (in F18).

So the problem here is that grubby (for whatever reason) doesn't understand your existing grub2.cfg.

Reassigning to grubby.

If you're having this problem, please attach your grub2.cfg to help debug this problem. Thanks.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.