[opensuse-kernel] After upgrading Kernel:/stable 4.12.x -> 4.13.x, boot reproducible fails to dracut emergency shell. "busname"?
Hi, After upgrading from Kernel:/stable 4.12.x -> 4.13.x, on Leap 42.3, the system no longer boots -- instead drops to dracut emergency shell. Unfortunately, at shell, I've got no keyboard, and I have no serial port, so having some challenges GRABBING the early logs to share. I turned on more verbose logging. At boot, although without keyboard I can't, unfortunately INTERRUPT it on screen, I DO see an ENORMOUS amount of output (moving by VERY quickly ...) re: "dracut-initqueue" and something about "settled" ... Rebooting to 4.12.x, and checking prior boot, in journalctl I do NOT see any mention of dracut, but I DO see journalctl -b -1 -- Logs begin at Mon 2016-11-07 13:36:46 PST, end at Tue 2018-03-27 10:17:20 PDT. -- Mar 27 09:37:01 0031.austin.local CRON[2126]: (CRON) ERROR chdir failed (/var/lib/amavisd): No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2123]: pam_unix(systemd-user:session): session closed for user amavisd Mar 27 09:37:01 0031.austin.local systemd[2122]: user@5003.service: Executing: /usr/lib/systemd/systemd --user Mar 27 09:37:01 0031.austin.local systemd[2122]: systemd 228 running in user mode for user 5003/amavisd. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) Mar 27 09:37:01 0031.austin.local systemd[2122]: Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd/user.slice/user-5003.slice/user@5003.service. Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'cpu' supported: no Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'cpuacct' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'blkio' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'memory' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'devices' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'pids' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'net_cls' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Set up TFD_TIMER_CANCEL_ON_SET timerfd. Mar 27 09:37:01 0031.austin.local systemd[2122]: Spawned /usr/lib/systemd/user-generators/systemd-dbus1-generator as 2125. Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/lib/systemd/user-generators/systemd-dbus1-generator succeeded. Mar 27 09:37:01 0031.austin.local systemd[2122]: user-generators succeeded. Mar 27 09:37:01 0031.austin.local systemd[2122]: Looking for unit files in (higher priority first): Mar 27 09:37:01 0031.austin.local systemd[2122]: /var/lib/amavisd/.config/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /etc/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /run/user/5003/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /run/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /var/lib/amavisd/.local/share/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/local/share/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/share/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/local/lib/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/lib/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: Unit type .busname is not supported on this system. Mar 27 09:37:01 0031.austin.local systemd[2122]: var.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: var-lib.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: var-lib-amavisd.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: dev.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: dev-mapper.mount: Failed to load configuration: No such file or directory ... This is DIFFERENT that for a successful boot to 4.12.x, where there's no mention of "busname" at all in journalctl I don't know what that busname is. Checking around, I 1st find a [systemd-devel] Failed units and "Unit type .busname is not supported on this system" https://lists.freedesktop.org/archives/systemd-devel/2015-February/028174.ht... >> systemd[1]: Unit type .busname is not supported on this system. >> This may be ignored. >> .busname units are only supported on kdbus systems.> and https://fossies.org/linux/systemd/NEWS CHANGES WITH 219: 3512 * systemd now has an explicit notion of supported and 3513 unsupported unit types. Jobs enqueued for unsupported unit 3514 types will now fail with an "unsupported" error code. More 3515 specifically .swap, .automount and .device units are not 3516 supported in containers, .busname units are not supported on 3517 non-kdbus systems. .swap and .automount are also not 3518 supported if their respective kernel compile time options 3519 are disabled. On this box cd /usr/lib/systemd grep -i busname `grep -rlni busname .` Binary file ./systemd matches ./user/evolution-user-prompter.service:BusName=org.gnome.evolution.dataserver.UserPrompter0 ./user/glib-pacrunner.service:BusName=org.gtk.GLib.PACRunner ./user/evolution-source-registry.service:BusName=org.gnome.evolution.dataserver.Sources5 ./user/at-spi-dbus-bus.service:BusName=org.a11y.Bus ./user/gnome-terminal-server.service:BusName=org.gnome.Terminal ./user/evolution-addressbook-factory.service:BusName=org.gnome.evolution.dataserver.AddressBook9 ./user/evolution-calendar-factory.service:BusName=org.gnome.evolution.dataserver.Calendar7 Binary file ./systemd-coredump matches Binary file ./systemd-machined matches Binary file ./systemd-logind matches Binary file ./system-generators/systemd-debug-generator matches Binary file ./system-generators/systemd-getty-generator matches Binary file ./system-generators/systemd-dbus1-generator matches Binary file ./system-generators/systemd-sysv-generator matches Binary file ./system-generators/systemd-fstab-generator matches Binary file ./system-generators/systemd-hibernate-resume-generator matches Binary file ./system-generators/systemd-insserv-generator matches Binary file ./system-generators/systemd-cryptsetup-generator matches Binary file ./system-generators/systemd-gpt-auto-generator matches Binary file ./systemd-journald matches Binary file ./systemd-udevd matches ./system/wickedd-auto4.service:BusName=org.opensuse.Network.AUTO4 ./system/polkit.service:BusName=org.freedesktop.PolicyKit1 ./system/org.freedesktop.locale1.busname:[BusName] ./system/upower.service:BusName=org.freedesktop.UPower ./system/org.freedesktop.hostname1.busname:[BusName] ./system/wpa_supplicant.service:BusName=fi.w1.wpa_supplicant1 ./system/NetworkManager.service:BusName=org.freedesktop.NetworkManager ./system/wickedd-nanny.service:BusName=org.opensuse.Network.Nanny ./system/wpa_supplicant@.service:BusName=fi.w1.wpa_supplicant1 ./system/geoclue.service:BusName=org.freedesktop.GeoClue2 ./system/wickedd.service:BusName=org.opensuse.Network ./system/org.freedesktop.systemd1.busname:[BusName] ./system/accounts-daemon.service:BusName=org.freedesktop.Accounts ./system/tuned.service:BusName=com.redhat.tuned ./system/systemd-localed.service:BusName=org.freedesktop.locale1 ./system/udisks2.service:BusName=org.freedesktop.UDisks2 ./system/org.freedesktop.timedate1.busname:[BusName] ./system/rtkit-daemon.service:BusName=org.freedesktop.RealtimeKit1 ./system/wickedd-dhcp4.service:BusName=org.opensuse.Network.DHCP4 ./system/systemd-timedated.service:BusName=org.freedesktop.timedate1 ./system/org.freedesktop.network1.busname:[BusName] ./system/colord.service:BusName=org.freedesktop.ColorManager ./system/org.freedesktop.machine1.busname:[BusName] ./system/bluetooth.service:BusName=org.bluez ./system/thermald.service:BusName=org.freedesktop.thermald ./system/systemd-machined.service:BusName=org.freedesktop.machine1 ./system/org.freedesktop.import1.busname:[BusName] ./system/systemd-hostnamed.service:BusName=org.freedesktop.hostname1 ./system/systemd-networkd.service:# On kdbus systems we pull in the busname explicitly, because it ./system/systemd-networkd.service:Wants=org.freedesktop.network1.busname ./system/systemd-networkd.service:After=org.freedesktop.network1.busname ./system/systemd-logind.service:BusName=org.freedesktop.login1 ./system/wickedd-dhcp6.service:BusName=org.opensuse.Network.DHCP6 ./system/systemd-importd.service:BusName=org.freedesktop.import1 ./system/org.freedesktop.login1.busname:[BusName] ./system/NetworkManager-dispatcher.service:BusName=org.freedesktop.nm_dispatcher Binary file ./systemd-update-utmp matches -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Additional info. I've checked booting with all of these kernel versions, from 4.4.120 -> 4.15.2 vmlinuz-4.4.120-45-default vmlinuz-4.15.2-2.gb34965a-default vmlinuz-4.15.3-2.g8d4f579-default vmlinuz-4.15.8-2.g67f0889-default vmlinuz-4.15.9-3.gcddf6d5-default vmlinuz-4.15.10-2.g5e4329c-default vmlinuz-4.15.11-2.ga1db525-default vmlinuz-4.15.12-2.g9f942ce-default and all of them boot just fine. At the moment, it's running on KDE on 4.15.12-2.g9f942ce-default x86_64 On this same machine, all of the 4.15.3 version kernels, vmlinuz-4.15.13-2.g950fc49-default vmlinuz-4.15.13-3.g12abbef-default vmlinuz-4.15.13-4.g580a38a-default fail to boot as reported above. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 28 Mar 2018 01:00:47 +0200, sigise@mailc.net wrote:
Additional info.
I've checked booting with all of these kernel versions, from 4.4.120 -> 4.15.2
vmlinuz-4.4.120-45-default vmlinuz-4.15.2-2.gb34965a-default vmlinuz-4.15.3-2.g8d4f579-default vmlinuz-4.15.8-2.g67f0889-default vmlinuz-4.15.9-3.gcddf6d5-default vmlinuz-4.15.10-2.g5e4329c-default vmlinuz-4.15.11-2.ga1db525-default vmlinuz-4.15.12-2.g9f942ce-default
and all of them boot just fine.
At the moment, it's running on KDE on
4.15.12-2.g9f942ce-default x86_64
On this same machine, all of the 4.15.3 version kernels,
vmlinuz-4.15.13-2.g950fc49-default vmlinuz-4.15.13-3.g12abbef-default vmlinuz-4.15.13-4.g580a38a-default
fail to boot as reported above.
Hm, the diff between 9f942ce and 950fc49 is only 4.15.13 update, so it's likely a regression in 4.15.13 stable. Could you try to bisect? Instead of bisecting expanded tree, you can now bisect manually by disabling patches in series.conf. In series.conf, there are patches.kernel.org/4.15.13-xxx-yyy.patch Put "+bisect" marker (or whatever with '+') to the last half of these patches: patches.kernel.org/4.15.13-042-bpf-cgroup-fix-a-verification-error-for-a-CGR.patch +bisect patches.kernel.org/4.15.13-043-PCI-ASPM-Calculate-LTR_L1.2_THRESHOLD-from-de.patch +bisect patches.kernel.org/4.15.13-044-vgacon-Set-VGA-struct-resource-types.patch ..... +bisect patches.kernel.org/4.15.13-084-Linux-4.15.13.patch and rebuild / retest. If this kernel works, the culprit is in the disabled patches. If it's broken, the culprit is the first half of 4.15.13 patches. And so on. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
I tried a bunch on a different machine, and got similar results except that 4.15.13-2.g950fc49 works. These 4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default still don't. So I wonder if I made a mistake in testing on the 1st machine. As soon as I get back to the office here in a while, I'll retest that g950fc49 kernel and see what happens. For the bisecting, I can try. I've never build a kernel for opensuse before. I'll have to figure out how to use the OBS and get it to build specific revisions. SIgi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Yep, I made a mistake -- maybe just hit the wrong selection in grub menu :-( Anyway, on the machine I reported about 4.15.13-2.g950fc49-default works. 4.15.13 installs after that 4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default don't. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 28 Mar 2018 17:03:29 +0200, sigise@mailc.net wrote:
Yep, I made a mistake -- maybe just hit the wrong selection in grub menu :-(
Anyway, on the machine I reported about
4.15.13-2.g950fc49-default
works. 4.15.13 installs after that
4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default
don't.
OK, that changes the picture completely. The only difference between the above is the kernel config change to enable module signing. Are you booting in secure boot mode? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Checked a couple of other boxes. Just to be clear,
With the 4.15.3 release, all the machines that got upgraded to 4.15.13-2.g950fc49-default are booting fine.
Any that got updated today, after the flurry of commits at
https://github.com/openSUSE/kernel/commits/stable?after=65f5b6872e2fcbee113c...
to 4.15.13-2.g12abbef-default fail to boot -- dropping to dracut emergency shell.
as I originally emailed you is, in fact, still the case. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mittwoch, 28. März 2018 17:26:14 Takashi Iwai wrote:
On Wed, 28 Mar 2018 17:03:29 +0200,
sigise@mailc.net wrote:
Yep, I made a mistake -- maybe just hit the wrong selection in grub menu :-(
Anyway, on the machine I reported about
4.15.13-2.g950fc49-default
works. 4.15.13 installs after that
4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default
don't.
OK, that changes the picture completely. The only difference between the above is the kernel config change to enable module signing.
Suffering from a similar problem, here's a screenshot of the failure. Kernel 4.15.10 works fine, while 4.15.13 does not. I'm tracking Kernel:stable in a local OBS.
Are you booting in secure boot mode?
Is there a way to disable this setting from the kernel command line? Pete
On Thu, 29 Mar 2018 13:58:49 +0200, Hans-Peter Jansen wrote:
On Mittwoch, 28. März 2018 17:26:14 Takashi Iwai wrote:
On Wed, 28 Mar 2018 17:03:29 +0200,
sigise@mailc.net wrote:
Yep, I made a mistake -- maybe just hit the wrong selection in grub menu :-(
Anyway, on the machine I reported about
4.15.13-2.g950fc49-default
works. 4.15.13 installs after that
4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default
don't.
OK, that changes the picture completely. The only difference between the above is the kernel config change to enable module signing.
Suffering from a similar problem, here's a screenshot of the failure.
Kernel 4.15.10 works fine, while 4.15.13 does not.
Definitely something to do with the module signing Jiri recently enabled.
I'm tracking Kernel:stable in a local OBS.
Is it with your locally built kernel (to your own branch)? Or it's built in OBS Kernel:stable? There can be a difference, as both have different keys.
Are you booting in secure boot mode?
Is there a way to disable this setting from the kernel command line?
It doesn't look so. "Module is not signed with expected PKCS#7" implies that a module is wrongly signed, and it's not the case ENOKEY or other error that can be ignored. In anyway, adding Jiri and Joey to Cc, who have better clue. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Donnerstag, 29. März 2018 14:16:15 Takashi Iwai wrote:
On Thu, 29 Mar 2018 13:58:49 +0200,
Hans-Peter Jansen wrote:
On Mittwoch, 28. März 2018 17:26:14 Takashi Iwai wrote:
On Wed, 28 Mar 2018 17:03:29 +0200,
sigise@mailc.net wrote:
Yep, I made a mistake -- maybe just hit the wrong selection in grub menu
:-(
Anyway, on the machine I reported about
4.15.13-2.g950fc49-default
works. 4.15.13 installs after that
4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default
don't.
OK, that changes the picture completely. The only difference between the above is the kernel config change to enable module signing.
Suffering from a similar problem, here's a screenshot of the failure.
Kernel 4.15.10 works fine, while 4.15.13 does not.
Definitely something to do with the module signing Jiri recently enabled.
I'm tracking Kernel:stable in a local OBS.
Is it with your locally built kernel (to your own branch)? Or it's built in OBS Kernel:stable? There can be a difference, as both have different keys.
In my own local OBS, due to other evil stuff, that is needed as well (NVidia, Virtualbox, etc..). Linking from one BS to another has a few downsides, such as revision tracking isn't functional (well, it tracks my own local changes, nothing else..).
Are you booting in secure boot mode?
Is there a way to disable this setting from the kernel command line?
It doesn't look so. "Module is not signed with expected PKCS#7" implies that a module is wrongly signed, and it's not the case ENOKEY or other error that can be ignored.
How do I correctly sign such builds? ATM, it looks, like enabling module signing renders my builds completely useless.
In anyway, adding Jiri and Joey to Cc, who have better clue.
Takashi San, thanks for your support. Much appreciated. Would be glad to here something from the guys with the clue stick, that turn my local builds bootable again. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 29 Mar 2018 15:22:38 +0200, Hans-Peter Jansen wrote:
On Donnerstag, 29. März 2018 14:16:15 Takashi Iwai wrote:
On Thu, 29 Mar 2018 13:58:49 +0200,
Hans-Peter Jansen wrote:
On Mittwoch, 28. März 2018 17:26:14 Takashi Iwai wrote:
On Wed, 28 Mar 2018 17:03:29 +0200,
sigise@mailc.net wrote:
Yep, I made a mistake -- maybe just hit the wrong selection in grub menu
:-(
Anyway, on the machine I reported about
4.15.13-2.g950fc49-default
works. 4.15.13 installs after that
4.15.13-3.g12abbef-default 4.15.13-4.g580a38a-default
don't.
OK, that changes the picture completely. The only difference between the above is the kernel config change to enable module signing.
Suffering from a similar problem, here's a screenshot of the failure.
Kernel 4.15.10 works fine, while 4.15.13 does not.
Definitely something to do with the module signing Jiri recently enabled.
I'm tracking Kernel:stable in a local OBS.
Is it with your locally built kernel (to your own branch)? Or it's built in OBS Kernel:stable? There can be a difference, as both have different keys.
In my own local OBS, due to other evil stuff, that is needed as well (NVidia, Virtualbox, etc..). Linking from one BS to another has a few downsides, such as revision tracking isn't functional (well, it tracks my own local changes, nothing else..).
That explains the possible cause. I forgot the details, but there were changes and requirements relevant with signing with PKCS#7. Was it about the new pesign-obs-integration package? Slipped from my memory, sorry. Other guys can help in this regard, I hope. Takashi
Are you booting in secure boot mode?
Is there a way to disable this setting from the kernel command line?
It doesn't look so. "Module is not signed with expected PKCS#7" implies that a module is wrongly signed, and it's not the case ENOKEY or other error that can be ignored.
How do I correctly sign such builds? ATM, it looks, like enabling module signing renders my builds completely useless.
In anyway, adding Jiri and Joey to Cc, who have better clue.
Takashi San, thanks for your support. Much appreciated. Would be glad to here something from the guys with the clue stick, that turn my local builds bootable again.
Cheers, Pete
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, Mar 29, 2018, at 7:10 AM, Takashi Iwai wrote:
Is it with your locally built kernel (to your own branch)? Or it's built in OBS Kernel:stable?
Fwiw, I see these^ problems with OBS Kernel:Stable builds, and others' branched builds in their home: OBS. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Donnerstag, 29. März 2018 16:10:25 Takashi Iwai wrote:
On Thu, 29 Mar 2018 15:22:38 +0200,
Hans-Peter Jansen wrote:
Suffering from a similar problem, here's a screenshot of the failure.
Kernel 4.15.10 works fine, while 4.15.13 does not.
Definitely something to do with the module signing Jiri recently enabled.
I'm tracking Kernel:stable in a local OBS.
Is it with your locally built kernel (to your own branch)? Or it's built in OBS Kernel:stable? There can be a difference, as both have different keys.
In my own local OBS, due to other evil stuff, that is needed as well (NVidia, Virtualbox, etc..).
That explains the possible cause. I forgot the details, but there were changes and requirements relevant with signing with PKCS#7. Was it about the new pesign-obs-integration package? Slipped from my memory, sorry. Other guys can help in this regard, I hope.
Thank you very much, Takashi San. Building a newer pesign-obs-integration package in the same project did the trick for the new kernel on some old distributions here. (4.15.15 on 13.2) @Jiri: you may want to require a newer pesign-obs-integration package for the binary kernel builds in order to avoid this issue. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun, Apr 1, 2018, at 11:54 AM, Hans-Peter Jansen wrote:
Building a newer pesign-obs-integration package in the same project did the trick for the new kernel on some old distributions here. (4.15.15 on 13.2)
To do that, did you just clone the https://build.opensuse.org/package/show/openSUSE:Leap:15.0:Staging:A/pesign-... packages into your project? Sigi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sonntag, 1. April 2018 12:30:57 sigise@mailc.net wrote:
On Sun, Apr 1, 2018, at 11:54 AM, Hans-Peter Jansen wrote:
Building a newer pesign-obs-integration package in the same project did the trick for the new kernel on some old distributions here. (4.15.15 on 13.2)
To do that, did you just clone the
https://build.opensuse.org/package/show/openSUSE:Leap:15.0:Staging:A/pesign -obs-integration
packages into your project?
I usually link with the devel project package itself in order to notice any regression early: https://build.opensuse.org/package/show/Base:System/pesign-obs-integration Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Pete
I usually link with the devel project package itself in order to notice any regression early: https://build.opensuse.org/package/show/Base:System/pesign-obs-integration
Got it thanks! Can you maybe help explain what you're seeing? Sounds like linking in pesign-obs-integration is needed for you to get past this error, but Jiri's comment sounds like it shouldn't be needed. Downloading latest from Kernel:Stable I'm still seeing the same problem with the hand on boot. So not sure which direction to go in here. Sigi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Montag, 2. April 2018 07:16:06 sigise@mailc.net wrote:
Pete
I usually link with the devel project package itself in order to notice any regression early: https://build.opensuse.org/package/show/Base:System/pesign-obs-integration
Got it thanks!
Can you maybe help explain what you're seeing?
Sounds like linking in pesign-obs-integration is needed for you to get past this error, but Jiri's comment sounds like it shouldn't be needed.
Downloading latest from Kernel:Stable I'm still seeing the same problem with the hand on boot.
So not sure which direction to go in here.
First of all, sorry Sigi, because I see now, that I hijacked this thread, because the failure, you described, looked similar. Unlike your case and as documented by photo, I'm seeing lots of unexpected module signing errors, which could be fixed in the way described. You're seeing something different, that smelled similar, since the revisions, you reported, pointed to the module signing as well. Could you detail the failure case a bit better, probably with a photo as well. Yes, the dysfunctional recovery console is really nagging at this point. It might be a good idea to report a full mkinitrd run for both, the working and the failing set, and a unified diff of both logs. You confused me a bit with the versions of $subject, therefore I fixed them up here. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 04/01/2018, 08:54 PM, Hans-Peter Jansen wrote:
@Jiri: you may want to require a newer pesign-obs-integration package for the binary kernel builds in order to avoid this issue.
Kernel:stable is built against factory, so it uses new enough pesign-obs-integration. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 03/29/2018, 01:58 PM, Hans-Peter Jansen wrote:
Suffering from a similar problem, here's a screenshot of the failure.
Nice, could you grab output of cat /proc/keys? The key should be embed to the kernel. What is your project? Could we handle this further in bugzilla? Has anyone created a bug yet? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Fyi, still happening with 4.15.15-1.1.g4904fc3-default from /Kernel:/stable/standard/x86_64/kernel-default-4.15.15-1.1.g4904fc3.x86_64.rpm I still haven't figure out how to grab any of the log info with no functional keyboard when the problem happens :-/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
until this gets figured out, would it be still possible to get a temporary OBS repo built & published containing all the kernel rpms for the working 4.15.13 g950fc49 , but no longer available, Kernel/stable branch? I'm trying to figure out how to dial back the version using OBS -- and these kernel *specs are a _lot_ more complicated than I'm used to. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sonntag, 1. April 2018 11:50:10 sigise@mailc.net wrote:
until this gets figured out, would it be still possible to get a temporary OBS repo built & published containing all the kernel rpms for the working
4.15.13 g950fc49
, but no longer available, Kernel/stable branch?
I'm trying to figure out how to dial back the version using OBS -- and these kernel *specs are a _lot_ more complicated than I'm used to.
It's not a matter of spec files, more of linking to a specific revision, but I wouldn't invest too much time with this specific version, but raise the number of parallel kernel installs: /etc/zypp/zypp.conf: multiversion.kernels = latest,latest-1,latest-2,latest-3,latest-4,latest-5,latest-6,running or even disable purge-kernels.service for now, to keep the last good one, and examine the failure, you see with the latest available 4.15 kernel.Beware, 4.16 is around the corner... Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Pete,
/etc/zypp/zypp.conf: multiversion.kernels = latest,latest-1,latest-2,latest-3,latest-4,latest-5,latest-6,running
or even disable purge-kernels.service for now, to keep the last good one, and examine the failure, you see with the latest available 4.15 kernel.Beware, 4.16 is around the corner...
Yeah, I do the multiversion bit already. But, I still "lost" something ... in whatever I have left for the 'working' kernel, I can no longer build VirtualBox kernel driver anymore. Tells me I'm missing parts. Maybe the '-macros' packages? Not really sure. I started looking into that, but figured it had to do with having made the mistake of upgrading to these now unbootable kernels' packages. I'm working on getting what diagnostics I can manage, per your earlier message. Sigi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Montag, 2. April 2018 08:20:03 sigise@mailc.net wrote:
Pete,
/etc/zypp/zypp.conf: multiversion.kernels = latest,latest-1,latest-2,latest-3,latest-4,latest-5,latest-6,running
or even disable purge-kernels.service for now, to keep the last good one, and examine the failure, you see with the latest available 4.15 kernel.Beware, 4.16 is around the corner...
Yeah, I do the multiversion bit already.
But, I still "lost" something ... in whatever I have left for the 'working' kernel, I can no longer build VirtualBox kernel driver anymore. Tells me I'm missing parts. Maybe the '-macros' packages? Not really sure.
The kernel-devel packages aren't multiversion for technical reasons. You might need to install the matching package manually. For this very reason, I'm using my own builds, including the kernel and all auxiliary kernel modules. If all this builds fine, it has a good chance to do well, when installed.
I started looking into that, but figured it had to do with having made the mistake of upgrading to these now unbootable kernels' packages.
I'm working on getting what diagnostics I can manage, per your earlier message.
You should mention any deviation from the standard distribution (repos, you don't do tarball installations, do you?). Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
The kernel-devel packages aren't multiversion for technical reasons. You might need to install the matching package manually.
That's my problem. The kernel-devel packages for that still-working-kernel version, 4.15.13-1.g950fc49, aren't available anymore. There are 3 versions in the repos -- *all* of which hang on boot.
For this very reason, I'm using my own builds, including the kernel and all auxiliary kernel modules. If all this builds fine, it has a good chance to do well, when installed.
I tried getting that all running locally before and could never figure out how to get it working. If there's a good step-by-step "building opensuse kernel with local obs" for newbies that you know of ...
You should mention any deviation from the standard distribution (repos, you don't do tarball installations, do you?).
No tarball. Just Kernel:stable repo. BUT ... a friend just gave me a bunch of rpms to try for kernel-default-4.15.15-2.3.g4904fc3.x86_64 kernel-default-devel-4.15.15-2.3.g4904fc3.x86_64 kernel-devel-4.15.15-2.1.g4904fc3.noarch kernel-macros-4.15.15-2.1.g4904fc3.noarch kernel-source-4.15.15-2.1.g4904fc3.noarch kernel-syms-4.15.15-2.1.g4904fc3.x86_64 Supposedly the only difference from Kernel:Stable is the addition of that pesign package to the OBS. And, wouldn't you know it -- it works! uname -rm 4.15.15-2.g4904fc3-default x86_64 Plus, VBox & NVidia modules are buildable again! So, same problem or not, thanks for the 'save'! Now to figure out how to get/build those packages on my own. Cheers, Sigi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Montag, 2. April 2018 09:27:06 sigise@mailc.net wrote:
The kernel-devel packages aren't multiversion for technical reasons. You might need to install the matching package manually.
That's my problem. The kernel-devel packages for that still-working-kernel version, 4.15.13-1.g950fc49, aren't available anymore. There are 3 versions in the repos -- *all* of which hang on boot.
For this very reason, I'm using my own builds, including the kernel and all auxiliary kernel modules. If all this builds fine, it has a good chance to do well, when installed.
I tried getting that all running locally before and could never figure out how to get it working. If there's a good step-by-step "building opensuse kernel with local obs" for newbies that you know of ...
Well, you better start with a OBS build. Sign in to OBS, create a project in your home, link kernel-source from Kernel:stable with osc, and link the other kernel-packages locally, e.g. osc linkpac Kernel:stable kernel-source home:xxxx:Kernel-stable osc linkpac home:xxxx:Kernel-stable kernel-source home:xxxx:Kernel-stable kernel-default osc linkpac home:xxxx:Kernel-stable kernel-source home:xxxx:Kernel-stable kernel-syms You can even link nvidia-gfxG04 from X11:Drivers:Video, but disable build, please. You have to build that one locally. Link x11-video-nvidiaG04 the same way as above. Hope, you get the idea. That's the easiest way to warm up. Setting ub a local OBS isn't that hard, but not _that_ easy, and takes a lot of resources..
You should mention any deviation from the standard distribution (repos, you don't do tarball installations, do you?).
No tarball. Just Kernel:stable repo.
BUT ...
a friend just gave me a bunch of rpms to try for
kernel-default-4.15.15-2.3.g4904fc3.x86_64 kernel-default-devel-4.15.15-2.3.g4904fc3.x86_64 kernel-devel-4.15.15-2.1.g4904fc3.noarch kernel-macros-4.15.15-2.1.g4904fc3.noarch kernel-source-4.15.15-2.1.g4904fc3.noarch kernel-syms-4.15.15-2.1.g4904fc3.x86_64
Supposedly the only difference from Kernel:Stable is the addition of that pesign package to the OBS.
And, wouldn't you know it -- it works!
uname -rm 4.15.15-2.g4904fc3-default x86_64
Plus, VBox & NVidia modules are buildable again!
So, same problem or not, thanks for the 'save'!
Hehe, good to hear. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Apr 02 2018, Hans-Peter Jansen <hpj@urpla.net> wrote:
The kernel-devel packages aren't multiversion for technical reasons.
They aren't? $ rpm -qp --provides kernel-*devel* kernel-bigsmp-devel = 3.1 kernel-default-devel = 4.15.15-1.1.g4904fc3 kernel-default-devel = 4.15.15-1.g4904fc3 kernel-default-devel(x86-64) = 4.15.15-1.1.g4904fc3 kernel-desktop-devel = 4.3 kernel-ec2-devel = 4.4 kernel-trace-devel = 3.13 kernel-xen-devel = 4.4 multiversion(kernel) kernel-devel = 4.15.15-1.1.g4904fc3 kernel-devel = 4.15.15-1.g4904fc3 multiversion(kernel) Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Dienstag, 3. April 2018 11:00:20 Andreas Schwab wrote:
On Apr 02 2018, Hans-Peter Jansen <hpj@urpla.net> wrote:
The kernel-devel packages aren't multiversion for technical reasons.
They aren't?
$ rpm -qp --provides kernel-*devel* kernel-bigsmp-devel = 3.1 kernel-default-devel = 4.15.15-1.1.g4904fc3 kernel-default-devel = 4.15.15-1.g4904fc3 kernel-default-devel(x86-64) = 4.15.15-1.1.g4904fc3 kernel-desktop-devel = 4.3 kernel-ec2-devel = 4.4 kernel-trace-devel = 3.13 kernel-xen-devel = 4.4 multiversion(kernel) kernel-devel = 4.15.15-1.1.g4904fc3 kernel-devel = 4.15.15-1.g4904fc3 multiversion(kernel)
Okay, they are. Thanks for correction. kernel-macros is not, but that shouldn't prevent Sigi from rebuilding kernel modules either. Anyway, Sigi has solved his issues. Interestingly, there's some interference between pesign-obs-integration, when build on/for Factory and the kernel packages since the revision when module signing was enabled, which renders those builds unusable for other distros. (42.3 for Sigi, 13.2 for me). This shouldn't happen, since pesign-o-i does its job on build time just by post processing the packages. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (5)
-
Andreas Schwab -
Hans-Peter Jansen -
Jiri Slaby -
sigise＠mailc.net -
Takashi Iwai