Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 965897 - systemd's kernel-install calls new-kernel-pkg with wrong parameters
Summary: systemd's kernel-install calls new-kernel-pkg with wrong parameters
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2013-05-21 23:19 UTC by Brendan Conoboy
Modified: 2013-06-03 15:56 UTC (History)
13 users (show)

Fixed In Version: systemd-204-4.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-28 09:27:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Call new-kernel-pkg with --update instead of --install (deleted)
2013-05-21 23:19 UTC, Brendan Conoboy
no flags Details | Diff

Description Brendan Conoboy 2013-05-21 23:19:52 UTC
Created attachment 751443 [details]
Call new-kernel-pkg with --update instead of --install

The 3.9 kernel series and earlier called /sbin/new-kernel-pkg directly as part of posttrans.  As of 3.10 the kernel calls /bin/kernel-install which then calls /sbin/new-kernel-pkg.  The invocation of new-kernel-pkg uses a different, incompatible, set of arguments than were used in 3.9.

How it was handled in 3.9's posttrans:

/sbin/new-kernel-pkg --package $kernelpkg --mkinitrd --dracut --depmod --update $kernelnvr || exit $?
/sbin/new-kernel-pkg --package $kernelpkg--rpmposttrans $kernelnvr || exit $?

How it is handled in kernel-install:

/sbin/new-kernel-pkg --package $kernelpkg --mkinitrd --dracut --depmod --install "$2" || exit $?
/sbin/new-kernel-pkg --package $kernelpkg --rpmposttrans "$2" || exit $?

As you can see, new-kernel-pkg is being called with --install instead of with --update.  This breaks, at minimum, installing kernels on ARM systems since some of the necessary configuration management only runs when --update is used.

The attached one-liner fixes the issue.

Comment 1 Kay Sievers 2013-05-22 22:00:45 UTC
http://koji.fedoraproject.org/koji/buildinfo?buildID=421077

Thanks!

Comment 2 Fedora Update System 2013-05-23 06:49:45 UTC
systemd-204-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-204-3.fc19

Comment 3 Fedora Update System 2013-05-23 19:58:44 UTC
Package systemd-204-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-204-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8993/systemd-204-3.fc19
then log in and leave karma (feedback).

Comment 4 Kevin Fenzi 2013-05-23 21:04:50 UTC
Hum. 

[root@jelerak ~]# /bin/kernel-install add 3.10.0-0.rc2.git1.1.fc20.x86_64 /boot/vmlinuz-3.10.0-0.rc2.git1.1.fc20.x86_64 
depmod: WARNING: could not open /lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.order: No such file or directory
depmod: WARNING: could not open /lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.builtin: No such file or directory
depmod: WARNING: could not open /var/tmp/initramfs.RES8tO/lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.order: No such file or directory
depmod: WARNING: could not open /var/tmp/initramfs.RES8tO/lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.builtin: No such file or directory
[root@jelerak ~]# grep kernel-3.10.0-0.rc2.git1.1 /etc/grub2.cfg 

Doesn't seem to be working right here. :( 

This is rawhide, but same systemd version: 

systemd-204-3.fc20.x86_64

Comment 5 Kevin Fenzi 2013-05-23 21:10:29 UTC
I see. The patch was never actually applied in the spec file. ;) 

If you like I can do so, or you can and push out a new rawhide / f19 versions?

Comment 6 Kay Sievers 2013-05-23 22:00:08 UTC
I *edited* the patch, not *added* it. :)

Why would it be used in F19, this should only affect rawhide, doesn't it?

Initialized empty Git repository in /home/kay/data/fedora/systemd/systemd-204/.git/
+ git config user.email systemd-maint
+ git config user.name 'Fedora systemd team'
+ git add .
+ git commit -a -q -m '204 baseline.'
+ git am /home/kay/data/fedora/systemd/kernel-install-grubby.patch
Applying: kernel-install: add fedora specific callouts to new-kernel-pkg
+ exit 0

Comment 7 Jóhann B. Guðmundsson 2013-05-23 22:29:19 UTC
Alot of us in the QA community have fedora-rawhide-kernel-nodebug repo install or just generally run the latest kernel to test on our workstation and doing so on F18 yields this these days since the kernel has started to have hard dependency on specific dracut/systemd releases 

--> Finished Dependency Resolution
Error: Package: kernel-3.10.0-0.rc2.git0.4.fc20.x86_64 (fedora-rawhide-kernel-nodebug)
           Requires: systemd >= 203-2
           Installed: systemd-201-2.fc18.7.x86_64 (@updates-testing)
               systemd = 201-2.fc18.7
           Available: systemd-195-15.fc18.x86_64 (fedora)
               systemd = 195-15.fc18
