|
Bugzilla – Full Text Bug Listing |
| Summary: | Warning about incorrect checksum during installation of Leap 15.5 Beta | ||
|---|---|---|---|
| Product: | [Internal Novell Products] openSUSE Build Service | Reporter: | Freek de Kruijf <freek> |
| Component: | build process | Assignee: | Michael Schröder <mls> |
| Status: | RESOLVED WONTFIX | QA Contact: | Adrian Schröter <adrian.schroeter> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | freek, lubos.kocman |
| Version: | 2.5 | ||
| Target Milestone: | 2.5 | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Screenshot | ||
Then please check the checksum manually. Typically, this is a download error. *** Bug 1208917 has been marked as a duplicate of this bug. *** So, did you check the SHA256 sum of that ISO? You also didn't even write what ISO you used. (In reply to Stefan Hundhammer from comment #3) > So, did you check the SHA256 sum of that ISO? > > You also didn't even write what ISO you used. No, I have it on a USB stick together with Ventoy. So I select that iso image using Ventoy to start the installation. I also have the .sha256 file of that image on the stick and cd to the folder with the .iso and the .sha256 on the stick and do "sha256sum -c <.sha256-file>", which returns "good". OK. I never used that Ventoy, so I have no idea what exactly it does. https://en.wikipedia.org/wiki/Ventoy But what ISO from where (exact name and download URL, please, and also approximate ISO size!) did you use? Was it a NET ISO which only contains rudimentary data to start the installation and from then on downloads everything from an Internet server? Or a normal or full ISO which already contains RPMs? Also, did you try a normal installation without another unknown layer such as this Ventoy? That screenshot on Wikipedia leads me to believe that this is already a layer of bootloader (it lets you select UEFI or not, for example). That means that this is yet another layer of software to debug; of which I feel zero motivation. ;-) (In reply to Stefan Hundhammer from comment #6) > Also, did you try a normal installation without another unknown layer such > as this Ventoy? > > That screenshot on Wikipedia leads me to believe that this is already a > layer of bootloader (it lets you select UEFI or not, for example). That > means that this is yet another layer of software to debug; of which I feel > zero motivation. ;-) I use repo="http://download.opensuse.org/distribution/leap/15.5/iso" image="openSUSE-Leap-15.5-DVD-x86_64-Current.iso" in my download script to download the image and the sha256 file to my disk. Afterwards I copy these files to the USB stick and run sha256sum with the files on that USB. During installation I got a message that other repos are not available for download. So the installation is done from the DVD image on the stick. Ventoy is just a system to have several iso images available from which one can choose to select an iso image to use for installation. I used it to install Leap 15.4 and Tumbleweed as well as Windows 10. Instead of using the BIOS to load the boot part of the iso, Ventoy loads that part of the iso and a normal pattern is shown of loading the installation kernel for Leap 15.5 Beta from the iso image. This kernel and its applications is loading the rpm files to be installed from the iso image. So apparently the mentioned rpm file has a wrong checksum or there is a wrong checksum in some catalog. I just selected the KDE desktop and the rest is standard, nothing fancy. I downloaded openSUSE-Leap-15.5-DVD-x86_64-Current.iso (a symlink obviously) from that location, and I got openSUSE-Leap-15.5-DVD-x86_64-Build408.2-Media.iso and the SHA256SUM checked out okay. I mounted that ISO and checked that RPM from that error message: /mnt/noarch 20 % sha256sum efont-unicode-bitmap-fonts-0.4.2-1.21.noarch.rpm 401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c efont-unicode-bitmap-fonts-0.4.2-1.21.noarch.rpm Then I checked the files in repodata/ for that RPM: > [sh @ balrog] /mnt/repodata 40 % zgrep 'package.*name.*efont-unicode' *.xml.gz > 05a40c33013c9ff42bb57fbe5f10db1feac2eeaae6dcb39617130daf2349509e-other.xml.gz:<package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > 0aea525598c801e46ab702ce187dc8ffeff00700c67aa0f1eb05aa315f4c5714-susedata.de.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > 228257ae8347038bd811d6de5d5176340ca729afefbba3cda6bbbe79a934affd-susedata.ja.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > 67673e0dffec4d79982fc4058a962085057775139f505b33ec05706b8f9439d9-susedata.es.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > 6f0ceeb9ef9a64857e0f81b7d243b4a238e2975562790b2b67ebc9bfef7b72bc-susedata.it.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > 9be94edb1dce94e51c540d2e6c23f7c56008117d2261795a02451c70dd1fa7c5-susedata.cs.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > a35282f7ddd02a59f730fba3fd76c9a161635060666243126e4f63b3f413402e-susedata.hu.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > b0facaafbc9bfdcb3fca21588c53af67c93242130550cc263a1a735d8a91474a-susedata.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > c148e44fbc297cb26da568f308c0f6b8b21e4487403460e3df1acda4ac59ddee-filelists.xml.gz:<package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > e4db72d6b5cb07d97de0f8be2c672dbf54c6ede6a438fdf4f56f487fafbe129a-susedata.ru.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> > fcb099c3b710a51207513801135e917cb780128db4abef49a583d00fd3abc01f-susedata.uk.xml.gz: <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch"> Notice the suspicious absence of the *.nl.xml.gz file in that list, although the file does exist in this directory: > [sh @ balrog] /mnt/repodata 44 % ls -1 *.??.xml.gz > 0aea525598c801e46ab702ce187dc8ffeff00700c67aa0f1eb05aa315f4c5714-susedata.de.xml.gz > 228257ae8347038bd811d6de5d5176340ca729afefbba3cda6bbbe79a934affd-susedata.ja.xml.gz > 67673e0dffec4d79982fc4058a962085057775139f505b33ec05706b8f9439d9-susedata.es.xml.gz > 6c145679e09b9adbe80dbed6a69e0523da441b6e1395c74ef80a1df199738d63-susedata.nn.xml.gz > 6f0ceeb9ef9a64857e0f81b7d243b4a238e2975562790b2b67ebc9bfef7b72bc-susedata.it.xml.gz > 90e23df6fbf27a77f4a1a08e0f60e182729dd09344f87afa9200364b147b1b2b-susedata.lt.xml.gz > 9be94edb1dce94e51c540d2e6c23f7c56008117d2261795a02451c70dd1fa7c5-susedata.cs.xml.gz > a35282f7ddd02a59f730fba3fd76c9a161635060666243126e4f63b3f413402e-susedata.hu.xml.gz > c4158dc03fbfc37729bd1f5a948e043fd631c3db5a23a65c9bad8ac006a838b1-susedata.fr.xml.gz > e4db72d6b5cb07d97de0f8be2c672dbf54c6ede6a438fdf4f56f487fafbe129a-susedata.ru.xml.gz > fc6ceddb1950e216cb2089bde65bc66748feebaee4738c57474148aa6cfa77f9-susedata.nl.xml.gz > fcb099c3b710a51207513801135e917cb780128db4abef49a583d00fd3abc01f-susedata.uk.xml.gz Some of those files contain that RPM, some don't:
[sh @ balrog] /mnt/repodata 48 % zgrep -c efont-unicode *.??.xml.gz | sed -e 's/^.*-susedata/...-susedata/'
...-susedata.de.xml.gz:1
...-susedata.ja.xml.gz:1
...-susedata.es.xml.gz:1
...-susedata.nn.xml.gz:0
...-susedata.it.xml.gz:1
...-susedata.lt.xml.gz:0
...-susedata.cs.xml.gz:1
...-susedata.hu.xml.gz:1
...-susedata.fr.xml.gz:0
...-susedata.ru.xml.gz:1
...-susedata.nl.xml.gz:0
...-susedata.uk.xml.gz:1
[sh @ balrog] /mnt/repodata 49 % zgrep 'efont-unicode' *.de.xml.gz
> <package pkgid="401ae543471b36569188f4424a537fd8849807980592f762a38752a213a5452c" name="efont-unicode-bitmap-fonts" arch="noarch">
[sh @ balrog] /mnt/repodata 50 % zgrep 'efont-unicode' *.nl.xml.gz
[sh @ balrog] /mnt/repodata 51 %
Possibly something went wrong when creating that image. Notice that the SHA256SUM is the same as in your screenshot. I was just advised to move this to product OBS. Notice that I am unsure about the exact OBS version number; it's what we are currently using to build openSUSE ISOs with. Hello, I've tried to be supportive towards ventoy in the past, as I like the convenience of ventoy in certain scenarios. However as a team we've agreed that it's something that we can't easily support. Ventoy alters data that we've generated, and then things don't behave as expected. To sum it up Ventoy is currently not a recommended solution by openSUSE project https://en.opensuse.org/Create_installation_USB_stick#Ventoy I've seen similar checksum issues seldom in the past, but they are always temporary. Closing as won't fix. I highly recommend using the following solution for windows https://en.opensuse.org/SDB:Create_a_Live_USB_stick_using_Windows or our or e.g. Fedora's imagewriter tool for Linux. Thank you for your understanding. https://github.com/ventoy/Ventoy/issues/914 "When I use the openSUSE Tumbleweed booted by it, there are multiple rpm package verification errors." That's literally this bug in the Ventoy issue tracker from two years ago. After some discussion, this just petered out without any conclusion. |
Created attachment 865258 [details] Screenshot See attached screenshot. Re-installation of this package does not give this error, so it is probably an error on the DVD image.