[opensuse] Leap 42.1 and Kernel 4.5 signature error on boot try
I am using the repository http://download.opensuse.org/repositories/Kernel:/stable/standard I am installing on a new ASUS Zenbook. It has the touchpad problem often cited. So I thought I would try the current 4.5 kernel. On boot up it complains the 'signature file' is wrong and won't boot. I did the typical GUI YAST2 upgrade to get the 4.5 kernel. The new kernel is: vmlinuz-4.5.0-4.gece3ff2-default How do I fix the signature file? Thanks, Allen Wilkinson +++++++ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
25.03.2016 21:35, Allen Wilkinson пишет:
I am using the repository
http://download.opensuse.org/repositories/Kernel:/stable/standard
I am installing on a new ASUS Zenbook. It has the touchpad problem often cited. So I thought I would try the current 4.5 kernel.
On boot up it complains the 'signature file' is wrong and won't boot.
Really? Please show exact message. It most likely complains that file signature is wrong, which is not the same as "wrong signature file".
I did the typical GUI YAST2 upgrade to get the 4.5 kernel.
The new kernel is: vmlinuz-4.5.0-4.gece3ff2-default
How do I fix the signature file?
Disable secure boot in your firmware. Development kernels are not signed. May be they should be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
+++++++ On Sat, 26 Mar 2016, Andrei Borzenkov wrote:
25.03.2016 21:35, Allen Wilkinson пишет:
I am using the repository
http://download.opensuse.org/repositories/Kernel:/stable/standard
I am installing on a new ASUS Zenbook. It has the touchpad problem often cited. So I thought I would try the current 4.5 kernel.
On boot up it complains the 'signature file' is wrong and won't boot.
Really? Please show exact message. It most likely complains that file signature is wrong, which is not the same as "wrong signature file".
I did the typical GUI YAST2 upgrade to get the 4.5 kernel.
The new kernel is: vmlinuz-4.5.0-4.gece3ff2-default
How do I fix the signature file?
Disable secure boot in your firmware. Development kernels are not signed. May be they should be. --
Thanks for reply. I disabled secure boot via YAST2 > Boot Loader Settings. I retried booting the 4.5 kernel. Same problem still: "invalid signature" "loading ramdisk" "Error: must load kernel first" I went into BIOS and disabled secure boot there. A reboot worked sort of. It booted to runlevel 3, not runlevel 5 as configured. I logged into the console as my normal user and did a few trivial things to test, then logged out. At that point the system was frozen. It seems neither opensuse kernels nor KDE 5 have have caught up to this laptop hardware: ASUS ZenBook Pro UX501VW Processor Intel® 2.6 GHz CoreTM i7 6700HQ Processor, Chipset Intel® HM170 Chipset Memory DDR4 2133 MHz SDRAM, 16 GB Display 15.6'' 16:9 IPS UHD (3840 x 2160) Graphic NVIDIA® GeForce® GTX 960M with 2G GDDR5 VRAM Storage 512 GB SSD, Samsung NVMe Card Reader 2-in-1 card reader ( SD/ SDXC/ MMC) Camera HD Web Camera Networking: Wifi: Dual-band 802.11 b/g/n or 802.11 ac Built-in BluetoothTM V4.0 10/100 BaseT via USB dongle Interfaces: 1 x Microphone-in/Headphone-out jack 1 x USB 3.1 TYPE C port(s) 3 x USB 3.0 port(s) 1 x HDMI 1 x Thunderbolt port Audio: Built-in Stereo W/Speakers And Array Microphone Bang & Olufsen Thanks, Allen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-03-26 at 09:44 -0400, Allen Wilkinson wrote:
On Sat, 26 Mar 2016, Andrei Borzenkov wrote:
How do I fix the signature file?
Disable secure boot in your firmware. Development kernels are not signed. May be they should be.
I disabled secure boot via YAST2 > Boot Loader Settings.
I retried booting the 4.5 kernel. Same problem still:
"invalid signature" "loading ramdisk" "Error: must load kernel first"
No. He said to disable in your firmware. In your "BIOS".
I went into BIOS and disabled secure boot there.
A reboot worked sort of. It booted to runlevel 3, not runlevel 5 as configured. I logged into the console as my normal user and did a few trivial things to test, then logged out. At that point the system was frozen.
Well, that's a different issue... - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb2mMIACgkQtTMYHG2NR9XNjQCfYzKzWvF/S9BDMjUQdYQpUBRj EfMAoI/iV1nCbgiZvvNDqCkc/JpnHnKd =kOF7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/26/2016 10:12 AM, Carlos E. R. wrote:
I went into BIOS and disabled secure boot there.
A reboot worked sort of. It booted to runlevel 3, not runlevel 5 as configured. I logged into the console as my normal user and did a few trivial things to test, then logged out. At that point the system was frozen.
Well, that's a different issue...
Indeed it is! That's the kind of thing that logs are likely to reveal details on. I *hope* you have journalctl set for persistent storage! if so, then something like # journalctl --boot=-1 will display the boot messages from the previous boot and may show up why you went into either a failed state or multi-user.target (runlevel 3 no longer exists) rather than graphical.target (runlevel 5 no longer exists). [[ It may be you need # journalctl --list-boots to see what you have going back in time.. YMMV ]] It may be that you actually went into maintenance mode rather than multi-user mode. This would be an important distinction. Details of "Kernel command line", any errors, anything disabled, anything reported as failed, anything highlighted in red. Use your discretion. For example, my perfectly normal SAMBA startup messages are in red for some reason, though they are not erroneous or particularly significant. Go figure. "Frozen" on modern PCs is always .... unfortunate. Back in teh olden days of "Real" computers, the things that needed raised floor and HVAC, there was always a 'maintenance mode' where the console peripheral processor could probe the innards to see what was actually going on, not only inspect memory but also the innards of the CPU, MMU and the rest. At one time they sold 'debug boards' you could plug into a PC; these boards had their own processor and could probe the PC's memory, but not the innards of the CPU chip. *sigh* That's the price we pay for 'integration'. Next up, we'll have the CPU, cache, MMU, GPU, sound and a few gigs of memory on the chip. Sorry, what was that again? "Iris"? "Skylake"? AMD's "Fusion" range? http://www.pcworld.com/article/3039877/software-games/amds-shipping-its-fast... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-26 16:04, Anton Aylward wrote:
(runlevel 3 no longer exists) rather than graphical.target (runlevel 5 no longer exists).
Yes they do :-) They are symlinks. minas-tirith:~ # l /etc/systemd/system/default.target lrwxrwxrwx 1 root root 40 Jan 6 2014 /etc/systemd/system/default.target -> /usr/lib/systemd/system/runlevel5.target minas-tirith:~ # l /usr/lib/systemd/system/runlevel5.target lrwxrwxrwx 1 root root 16 May 9 2015 /usr/lib/systemd/system/runlevel5.target -> graphical.target minas-tirith:~ # l /usr/lib/systemd/system/graphical.target - -rw-r--r-- 1 root root 522 Apr 24 2015 /usr/lib/systemd/system/graphical.target minas-tirith:~ # - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlb2pmkACgkQja8UbcUWM1zEagD/WWtOJ20LOEvAvZw9R1gBw2W8 Wn8F+WU/adH7cIhF4dcBAIK9yujo6A1oiunSSdHPvlMsOsXPG+1nK0JN1JLFrV8Y =1XTb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/26/2016 11:10 AM, Carlos E. R. wrote:
On 2016-03-26 16:04, Anton Aylward wrote:
(runlevel 3 no longer exists) rather than graphical.target (runlevel 5 no longer exists).
Yes they do :-)
They are symlinks.
What you are saying is that the commands exists, not that the runlevels exist. Executing "init 3" actually run systemd .... # ls -l /sbin/init lrwxrwxrwx 1 root root 26 Mar 9 09:37 /sbin/init -> ../usr/lib/systemd/systemd ... and that "3" tells it to do multi-user.target. There are a fw other such aliases supported to give the image of backward compatbility, but that's all it is' an image. Even the scripts in /etc/init.d have a start-up check to see it systemd is present and running and if so redirect to systemctl. See /etc/rc.status. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-26 16:29, Anton Aylward wrote:
On 03/26/2016 11:10 AM, Carlos E. R. wrote:
On 2016-03-26 16:04, Anton Aylward wrote:
(runlevel 3 no longer exists) rather than graphical.target (runlevel 5 no longer exists).
Yes they do :-)
They are symlinks.
What you are saying is that the commands exists, not that the runlevels exist.
Executing "init 3" actually run systemd ....
Who cares? :-)
# ls -l /sbin/init lrwxrwxrwx 1 root root 26 Mar 9 09:37 /sbin/init -> ../usr/lib/systemd/systemd
... and that "3" tells it to do multi-user.target. There are a fw other such aliases supported to give the image of backward compatbility, but that's all it is' an image. Even the scripts in /etc/init.d have a start-up check to see it systemd is present and running and if so redirect to systemctl. See /etc/rc.status.
I know. But to me, the levels exist, for all practical purposes. You can also enter a '3' in grub ant it will also work. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlb2rHYACgkQja8UbcUWM1zy3wEAldHj8vjQJXJQAj0KoEI4zAM/ +Issjb9fNnvBQomP28ABAJ5m8cpimoTPEgB3xO7NX3lsZRPaQ+P/RU40dGH4pWCg =zjZ4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/26/2016 11:36 AM, Carlos E. R. wrote:
I know. But to me, the levels exist, for all practical purposes.
No, because as I say the stuff in, for example, /etc/rc5.d/ get handed over to systemctl. And that's only if the ssystemd-sysvinit compatibility package is installed, which you cannot assume that everyone has. In the longer run even this fake backward comparability will go away or become heavily depreciated, as backward compatibilities tend to, so its best not to become reliant on it or its terminology. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
26.03.2016 19:11, Anton Aylward пишет:
On 03/26/2016 11:36 AM, Carlos E. R. wrote:
I know. But to me, the levels exist, for all practical purposes.
No, because as I say the stuff in, for example, /etc/rc5.d/ get handed over to systemctl. And that's only if the ssystemd-sysvinit compatibility package is installed,
That's wrong. sysvinit compatibility is base systemd functionality. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-03-26 at 20:26 +0300, Andrei Borzenkov wrote:
26.03.2016 19:11, Anton Aylward пишет:
On 03/26/2016 11:36 AM, Carlos E. R. wrote:
I know. But to me, the levels exist, for all practical purposes.
No, because as I say the stuff in, for example, /etc/rc5.d/ get handed over to systemctl. And that's only if the ssystemd-sysvinit compatibility package is installed,
That's wrong. sysvinit compatibility is base systemd functionality.
And there was a statement that runlevel compatibility would be maintained for ever on openSUSE. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb25xcACgkQtTMYHG2NR9VK8gCfX/ZJr5H941L/IIgVEgij8otx /QsAmwVXxtDzo908mlULiZQS93fRXLTk =h6RD -----END PGP SIGNATURE-----
On 03/26/2016 03:42 PM, Carlos E. R. wrote:
And there was a statement that runlevel compatibility would be maintained for ever on openSUSE.
Reference, please. I missed that one. Who will be responsible for this? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-26 21:32, Anton Aylward wrote:
On 03/26/2016 03:42 PM, Carlos E. R. wrote:
And there was a statement that runlevel compatibility would be maintained for ever on openSUSE.
Reference, please. I missed that one.
That was long ago, and I had to search hard for it. Here you have, I think this was it: http://lists.opensuse.org/opensuse-factory/2012-09/msg00651.html http://lists.opensuse.org/archive/opensuse-factory/2011-12/msg00268.html -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/26/2016 11:24 PM, Carlos E. R. wrote:
On 2016-03-26 21:32, Anton Aylward wrote:
On 03/26/2016 03:42 PM, Carlos E. R. wrote:
And there was a statement that runlevel compatibility would be maintained for ever on openSUSE.
Reference, please. I missed that one.
That was long ago, and I had to search hard for it. Here you have, I think this was it:
http://lists.opensuse.org/opensuse-factory/2012-09/msg00651.html http://lists.opensuse.org/archive/opensuse-factory/2011-12/msg00268.html
Thank you for that. I do think it is a bit qualified. For example there is the issue of 3rd party support. In fact that first message says
As long as systemd does not provide the same features as sysV init, dropping sysV init is the wrong way to go. If it is really, *really* necessary, *do not drop the init scripts*, as cluster software will fail on update.
The problem with all this defence of the initVscripts is that systemd is not static. The perfectly valid arguments and examples of 2012 are outdated in 2016. We've seen new units added. True, Suse may not yet have adopted them, just as it was slow to adopt the unit to make Postscript work; I recall from my personal experience I had to search that one out on the web, from other distributions. And yes, Suse has a modified version of systemd, and yes we're running 210 when many other stable releases are running #229. So its hard to make absolute statements about systemd and I think statements about systemd on Suse, what it can and can't do, are point in time, and what it should and shouldn't do are tof the same philosophy that divides Linux from BSD. There are many classes of users. I like Suse, imperfections and gripes and all, but the reality is that I have to deal with other types of Linux and UNIX outside my "home" context. Work not only drags in the "Big Iron" of AIX, HP/UX and to a odd degree SUN (not like it was now because of oracle), but RedHat (the darling of so many financial houses) and, I'm sorry to say, Ubuntu. Some people seem to believe that Mint is the ne plus ultra because Steven J. Vaughan-Nichols says so. http://www.zdnet.com/article/2015s-best-linux-desktop-mint-17-2/ In the pre-Linux world I thought of the SUN systems I used as the 'baseline' and other version of UNIX as variants from that, add or subtract features and commands. Now the world with Linux is too diverse, I can't consider Suse, or Redhat, or Ubuntu, a 'baseline'. I had over a decade of UNIX before the SysVinit model came along, dealing with confusing ad-hoc scripts; in many ways there is a progression of rationalization. I'm still bothered by the BSD startup model. The critique of the shortcomings of the sysvinit methods that the systemd developers make are, to my mind, valid cna convincing, I've not seen a refutation of them that justifies not using systemd, and where that have merit has been a means of determining what systemd should address next. While SysVinit script support may continue my mind, my way of dealing with Suse and other systems that support systemd (especially later than #210) is to think in terms of systemd and systemd unit. Apart from very specific hardware and 3rd party thigns, how much of 'core' Suse still depends on sysVinit? How is that dealt with in Redhat? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Allen Wilkinson -
Andrei Borzenkov -
Anton Aylward -
Carlos E. R.