Error: Package: kernel-3.10.0-0.rc2.git0.4.fc20.x86_64 (fedora-rawhide-kernel-nodebug)
           Requires: dracut >= 027
           Installed: dracut-024-25.git20130205.fc18.x86_64 (@updates)
               dracut = 024-25.git20130205.fc18
           Available: dracut-024-18.git20130102.fc18.x86_64 (fedora)
               dracut = 024-18.git20130102.fc18
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

so we should or rather need to start considering syncing better the updates strategy of the core/base OS releases to GA ( F18/F19+ ) at least come up with somekind of strategy/plan involving updating the kernel/dracut/systemd/util-linux etc.probably an topic for guadec if all the relevant parties are there.

Comment 8 Kevin Fenzi 2013-05-23 22:45:57 UTC
(In reply to Kay Sievers from comment #6)
> I *edited* the patch, not *added* it. :)
> 
> Why would it be used in F19, this should only affect rawhide, doesn't it?

ok. I see the setup now... :) 

So, yes, the patch was changed was applied, but doesn't seem to work here. 

It never adds the new kernel to grub. 

[root@jelerak ~]# sh -x /bin/kernel-install add 3.10.0-0.rc2.git1.1.fc20.x86_64 /boot/vmlinuz-3.10.0-0.rc2.git1.1.fc20.x86_64 
+ [[ -x /sbin/new-kernel-pkg ]]
+ case "$1" in
+ /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.10.0-0.rc2.git1.1.fc20.x86_64
depmod: WARNING: could not open /lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.order: No such file or directory
depmod: WARNING: could not open /lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.builtin: No such file or directory
depmod: WARNING: could not open /var/tmp/initramfs.cuyYn4/lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.order: No such file or directory
depmod: WARNING: could not open /var/tmp/initramfs.cuyYn4/lib/modules/3.10.0-0.rc2.git1.1.fc20.x86_64/modules.builtin: No such file or directory
+ /sbin/new-kernel-pkg --package kernel --rpmposttrans 3.10.0-0.rc2.git1.1.fc20.x86_64
+ [[ -d /boot/loader/entries ]]
+ [[ -L /boot/loader/entries ]]
+ exit 0

So, this seems now to be a bug in /sbin/new-kernel-pkg / grubby?

Comment 9 Fedora Update System 2013-05-26 03:43:46 UTC
systemd-204-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Bruno Wolff III 2013-05-26 19:35:44 UTC
I don't think grubby has changed since things starting breaking. For a while kernel-install was sort of working (not for PAE kernels, see bug 964023), but now grub.conf files are not getting updated.

Comment 11 Kevin Fenzi 2013-05-28 02:19:35 UTC
This is still not right. ;) 

Old kernels: 

postinstall scriptlet (using /bin/sh):

if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
   [ -f /etc/sysconfig/kernel ]; then
  /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi

/sbin/new-kernel-pkg --package kernel --install 3.9.4-200.fc18.x86_64 || exit $?
preuninstall scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 3.9.4-200.fc18.x86_64 || exit $?
posttrans scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.9.4-200.fc18.x86_64 || exit $?
/sbin/new-kernel-pkg --package kernel --rpmposttrans 3.9.4-200.fc18.x86_64 || exit $?

new kernels: 

postinstall scriptlet (using /bin/sh):

if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
   [ -f /etc/sysconfig/kernel ]; then
  /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi
preuninstall scriptlet (using /bin/sh):
/bin/kernel-install remove 3.10.0-0.rc2.git1.2.fc20.x86_64 /boot/vmlinuz-3.10.0-0.rc2.git1.2.fc20.x86_64 || exit $?
posttrans scriptlet (using /bin/sh):
/bin/kernel-install add 3.10.0-0.rc2.git1.2.fc20.x86_64 /boot/vmlinuz-3.10.0-0.rc2.git1.2.fc20.x86_64 || exit $?

system's /bin/kernel-install is only being called in posttrans now, and only doing 'update' which does nothing at all since the entry was never added. Old kernels called install in post, then update in posttrans. So, either the kernel needs to call /bin/kernel-install with a install argument in post, or /bin/kernel-install needs to install and update in posttrans. 

Happy to gather more info or whatnot, but rawhide kernels are never updating now, which is kinda anoying. ;)

