Failure to install openSUSE Leap 15.6 (from 15.4)
I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result What is wrong, what should I do get Leap 15.6 installed? Thanks in advance! Franz
Am Mittwoch, 31. Juli 2024, 17:06:49 MESZ schrieb Franz Polster:
I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result
What is wrong, what should I do get Leap 15.6 installed?
Did you try 'Upgrade'? Cheers Axel
Am Mittwoch, 31. Juli 2024, 20:42:10 MESZ schrieb Franz Polster:
Yes, I tried both "Installation" as well as "Update".
And you are sure ist not a hardware problem? It may be worth running an online upgrade: zypper clean zypper --releasever=15.6 ref zypper --releasever=15.6 dup -dl zypper --releasever=15.6 dup -l (out of my head, dup may come before releasever...) HTH Axel
Concerning the hardware see my reply to Felix Miata. I bought the notebook in 2013. I consider myself a naive user: What are the suggested zypper-commands doing? Could they ruin my current Leap 15.4 system? Franz
On 2024-08-01 21:50, Franz Polster wrote:
Concerning the hardware see my reply to Felix Miata. I bought the notebook in 2013.
I consider myself a naive user: What are the suggested zypper-commands doing? Could they ruin my current Leap 15.4 system?
Yes. It is a possibility. Make a backup first. The full instructions are here: <https://en.opensuse.org/SDB:System_upgrade> <https://doc.opensuse.org/documentation/leap/startup/single-html/book-startup/index.html#sec-update-zypper> -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Hello Franz, Am Donnerstag, 1. August 2024, 21:50:50 MESZ schrieb Franz Polster:
Concerning the hardware see my reply to Felix Miata. I bought the notebook in 2013.
Thats no indication - I run a 2012 ThinkPad on Tumbleweed....
I consider myself a naive user: What are the suggested zypper-commands doing? Could they ruin my current Leap 15.4 system?
No backup, no mercy. As Carlos wrote, make a backup first. If your installation uses btrfs, you can at least go back to a prior snapshot HTH Axel
Franz Polster composed on 2024-07-31 15:06 (UTC):
I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result
What is wrong, what should I do get Leap 15.6 installed?
Showing us what hardware you have from 15.4 boot running inxi -bxx may offer clues. Are you monitoring these attempts so as to offer an estimation of how far along the attempt has proceeded before this happens? Right away? Near finished? Other? If early, try again and hit ESC quickly after leaving the boot menu, so to see messages that may include clues. Depending on how far along attempt has proceeded, you may be able to Ctrl-Alt-F[3,4,etc] to see clues among messages. Cloning your 15.4 to your proposed 15.6 location, then online upgrading to 15.5, then 15.6 would be an option that would not disturb 15.4. 2/3 or so of my 30 or so 15.6 installations were achieved via zypper online upgrades. TW has made zypper a reliable upgrader, as long as sensible precautions are taken with any enabled non-standard repos. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
This is the result of command "inxi -bxx": fjp@Tuxedo:~/HTML/MyWebSite/pages/gps> inxi -bxx System: Host: Tuxedo Kernel: 5.14.21-150400.24.100-default x86_64 bits: 64 compiler: gcc v: 7.5.0 Desktop: KDE Plasma 5.24.4 tk: Qt 5.15.2 wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.4 Machine: Type: Laptop System: product: ' v: REV:1.0 serial: <superuser required> Chassis: type: 10 serial: <superuser required> Mobo: Micro-Star model: MS-1758 v: REV:1.0 serial: <superuser required> BIOS: American Megatrends v: E1758IG6.108 date: 05/13/2013 CPU: Info: Dual Core Intel Core i3-4100M [MT MCP] arch: Haswell speed: 2495 MHz min/max: 800/2500 MHz Graphics: Device-1: Intel 4th Gen Core Processor Integrated Graphics vendor: Micro-Star MSI driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0416 Device-2: NVIDIA GK208M [GeForce GT 740M] vendor: Micro-Star MSI driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:1292 Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: loaded: modesetting,nouveau unloaded: fbdev,vesa alternate: intel,nv,nvidia resolution: 1920x1080~60Hz s-dpi: 96 OpenGL: renderer: Mesa DRI Intel HD Graphics 4600 (HSW GT2) v: 4.5 Mesa 21.2.4 compat-v: 3.0 direct render: Yes Network: Device-1: Qualcomm Atheros AR8161 Gigabit Ethernet vendor: Micro-Star MSI driver: alx v: kernel port: d000 bus-ID: 04:00.0 chip-ID: 1969:1091 Device-2: Intel Centrino Wireless-N 2230 driver: iwlwifi v: kernel bus-ID: 05:00.0 chip-ID: 8086:0887 Drives: Local Storage: total: 713.04 GiB used: 38.47 GiB (5.4%) Info: Processes: 216 Uptime: 0h 43m Memory: 15.53 GiB used: 2.38 GiB (15.3%) Init: systemd v: 249 runlevel: 5 target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Packages: N/A note: see --pkg Shell: Bash v: 4.4.23 running-in: konsole inxi: 3.3.07 fjp@Tuxedo:~/HTML/MyWebSite/pages/gps> It is a "Tuxedo Book CA1702", bought in Oct 2013. Could it be the case that this notebook is too old for Leap 15.6 ? The problem occurs at an early stage of the installation process, long before the graphical interface appears with the prompts for language, keyboard, .... As to your other clues/tips: being a naive user I decided not to try all these tests/tricks in order not to ruin my outdated, but working Leap 15.4. Thanks anyway!
On 2024-08-01 21:39, Franz Polster wrote:
This is the result of command "inxi -bxx":
It is a "Tuxedo Book CA1702", bought in Oct 2013. Could it be the case that this notebook is too old for Leap 15.6 ?
No, but the kernel certainly has a problem with it. It may be solved, if the exact cause is found, but the boot image will probably not be updated.
The problem occurs at an early stage of the installation process, long before the graphical interface appears with the prompts for language, keyboard, ....
As to your other clues/tips: being a naive user I decided not to try all these tests/tricks in order not to ruin my outdated, but working Leap 15.4.
You could try 15.5 instead of 15.6.
Thanks anyway!
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
If Leap 15.5 can still be downloaded: where is Leap 15.5 available? I am aware only of get.opensuse.org/leap15.6/ which of course offers Leap 15.6. I tried get.opensuse.org/leap15.5/ to no avail: it points to get.opensuse.org/leap15.6/ Franz
On 02/08/2024 10:25, Franz Polster wrote:
If Leap 15.5 can still be downloaded: where is Leap 15.5 available? I am aware only of get.opensuse.org/leap15.6/ which of course offers Leap 15.6. I tried get.opensuse.org/leap15.5/ to no avail: it points to get.opensuse.org/leap15.6/
Franz
I looked all over the site, couldn't find it. Was only able to locate it via the mirrors page and using the navigation tree to go up to Leap level and then pick 15.5. https://download.opensuse.org/distribution/leap/15.5/iso/ gumb
On 2024-08-02 02:25, Franz Polster wrote:
If Leap 15.5 can still be downloaded: where is Leap 15.5 available? I am aware only of get.opensuse.org/leap15.6/ which of course offers Leap 15.6. I tried get.opensuse.org/leap15.5/ to no avail: it points to get.opensuse.org/leap15.6/
Franz This is a direct link to the 15.5 DVD install image: http://download.opensuse.org/distribution/leap/15.5/iso/openSUSE-Leap-15.5-D...
Opening this URL in your browser should trigger the download. Then just write the image to USB with something like imagewriter, which should be already on your system.
On Fri, Aug 02, 2024 at 08:25:38AM -0000, Franz Polster wrote:
If Leap 15.5 can still be downloaded: where is Leap 15.5 available? I am aware only of get.opensuse.org/leap15.6/ which of course offers Leap 15.6. I tried get.opensuse.org/leap15.5/ to no avail: it points to get.opensuse.org/leap15.6/
https://download.opensuse.org/distribution/leap/15.5/iso/ or better still: https://download.opensuse.org/distribution/leap/15.5/iso/openSUSE-Leap-15.5-... (#1/2 result searching for "opensuse leap 15.5 iso mirror" with two popular search engines) Notwithstanding if you have a kernel issue with 15.6 on your system, I thought the upgrade path was through successive releases only, ie you should upgrade from 15.4 to 15.5 and then (perhaps) to 15.6. There's a warning in the guide: "Do not skip a release when upgrading!" https://en.opensuse.org/SDB:System_upgrade Of course, an upgrade may just work fine for 99.9% of packages, but the distro has thousands of packages. The more packages then the greater likelihood you hitting an unfortunate corner case which hasn't been tested with an upgrade from previous-previous or previous-previous-previous etc. Daniel
On 2024-08-02 11:19, Daniel Morris wrote:
On Fri, Aug 02, 2024 at 08:25:38AM -0000, Franz Polster wrote:
If Leap 15.5 can still be downloaded: where is Leap 15.5 available? I am aware only of get.opensuse.org/leap15.6/ which of course offers Leap 15.6. I tried get.opensuse.org/leap15.5/ to no avail: it points to get.opensuse.org/leap15.6/
https://download.opensuse.org/distribution/leap/15.5/iso/
or better still:
https://download.opensuse.org/distribution/leap/15.5/iso/openSUSE-Leap-15.5-...
(#1/2 result searching for "opensuse leap 15.5 iso mirror" with two popular search engines)
Notwithstanding if you have a kernel issue with 15.6 on your system, I thought the upgrade path was through successive releases only, ie you should upgrade from 15.4 to 15.5 and then (perhaps) to 15.6. There's a warning in the guide:
"Do not skip a release when upgrading!"
https://en.opensuse.org/SDB:System_upgrade
Of course, an upgrade may just work fine for 99.9% of packages, but the distro has thousands of packages. The more packages then the greater likelihood you hitting an unfortunate corner case which hasn't been tested with an upgrade from previous-previous or previous-previous-previous etc.
There was a post here long ago telling that the upgrade was actually tested with many versions, not just the prior one. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Thanks, I just downloaded the 15.5 iso.file. According to the mirror-list page the last update was done in May 2023. So, I am wondering weather it is worth the effort to (try to) install Leap 15.5. At least, now I know where to look for SHA256 hashes. Thanks again, also to the other contributors! Franz
Am 02.08.24 um 16:44 schrieb Franz Polster:
Thanks, I just downloaded the 15.5 iso.file. According to the mirror-list page the last update was done in May 2023. So, I am wondering weather it is worth the effort to (try to) install Leap 15.5. At least, now I know where to look for SHA256 hashes.
The gold image is dated May 2023 and usually not changed afterwards without good reason. Updates come "up to date" with the installation. Peter
Thanks, I just downloaded the 15.5 iso.file. According to the mirror-list page the last update was done in May 2023. So, I am wondering weather it is worth the effort to (try to) install Leap 15.5. At least, now I know where to look for SHA256 hashes.
Thanks again, also to the other contributors!
Franz Updating from 15.4 directly to 15.6 did not work for you. You can try
On 2024-08-02 08:44, Franz Polster wrote: that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
On 2024-08-02 16:55, Darryl Gregorash wrote:
On 2024-08-02 08:44, Franz Polster wrote:
Thanks, I just downloaded the 15.5 iso.file. According to the mirror-list page the last update was done in May 2023. So, I am wondering weather it is worth the effort to (try to) install Leap 15.5. At least, now I know where to look for SHA256 hashes.
Thanks again, also to the other contributors!
The image file has not been updated since 2023, yes, but the distribution itself has been updated many times and is still being updated, via update repositories.
Franz
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash. A zypper dup might work, or the kernel could also crash on the following first boot. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Carlos E. R. composed on 2024-08-02 21:08 (UTC+0200):
Darryl Gregorash wrote:
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
Zypper online upgrades done with kernel locked will leave the old kernel installed, and not install a new one. I keep kernel locked as a matter of course, and choose the time for new kernel installation independently from other processes. Upgrade can be performed this way, then booted on old kernel, only after which installing new without removing old. It's a little like having a snapshot to fall back on. Working old remains available for use in case new fails. If old initrd is not backed up or locked, upgrade could make booting new system fail without recourse, by having regenerated initrd for each old kernel. Once I have a working initrd for a kernel, I make it immutable to prevent such any such possibility, and leave that way until time to remove its kernel. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-08-02 21:51, Felix Miata wrote:
Carlos E. R. composed on 2024-08-02 21:08 (UTC+0200):
Darryl Gregorash wrote:
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
Zypper online upgrades done with kernel locked will leave the old kernel installed, and not install a new one. I keep kernel locked as a matter of course, and choose the time for new kernel installation independently from other processes. Upgrade can be performed this way, then booted on old kernel, only after which installing new without removing old. It's a little like having a snapshot to fall back on. Working old remains available for use in case new fails.
Hum. Risky, methinks.
If old initrd is not backed up or locked, upgrade could make booting new system fail without recourse, by having regenerated initrd for each old kernel. Once I have a working initrd for a kernel, I make it immutable to prevent such any such possibility, and leave that way until time to remove its kernel.
Interesting. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 8/2/24 8:48 PM, Carlos E. R. wrote:
On 2024-08-02 21:51, Felix Miata wrote:
Carlos E. R. composed on 2024-08-02 21:08 (UTC+0200):
Darryl Gregorash wrote:
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
Zypper online upgrades done with kernel locked will leave the old kernel installed, and not install a new one. I keep kernel locked as a matter of course, and choose the time for new kernel installation independently from other processes. Upgrade can be performed this way, then booted on old kernel, only after which installing new without removing old. It's a little like having a snapshot to fall back on. Working old remains available for use in case new fails.
Hum.
Risky, methinks.
If old initrd is not backed up or locked, upgrade could make booting new system fail without recourse, by having regenerated initrd for each old kernel. Once I have a working initrd for a kernel, I make it immutable to prevent such any such possibility, and leave that way until time to remove its kernel.
Interesting.
There may be another way to do this which may be additionally helpful since it is unknown which kernel version(s) will fail, i.e., there is no assurance the the 15.6 image kernel is the only problem version, or for that matter, whether the problem was introduced in a 15.5 kernel. https://doc.opensuse.org/documentation/leap/reference/html/book-reference/ch... (6.1.3 in this case) Using the multiple kernel version feature: Configure 15.4 /etc/zypp.conf to keep at least the last 3 installed kernel versions (running, latest-1, latest-2; also a specific kernel version can be specified, in this case the working 15.4 version - probably a good idea). Perform the 15.5 upgrade with the downloaded media. But again, since it is unknown which version introduced the problem, it would probably be safest to skip enabling the online update repositories just yet. After rebooting the upgraded 15.5 system (if it should fail, the 15.4 kernel should still be available on the system and boot menu), then activate the 15.5 update repo's in YaST (or zypper). There will be a lot updates. In YaST (or zypper) the kernel can be updated to the latest 15.5 version. If that fails, the system can be booted into the initial distro version installed with the upgrade that worked or even go back to the 15.4 kernel, and then if desired, earlier 15.5 kernel versions than the latest can be tried to help isolate the problem (older kernels are only removed after a successful reboot so the earlier successful kernels will still be there, including 15.4). Once the 15.5 upgrade is successful, the same approach can be taken for 15.6. Perform an upgrade with YaST or zypper; if the update repositories have been added, the latest 15.6 kernel will be chosen. If that fails, the 15.5 kernel (and even 15.4) kernel will still be on the system. This step by step approach can upgrade the user's system while always having a fallback version known to be working. And if necessary, help to identify which kernel version introduces the error. HTH, --dg
Carlos E. R. composed on 2024-08-03 02:48 (UTC+0200):
Felix Miata wrote:
Zypper online upgrades done with kernel locked will leave the old kernel installed, and not install a new one. I keep kernel locked as a matter of course, and choose the time for new kernel installation independently from other processes. Upgrade can be performed this way, then booted on old kernel, only after which installing new without removing old. It's a little like having a snapshot to fall back on. Working old remains available for use in case new fails.
Hum.
Risky, methinks.
IME, risk is zero going between two leap versions: # inxi -S --vs inxi 3.3.35-00 (2024-06-18) System: Host: ab560 Kernel: 5.14.21-150400.24.38-default arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.9 Distro: openSUSE Leap 15.5 # # inxi -S --vs inxi 3.3.35-00 (2024-06-18) System: Host: ab560 Kernel: 5.3.18-150300.59.106-default arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Leap 15.5 # # inxi -S --vs inxi 3.3.35-00 (2024-06-18) System: Host: ab250 Kernel: 5.3.18-lp152.106-default arch: x86_64 bits: 64 Desktop: KDE v: 3.5.10 Distro: openSUSE Leap 15.5 # rpm -qa | grep nel-def kernel-default-5.14.21-150400.24.18.1.x86_64 kernel-default-5.14.21-150500.53.2.x86_64 kernel-default-5.14.21-150500.55.19.1.x86_64 kernel-default-5.14.21-150500.55.31.1.x86_64 kernel-default-5.14.21-150500.55.36.1.x86_64 kernel-default-5.14.21-150500.55.44.1.x86_64 kernel-default-5.14.21-150500.55.52.1.x86_64 kernel-default-5.14.21-150500.55.65.1.x86_64 kernel-default-5.3.18-lp152.106.1.x86_64 # In TW, I have multiple installations otherwise fully upgraded that have yet to have a 6.8 kernel installed, while 6.10.2 is current. Kernels don't stop working just because some system packages were upgraded that justify an increase in release version number. Keeping kernel current is mostly about security, and support for new technology. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-08-02 13:08, Carlos E. R. wrote:
On 2024-08-02 16:55, Darryl Gregorash wrote:
On 2024-08-02 08:44, Franz Polster wrote:
Franz
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
What will not work, Carlos? I made two distinct points here: either try again straight from 15.4 to 15.6 and hope, or go in two steps, first to 15.5 then to 15.6. Which one are you claiming will not work? What alternative process do you suggest that you think is better?
On 2024-08-04 05:10, Darryl Gregorash wrote:
On 2024-08-02 13:08, Carlos E. R. wrote:
On 2024-08-02 16:55, Darryl Gregorash wrote:
On 2024-08-02 08:44, Franz Polster wrote:
Franz
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
What will not work, Carlos? I made two distinct points here: either try again straight from 15.4 to 15.6 and hope, or go in two steps, first to 15.5 then to 15.6. Which one are you claiming will not work? What alternative process do you suggest that you think is better?
The DVD installation image of 15.6 doesn't boot in his machine, and this will keep happening no matter if the hard disk has 15.4 or 15.5. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-04 05:05, Carlos E. R. wrote:
On 2024-08-04 05:10, Darryl Gregorash wrote:
On 2024-08-02 13:08, Carlos E. R. wrote:
On 2024-08-02 16:55, Darryl Gregorash wrote:
Franz Updating from 15.4 directly to 15.6 did not work for you. You can try
On 2024-08-02 08:44, Franz Polster wrote: that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
What will not work, Carlos? I made two distinct points here: either try again straight from 15.4 to 15.6 and hope, or go in two steps, first to 15.5 then to 15.6. Which one are you claiming will not work? What alternative process do you suggest that you think is better?
The DVD installation image of 15.6 doesn't boot in his machine, and this will keep happening no matter if the hard disk has 15.4 or 15.5.
Three different people have told him where he can go in his browser to grab the iso image straight from download.o.o. He said this in one earlier post:
Thanks, I just downloaded the 15.5 iso.file. According to the mirror-list page the last update was done in May 2023. So, I am wondering weather it is worth the effort to (try to) install Leap 15.5. At least, now I know where to look for SHA256 hashes.
Thanks again, also to the other contributors! so we may safely assume he knows how to do a hash verification of any image he has. So don't you think it's possible to conclude that he now has verified iso images for both 15.5 and 15.6?
On 2024-08-04 21:15, Darryl Gregorash wrote:
On 2024-08-04 05:05, Carlos E. R. wrote:
On 2024-08-04 05:10, Darryl Gregorash wrote:
On 2024-08-02 13:08, Carlos E. R. wrote:
On 2024-08-02 16:55, Darryl Gregorash wrote:
On 2024-08-02 08:44, Franz Polster wrote:
Franz
Updating from 15.4 directly to 15.6 did not work for you. You can try that again and hop that it works this time, or you can update first to 15.5, then to 15.6, which will work. Your choice.
No, it will not work, there is boot crash of the image, a kernel crash.
A zypper dup might work, or the kernel could also crash on the following first boot.
What will not work, Carlos? I made two distinct points here: either try again straight from 15.4 to 15.6 and hope, or go in two steps, first to 15.5 then to 15.6. Which one are you claiming will not work? What alternative process do you suggest that you think is better?
The DVD installation image of 15.6 doesn't boot in his machine, and this will keep happening no matter if the hard disk has 15.4 or 15.5.
Three different people have told him where he can go in his browser to grab the iso image straight from download.o.o. He said this in one earlier post:
Thanks, I just downloaded the 15.5 iso.file. According to the mirror-list page the last update was done in May 2023. So, I am wondering weather it is worth the effort to (try to) install Leap 15.5. At least, now I know where to look for SHA256 hashes.
Thanks again, also to the other contributors! so we may safely assume he knows how to do a hash verification of any image he has. So don't you think it's possible to conclude that he now has verified iso images for both 15.5 and 15.6?
I never said anything about verification of the image. He has a problem when booting with the i5.6 DVD, which enters a kernel panic. That will keep happening no matter what is installed in the machine. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-04 21:15, Darryl Gregorash wrote:
So don't you think it's possible to conclude that he now has verified iso images for both 15.5 and 15.6?
I never said anything about verification of the image. You didn't, but so what? The matter has been raised, or at least inferred, previously. A hashcheck of the downloaded iso image will ensure there are no errors in it, but you seem to be suggesting here
On 2024-08-04 13:28, Carlos E. R. wrote: that that simple step is not important. Instead, you conclude...
He has a problem when booting with the i5.6 DVD, which enters a kernel panic. That will keep happening no matter what is installed in the machine.
The problem occurs at an early stage of the installation process, long before the graphical interface appears with the prompts for language, keyboard, .... The kernel panic clearly happens while the DVD image is being booted, and not after any changes have been made to the installed system -- suggesting that there was a possible problem with the original download. If the OP gets a fresh copy of the 15.6 image and verifies its hash, it is quite possible that the problem will have gone away. If not, he can always go to the CL and do the upgrade with zypper. But wait. Recently you posted this: It seems that the kernel in 15.6 is not compatible with your machine. You would have to see the verbose boot messages to try to find what is the exact problem, and then maybe there is an option to get pass that point. Or report the issue in Bugzilla. See my previous paragraph. At the point where the kernel panic happens,
... that a kernel panic will happen with 15.6, no matter what. On what basis do you make this conclusion? The OP has not been able to provide us with the information showing at what exact point the panic happened. All he has said about it is this: the system is still clearly trying to boot from the DVD image. On this basis alone you have concluded that the 6.4.0 kernel is not compatible with his machine. How can you make this conclusions, without further supporting evidence? If the 6.4 kernel is indeed incompatible with this machine, then it is very probable that it will be incompatible with many others. Yet there are no massive reports of kernel panic happening all over the planet with similar systems dating from the same time period.
On 2024-08-04 23:04, Darryl Gregorash wrote:
On 2024-08-04 21:15, Darryl Gregorash wrote:
So don't you think it's possible to conclude that he now has verified iso images for both 15.5 and 15.6?
I never said anything about verification of the image. You didn't, but so what? The matter has been raised, or at least inferred, previously. A hashcheck of the downloaded iso image will ensure there are no errors in it, but you seem to be suggesting here
On 2024-08-04 13:28, Carlos E. R. wrote: that that simple step is not important. Instead, you conclude...
I did not suggest that verification of the image is not important.
He has a problem when booting with the i5.6 DVD, which enters a kernel panic. That will keep happening no matter what is installed in the machine.
... that a kernel panic will happen with 15.6, no matter what. On what basis do you make this conclusion? The OP has not been able to provide us with the information showing at what exact point the panic happened. All he has said about it is this:
The problem occurs at an early stage of the installation process, long before the graphical interface appears with the prompts for language, keyboard, .... The kernel panic clearly happens while the DVD image is being booted, and not after any changes have been made to the installed system -- suggesting that there was a possible problem with the original download.
Suggesting there is a problem with the kernel itself, which will not be solved by installing 15.5 on the hard disk. It is the kernel on the DVD which has to be changed "somehow".
It seems that the kernel in 15.6 is not compatible with your machine. You would have to see the verbose boot messages to try to find what is the exact problem, and then maybe there is an option to get pass that point. Or report the issue in Bugzilla. See my previous paragraph. At the point where the kernel panic happens,
If the OP gets a fresh copy of the 15.6 image and verifies its hash, it is quite possible that the problem will have gone away. If not, he can always go to the CL and do the upgrade with zypper. But wait. Recently you posted this: the system is still clearly trying to boot from the DVD image. On this basis alone you have concluded that the 6.4.0 kernel is not compatible with his machine. How can you make this conclusions, without further supporting evidence?
It is the obvious conclusion.
If the 6.4 kernel is indeed incompatible with this machine, then it is very probable that it will be incompatible with many others. Yet there are no massive reports of kernel panic happening all over the planet with similar systems dating from the same time period.
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-05 05:00, Carlos E. R. wrote:
On 2024-08-04 23:04, Darryl Gregorash wrote:
On 2024-08-04 21:15, Darryl Gregorash wrote:
So don't you think it's possible to conclude that he now has verified iso images for both 15.5 and 15.6?
I never said anything about verification of the image. You didn't, but so what? The matter has been raised, or at least inferred, previously. A hashcheck of the downloaded iso image will ensure there are no errors in it, but you seem to be suggesting here
On 2024-08-04 13:28, Carlos E. R. wrote: that that simple step is not important. Instead, you conclude...
I did not suggest that verification of the image is not important. No? "I never said anything about verification of the image" suggests to me that you might not consider it all that important.
The kernel panic clearly happens while the DVD image is being booted, and not after any changes have been made to the installed system -- suggesting that there was a possible problem with the original download.
Suggesting there is a problem with the kernel itself, which will not be solved by installing 15.5 on the hard disk. It is the kernel on the DVD which has to be changed "somehow". Thousands have used the same iso image to upgrade to 15.6, without problems. It seems very unlikely that there is a problem with the image itself.
It is the obvious conclusion. Is it? I can think of two other possibilities just off the top of my head: An uncorrected error during download, with no hash check done after, could give rise to the same problem. A problematic USB stick could do the same -- writes to the stick might be working, but there could be spurious errors in the read circuit.
As for your claim that the current kernel contained in 15.6 must be incompatible with his machine, I say nonsense. The kernel is 6.4.0, and he is using the generic "default" version. I checked the website of the manufacturer of his machine. They make generic Intel- and AMD-based systems, and his was bought in 2013. There must be millions of systems from that era still in use, so if there is an incompatibility with the OP's system, there would certainly be problems being reported around the globe -- not just from oS users, but from users of every other distro as well.
Darryl Gregorash composed on 2024-08-05 12:00 (UTC-0600):
must be millions of systems from that era still in use, so if there is an incompatibility with the OP's system, there would certainly be problems being reported around the globe -- not just from oS users, but from users of every other distro as well.
The last part I disagree with. Leap kernels are custom kernels, loaded with backports, made for SLE users, secondarily provided for use by openSUSE users. Few if any users of other distros would have use for those custom SLE kernels. 6.4 was never LTS either, so at this point in time, no user of other distros would be inclined to try any 6.4, much less SLE's, if their own distro wasn't also providing a 6.4. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-08-05 15:23, Felix Miata wrote:
Darryl Gregorash composed on 2024-08-05 12:00 (UTC-0600):
must be millions of systems from that era still in use, so if there is an incompatibility with the OP's system, there would certainly be problems being reported around the globe -- not just from oS users, but from users of every other distro as well.
The last part I disagree with. Leap kernels are custom kernels, loaded with backports, made for SLE users, secondarily provided for use by openSUSE users. Few if any users of other distros would have use for those custom SLE kernels. 6.4 was never LTS either, so at this point in time, no user of other distros would be inclined to try any 6.4, much less SLE's, if their own distro wasn't also providing a 6.4. The kernel panic occurs so early in the boot process that I think it unlikely to be anything specific to the SUSE kernels, nor even specific to version 6.4. Rather, it is likely to be at a much more fundamental level, and exist in more version 6.x kernels than just what oS/SLE are using.
Darryl Gregorash composed on 2024-08-05 15:36 (UTC-0600):
The kernel panic occurs so early in the boot process that I think it unlikely to be anything specific to the SUSE kernels, nor even specific to version 6.4. Rather, it is likely to be at a much more fundamental level, and exist in more version 6.x kernels than just what oS/SLE are using.
I just checked the archive. Last post from OP hosted there was 3 days ago. Could it be problem solved? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-08-05 15:58, Felix Miata wrote:
Darryl Gregorash composed on 2024-08-05 15:36 (UTC-0600):
The kernel panic occurs so early in the boot process that I think it unlikely to be anything specific to the SUSE kernels, nor even specific to version 6.4. Rather, it is likely to be at a much more fundamental level, and exist in more version 6.x kernels than just what oS/SLE are using.
I just checked the archive. Last post from OP hosted there was 3 days ago. Could it be problem solved? If so, perhaps he could post a note to let us know... Franz?
I apologize for being silent, I just spend the last days on my MTB in the fields and forest and was too tired to do meaningful work in the evenings. This morning, until almost to this moment, I managed to install Leap 15.5: the installation process went smoothly, some steps were extremely time-consuming, e.g. installation of the LaTeX. So, this kept me busy (with long waits!) all day. But at last I have Leap 15.5 running and I can write this reply under 15.5. I do not even plan to install 15.6, rather I decided to wait for the successor version (Leap 15.7?). Therefore, I consider this matter closed. Except: Installation of Leap 15.5 triggered two issues: 1) the installation process seems to suggest the use of the brtfs file system. For obvious reasons I insisted on Ext4 for the /home partition. Question: Are there compelling reasons to switch to brtfs? If so, how should it be done? In the course of a future system installation? 2) On starting applications from the command line my new Leap 15.5 produces strange "Qt" messages. Examples: fjp@Tuxedo:~/Admin/TuxedoCA1702/Leap15.5> kate Leap15.5-current.txt& [1] 3429 fjp@Tuxedo:~/Admin/TuxedoCA1702/Leap15.5> Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected fjp@Tuxedo:~/ExponentialApproximation/EXPFJP/Dokumentation> okular EXPFJP-Dok_240425.pdf Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected Should they be simply ignored? What can I do to get rid of these messages? Thanks to all of you! Franz
Franz Polster composed on 2024-08-06 15:42 (UTC):
I do not even plan to install 15.6, rather I decided to wait for the successor version (Leap 15.7?).
Not a good plan. As with 15.4, and Leap releases prior, 15.5 support expiration will occur roughly 6 months prior to release of the successor (15.7) to its successor (15.6).
Therefore, I consider this matter closed. Except:
New issues deserve new threads with appropriate subject lines to attract the interest of such subjects. Grub can load installation kernels and initrds from any supported filesystem. Those for 15.6 (linux & initrd) can be downloaded from http://download.opensuse.org/distribution/leap/15.6/repo/oss/boot/x86_64/loa... . A custom Grub stanza can be created in /etc/grub.d/40_custom for loading them. If you do this and succeed to boot them, you may abort, or continue with a NET installation of 15.6, just as if you had booted from the NET installation .iso. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Op dinsdag 6 augustus 2024 17:42:19 CEST schreef Franz Polster:
Installation of Leap 15.5 triggered two issues:I do not even plan to install 15.6, rather I decided to wait for the successor version (Leap 15.7?).
Most likely (16.0) you will have to. And, it means you're going to be on an outdated and unsupported version after 15.5 is EOL and you have to wait for your newer version.
1) the installation process seems to suggest the use of the brtfs file system. For obvious reasons I insisted on Ext4 for the /home partition. Question: Are there compelling reasons to switch to brtfs? If so, how should it be done? In the course of a future system installation?
The reasons for picking ext4 over btrfs are not obvious at all. It **is** obvious that the devs/release teams had good reasons to go for btrfs as the default. I have no idea about your reasons, specially since you don't seem to know btrfs. Most compelling reason for me is the snapshotting feature. It allows me to roll back at filesystem level when I break things. Furthermore the btrfs send/receive to create perfect backups/restores On the "Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC- COOKIE-1 authentication rejected" message, there can be many reasons/solutions. Google is your friend there. -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
On 2024-08-06 18:26, Knurpht-openSUSE wrote:
Op dinsdag 6 augustus 2024 17:42:19 CEST schreef Franz Polster:
...
1) the installation process seems to suggest the use of the brtfs file
system. For obvious reasons I insisted on Ext4 for the /home partition.
Question: Are there compelling reasons to switch to brtfs? If so, how
should it be done? In the course of a future system installation?
The reasons for picking ext4 over btrfs are not obvious at all. It **is** obvious that the devs/release teams had good reasons to go for btrfs as the default. I have no idea about your reasons, specially since you don't seem to know btrfs. Most compelling reason for me is the snapshotting feature. It allows me to roll back at filesystem level when I break things. Furthermore the btrfs send/receive to create perfect backups/restores
It is also obvious to me to prefer ext4 over btrfs :-p -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-06 19:52, Darryl Gregorash wrote:
On 2024-08-06 11:42, Carlos E. R. wrote:
It is also obvious to me to prefer ext4 over btrfs :-p
Only you could prefer ext4 over btrfs -- and only you could believe there are "obvious" reasons for doing so.
There are so far 2 people with that preference in this thread alone. You do a poll of everybody and find out >:-P There are distros out there not preferring to install on btrfs. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Op dinsdag 6 augustus 2024 20:07:10 CEST schreef Carlos E. R.:
There are so far 2 people with that preference in this thread alone And both of them would regret that if they really went for some proper reading on btrfs, instead of playing the it-s-always-been-like-this card. Or do you seriouslyy think that 2 people in here know better than f.e. Facebook, SUSE, Redhat and so on. -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
On 8/6/24 11:27, Knurpht-openSUSE wrote:
Op dinsdag 6 augustus 2024 20:07:10 CEST schreef Carlos E. R.:
There are so far 2 people with that preference in this thread alone And both of them would regret that if they really went for some proper reading on btrfs, instead of playing the it-s-always-been-like-this card. Or do you seriouslyy think that 2 people in here know better than f.e. Facebook, SUSE, Redhat and so on.
Wait, regarding Redhat, I thought they dropped support for btrfs. I asked my friend at ChatGPT about it and she spake thusly: "As of Red Hat Enterprise Linux (RHEL) 8, Red Hat does not support the Btrfs (B-tree file system) filesystem. Red Hat deprecated Btrfs in RHEL 7 and removed support for it entirely in RHEL 8. Instead, Red Hat focuses on other filesystems such as XFS and Ext4, with a strong emphasis on XFS for enterprise environments." "For users who require Btrfs, alternatives such as CentOS (before CentOS Stream) or Fedora, which include Btrfs support, might be considered. Additionally, other Linux distributions like openSUSE and Debian also support Btrfs." Regards, Lew
On 06.08.2024 21:27, Knurpht-openSUSE wrote:
Op dinsdag 6 augustus 2024 20:07:10 CEST schreef Carlos E. R.:
There are so far 2 people with that preference in this thread alone And both of them would regret that if they really went for some proper reading on btrfs, instead of playing the it-s-always-been-like-this card. Or do you seriouslyy think that 2 people in here know better than f.e. Facebook, SUSE, Redhat and so on.
Facebook, SUSE, Redhat and so on have engineers who spend their life troubleshooting and fixing btrfs problems. Can you afford to hire one of them?
On 2024-08-07 06:04, Andrei Borzenkov wrote:
On 06.08.2024 21:27, Knurpht-openSUSE wrote:
Op dinsdag 6 augustus 2024 20:07:10 CEST schreef Carlos E. R.:
There are so far 2 people with that preference in this thread alone And both of them would regret that if they really went for some proper reading on btrfs, instead of playing the it-s-always-been-like-this card. Or do you seriouslyy think that 2 people in here know better than f.e. Facebook, SUSE, Redhat and so on.
Facebook, SUSE, Redhat and so on have engineers who spend their life troubleshooting and fixing btrfs problems. Can you afford to hire one of them?
That's exactly my issue. If I have a problem with btrfs, I can not solve it myself. Although I am testing btrfs with compression on some backup media. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Op dinsdag 6 augustus 2024 20:28:44 CEST schreef Larry Len Rainey:
A snapshot is not a backup - drives fail and all data is lost. You show here that you did not read my message or do not know about btrfs send/receive. The latter is an actual valid method to backup / restore. I did not say that snapshot == backup. A good recent example of what a rollback can mean to a user was when user got hit with a broken PSU during upgrade. After replacing the PSU, the system was unaccessible at boot, rolling back ( via a USB boot ) returned it to a fully usable machine
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
On 2024-08-06 20:49, Knurpht-openSUSE wrote:
Op dinsdag 6 augustus 2024 20:28:44 CEST schreef Larry Len Rainey:
A snapshot is not a backup - drives fail and all data is lost. You show here that you did not read my message or do not know about btrfs send/receive. The latter is an actual valid method to backup / restore. I did not say that snapshot == backup. A good recent example of what a rollback can mean to a user was when user got hit with a broken PSU during upgrade. After replacing the PSU, the system was unaccessible at boot, rolling back ( via a USB boot ) returned it to a fully usable machine
I do not deny how marvellous thing are snapshots. I agree with that. Nevertheless, it has issues that for me are paramount: not being able to solve "mid/serious" problems without help, and not being able to do a restore from an rsync. Thus I keep things simple and reliable: ext4 for "/" and xfs for /home and /data. As you have seen, there are important distributions not using btrfs, and I am not the only user not to use btrfs. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-06 20:28, Larry Len Rainey wrote:
I too, prefer ext4.
A snapshot is not a backup - drives fail and all data is lost.
Knowing how to backup and restore an ext4 system and is a safer option in my opinion.
That's another issue, I forgot about it. I do backups with rsync. I have absolutely no idea on how to restore from scratch the root filesystem on btrfs. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 8/6/24 10:52, Darryl Gregorash wrote:
On 2024-08-06 11:42, Carlos E. R. wrote:
It is also obvious to me to prefer ext4 over btrfs :-p
Only you could prefer ext4 over btrfs -- and only you could believe there are "obvious" reasons for doing so.
Well, only Carlos and me. I prefer the simplicity of ext4 for the system partitions and XFS for home and data partitions. It's worked well for me since SuSE 5.2. Although I did try Reiserfs for system partitions once, that didn't end well I'm afraid. BTW, I did try btrfs once and it failed on partitions larger than 15-TB, if I remember correctly. I know, that experience doesn't map to using it on small system partitions, but it is a data point. It's a blessing that we all have choice in these matters. Regards, Lew
On 2024-08-06 17:42, Franz Polster wrote:
I apologize for being silent, I just spend the last days on my MTB in the fields and forest and was too tired to do meaningful work in the evenings. This morning, until almost to this moment, I managed to install Leap 15.5: the installation process went smoothly, some steps were extremely time-consuming, e.g. installation of the LaTeX. So, this kept me busy (with long waits!) all day. But at last I have Leap 15.5 running and I can write this reply under 15.5.
I do not even plan to install 15.6, rather I decided to wait for the successor version (Leap 15.7?). Therefore, I consider this matter closed. Except:
You should report your problem in Bugzilla. Otherwise, it may never be solved and might appear again in the next release.
Installation of Leap 15.5 triggered two issues:
1) the installation process seems to suggest the use of the brtfs file system. For obvious reasons I insisted on Ext4 for the /home partition. Question: Are there compelling reasons to switch to brtfs? If so, how should it be done? In the course of a future system installation?
openSUSE devs prefer btrfs for the root system. The snapshot system allows a user to revert an update, that seems to be the most salient feature. I do not like it, mainly because when it crashes, it crashes royally, and handling of breakage needs an expert. I can not do it on my own, which is reason enough for me to refuse to allow it. But the default for /home was XFS, I am not aware of that changing.
2) On starting applications from the command line my new Leap 15.5 produces strange "Qt" messages. Examples:
fjp@Tuxedo:~/Admin/TuxedoCA1702/Leap15.5> kate Leap15.5-current.txt& [1] 3429 fjp@Tuxedo:~/Admin/TuxedoCA1702/Leap15.5> Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
Ask in a new message to attract people that know about such issues. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Op dinsdag 6 augustus 2024 19:50:10 CEST schreef Carlos E. R.:
You should report your problem in Bugzilla. Otherwise, it may never be solved and might appear again in the next release. Not valid here. With your experience you should know what happens if a user installs LateX ..... it pulls in the full texlive stack. And ~3K of packages takes a while. That said, I'm not very confident about having to deal with a pretty stock install and upgrade methodology from the side of the OP
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
There’s always the edge use case. Me, I keep it simple and use EXT4 with one partition for all. I also use TW, have for several years and haven’t “fresh” installed in about 5 years. Ken Schneider
kschneider composed on 2024-08-06 20:43 (UTC):
There’s always the edge use case. Me, I keep it simple and use EXT4 with one partition for all. I also use TW, have for several years and haven’t “fresh” installed in about 5 years.
Mine goes the other way. My PCs are all multiboot, on which I keep past support versions installed for years. So for me, EXT4 is largely about compatibility. Any kernel booted should be able to fully utilize any present filesystem. As much simplicity as practical is a necessity. The only BTRFS here is on an ancient single boot laptop given to me with a Leap BTRFS installation already on it. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-08-06 20:32, Knurpht-openSUSE wrote:
Op dinsdag 6 augustus 2024 19:50:10 CEST schreef Carlos E. R.:
You should report your problem in Bugzilla. Otherwise, it may never be solved and might appear again in the next release. Not valid here. With your experience you should know what happens if a user installs LateX ..... it pulls in the full texlive stack. And ~3K of packages takes a while. That said, I'm not very confident about having to deal with a pretty stock install and upgrade methodology from the side of the OP
Franz problem is not related to having Latex in the system (I have it, too). His problem is his machine will not boot the installation media. This problem has to be reported in Bugzilla. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-01 13:39, Franz Polster wrote:
It is a "Tuxedo Book CA1702", bought in Oct 2013. Could it be the case that this notebook is too old for Leap 15.6 ?
That is doubtful. Without more evidence than just your experience, I don't consider it a possibility.
As to your other clues/tips: being a naive user I decided not to try all these tests/tricks in order not to ruin my outdated, but working Leap 15.4.
Leap 15.4 reaches end-of-life at the end of this year (meaning no more updates for it). 15.5 will be supported until the end of 2025. So I recommend that, at the very least, you should upgrade now to 15.5. This will give you another year with a supported OS version, while you/we have a chance to learn what went wrong for you.
Op woensdag 31 juli 2024 17:06:49 CEST schreef Franz Polster:
I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result
What is wrong, what should I do get Leap 15.6 installed?
Thanks in advance! Franz Skipping the other replies: Given the little differences I tested online upgrade 15.4 -> 15.6 directly. On various hardware, and in the end on customer hardware. Without issues.
sudo zypper dup --releasever=15.6 --allow-vendor-change -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
On 7/31/24 11:06 AM, Franz Polster wrote:
I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result
What is wrong, what should I do get Leap 15.6 installed?
Thanks in advance! Franz
You may get some help here. You can disable the graphical interface which may help you find where the problem is. I ran into a problem with the "cpu mitigations" kernel parameter (2.4.7 on this. page). IIRC the default is "auto". On my system it must be "off" or the kernel will not boot. As shown, you can access the boot parameters and change them on the fly. https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-bo... HTH, --dg
On 2024-07-31 17:06, Franz Polster wrote:
I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result
What is wrong, what should I do get Leap 15.6 installed?
It seems that the kernel in 15.6 is not compatible with your machine. You would have to see the verbose boot messages to try to find what is the exact problem, and then maybe there is an option to get pass that point. Or report the issue in Bugzilla. Maybe try to boot the media in safe mode; this should be an option in the boot menu. You could try to upgrade to 15.5 instead. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
participants (14)
-
Andrei Borzenkov -
Axel Braun -
Carlos E. R. -
Daniel Morris -
Darryl Gregorash -
DennisG -
Felix Miata -
Franz Polster -
gumb -
Knurpht-openSUSE -
kschneider bout-tyme.net -
Larry Len Rainey -
Lew Wolfgang -
Peter McD