Comment 12 Adam Williamson 2013-05-28 02:40:26 UTC
kay: in addition to what others have said, F19 will certainly be rebased to kernel 3.10 post-release, so we may as well fix this there now.

Comment 13 Peter Robinson 2013-05-28 08:13:12 UTC
(In reply to Adam Williamson from comment #12)
> kay: in addition to what others have said, F19 will certainly be rebased to
> kernel 3.10 post-release, so we may as well fix this there now.

When the kernel is rebased the kernel.spec or major changes generally are not so the mechanism used for kernel installs should remain as it is now for the lifecycle of F-19.

Comment 14 Harald Hoyer 2013-05-28 09:27:39 UTC
(In reply to Kevin Fenzi from comment #11)
> system's /bin/kernel-install is only being called in posttrans now, and only
> doing 'update' which does nothing at all since the entry was never added.
> Old kernels called install in post, then update in posttrans. So, either the
> kernel needs to call /bin/kernel-install with a install argument in post, or
> /bin/kernel-install needs to install and update in posttrans. 

kernel-install now does "--install" and "--update" and "--posttrans" in posttrans.

3 calls to /sbin/new-kernel-pkg to do a simple job :-/

Comment 15 Bruno Wolff III 2013-05-28 13:31:08 UTC
People have been encouraged to test rawhide kernels in f19. It would be nice to keep it easy to keep using them. (Copying over the config entries by hand is a pain.)

Comment 16 Adam Williamson 2013-05-29 16:22:33 UTC
Does the new mechanism respect configuration set in /etc/sysconfig/kernel ?

Comment 17 Brendan Conoboy 2013-05-29 19:27:38 UTC
Please also queue this fix for F19.

Comment 18 Peter Robinson 2013-05-29 19:30:48 UTC
(In reply to Brendan Conoboy from comment #17)
> Please also queue this fix for F19.

kernel-install is currently only being used on rawhide so there is no fix needed for F-19

Comment 19 Brendan Conoboy 2013-05-29 19:32:38 UTC
The kernel-install script is being used by the 3.10 kernel which will land in F19 post-release.

Comment 20 Peter Robinson 2013-05-29 19:39:16 UTC
(In reply to Brendan Conoboy from comment #19)
> The kernel-install script is being used by the 3.10 kernel which will land
> in F19 post-release.

Not necessarily. It's a patch being applied to the rawhide kernel that won't necessarily be merged back to F-19. It was my understanding that the request was just for rawhide to get wider testing. Maybe the kernel team can clarify this

[1] http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?id=6d752ab3ea52e9562776f850f7b884824aea7a21

Comment 21 Josh Boyer 2013-05-29 19:54:23 UTC
(In reply to Peter Robinson from comment #20)
> (In reply to Brendan Conoboy from comment #19)
> > The kernel-install script is being used by the 3.10 kernel which will land
> > in F19 post-release.
> 
> Not necessarily. It's a patch being applied to the rawhide kernel that won't
> necessarily be merged back to F-19. It was my understanding that the request
> was just for rawhide to get wider testing. Maybe the kernel team can clarify
> this
> 
> [1]
> http://pkgs.fedoraproject.org/cgit/kernel.git/commit/
> ?id=6d752ab3ea52e9562776f850f7b884824aea7a21

3.10 has nothing to do with kernel-install.  kernel-install is an F20 and beyond change.

Comment 22 Josh Boyer 2013-05-29 19:57:29 UTC
(In reply to Josh Boyer from comment #21)
> (In reply to Peter Robinson from comment #20)
> > (In reply to Brendan Conoboy from comment #19)
> > > The kernel-install script is being used by the 3.10 kernel which will land
> > > in F19 post-release.
> > 
> > Not necessarily. It's a patch being applied to the rawhide kernel that won't
> > necessarily be merged back to F-19. It was my understanding that the request
> > was just for rawhide to get wider testing. Maybe the kernel team can clarify
> > this
> > 
> > [1]
> > http://pkgs.fedoraproject.org/cgit/kernel.git/commit/
> > ?id=6d752ab3ea52e9562776f850f7b884824aea7a21
> 
> 3.10 has nothing to do with kernel-install.  kernel-install is an F20 and
> beyond change.

That being said, if it continues to remain broken in rawhide we'll revert the kernel.spec changes.  The intention is to get it working in rawhide ASAP so that it's fixed well before F20 is released.

Comment 23 Bruno Wolff III 2013-06-03 15:56:29 UTC
It looks like a fixed systemd got built for f19 today. Thanks.


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