Downloaded install. file’s checksum confirmed; but in “Check install. media” “Error reading block"

English Install/Boot/Login
1

On this day of May 22, 2019, the day of 64-bit openSUSE Leap 15.1’s release, I have encountered a puzzling situation and request help in solving it. From within the openSUSE Web pages I downloaded the installation file for 64-bit openSUSE Leap 15.1 in the form of an International Standards Organization (.iso) file. Via clicking on a hyperlink reading “Checksum” on

https://software.opensuse.org/distributions/leap

on the Internet I obtained from openSUSE what the SHA-256 checksum should be for this .iso file. And from

http://emn178.github.10/online-tools/sha256_checksum.html

I obtained the SHA-256 checksum for the .iso file I downloaded from the Internet. After I imaginarily “cut off” “SHA256” from what I saw in the beginning of the openSUSE-supplied checksum, those two checksums matched completely.

In 64-bit Windows 10 Home Edition I right-button-clicked on the Leap-15.1, .iso file I downloaded and clicked on “Burn disc image” and later on “Verify disc after burning” and “Burn.” This disc-“burning” process was reported to be successful.

Then in Oracle Virtual “Machine” (VM) VirtualBox (VirtualBox) with the “boot” order set to be first “Optical,” second “Hard disk,” and third “Floppy,” I clicked Virtual Box’s “Start.” This clicking resulted in the openSUSE Recordable Digital Video Disc (DVD-R) software beginning to be executed. Among the ensuing available options I selected “More…”, then “Check installation media”, then “sr0…” for that DVD-R in my computer’s DVD drive, maybe “OK”, and waited for the process of checking that DVD-R’s written data to be completed. The reported result of that checking was “Error reading block 7922948. The medium is broken.” What is really puzzling is that I obtained exactly this same result with two separate “Burn disc image” processes in Windows 10 on the same downloaded .iso file using two different physical DVD-Rs, which were each reported to be successfully “burned!” Logic concerning this last result therefore “points” to not the disc-”burning” process being faulty, but the downloaded .iso file being faulty or partly undecipherable. But the paradox is that again my .iso-file download had the expected SHA-256 checksum obtained from within openSUSE’s Web pages, which “points” to my downloaded .iso file not being faulty. Could there have been a problem in how “Check installation media” performed the check of my openSUSE Leap, 15.1 DVD-R?—The combination of the successes of the “Burn disc image” process and the checking of the checksum suggest that nothing was wrong with either the .iso file provided by openSUSE or the disc-”burning” process.

Has anyone else had this sort of problem? What is my trouble in this regard? So far I have not tried to proceed in upgrading 64-bit openSUSE Leap from version 15.0 to version 15.1 using either one of my so-prepared, 64-bit openSUSE Leap 15.1, installation DVD-Rs. And I consider such proceeding risky concerning possible problems with such an upgrade. I also have not tried to perform this upgrade completely online instead of by making use of either one of those DVD-Rs. In case I would ever need to perform a so-called “clean” installation of 64-bit openSUSE Leap 15.1 or to upgrade to it again, I like the idea of having an installation DVD-R available for this operating system.

2

I can’t guess what your problem is.

If the sha256 checksum is correct, then you had a good download.

There’s always a possibility that you dvd burning hardware is failing. Some people recommend burning at the slowest speed you can set, to reduce the likelihood of failure. My preference is to avoid burning to DVD when I can, so I usually write the downloaded .iso file to a USB and install from there.

3

Thanks, nrickert, for kindly taking some time to post some writing here. I noticed from

https://www.youtube.com/watch?v=DFs3hnG7h_o

that in VirtualBox “booting” from a Universal Serial Bus (USB) flashdrive is possible, but involves installing ploplinux. So by that method upgrading openSUSE Leap from version 15.0 to 15.1 is probably possible using either the Digital Video Disc (DVD) Image or “Network Image” .iso file for Leap 15.1 obtainable from

https://software.opensuse.org/distributions/leap

. But I haven’t tried that lately.

Additional data:

  1. On
https://forums.opensuse.org/showthread.php/435303-11-2-Problem-during-Check-Installation-Media

on the Internet a problem of my kind was noticed in openSUSE 11.2, but I think was not reported as definitely having been solved in that “thread” of postings.

  1. From
https://software.opensuse.org/distributions/leap

for openSUSE Leap 15.1 I downloaded the “Network Image” “For CD and USB stick” and then in Windows 10 right-button-clicked on that downloaded .iso file and selected “Burn image to disc” with a blank Recordable Compact Disc (CD-R) in my computer’s Digital Video Disc (DVD) writer’s drive. In that process I selected “Verify disc after burning,” as I have lately often done in such “burning.” That “burning” was reported to have been successful, so without errors. But after I in VirtualBox “booted” from that CD-R, selected “More…,” “Check Installation Media,” “sr0…,” and “OK,” eventually I saw the same previous type of output of this time “Error reading block 255748. This medium is broken.”—That is the only difference in the error messages after executing “Check Installation Media” on the three optical discs I have been discussing in this “thread” of postings is in a different reported block number (Note: number, not numbers!) when checking the two DVD-Rs compared to the block number reported when checking the CD-R. The SHA-256 checksum for the Leap-15.1 “Network Image” “For CD and USB stick” obtained by clicking on “Checksum” below that quoted text on

https://software.opensuse.org/distributions/leap

exactly agreed with checksum obtained using the online computer program on

https://emn178.github.io/online-tools/sha256_checksum.html

.

  1. In 64-bit openSUSE Leap 15.0 I learned that there is a capability within Yet another Software Tool 2 (YaST2) to “Check Media.” For the two DVD-Rs I have been discussing and the CD-R from “2” above the reported results were the same, namely a) that because these “burned” discs did not have MD5 checksums that only their readabilities would be checked; b) “Result: sha256sum wrong” was reported, with the SHA-256 being relevant for the original .iso file, but I suppose irrelevant for the data “burned” on optical discs which were being checked using YaST2’s “Check Media;” and c) otherwise no problems were reported in reading any specific block numbers of any of the three optical discs I have been discussing in this “thread!” Notice how these results are drastically different from the results of “Error reading block” and a specific block number obtained from executing “Check Installation Media,” which is located on each of those optical discs!

So again I think the logical conclusion from the data I have collected is that there might be a problem in the “Check Installation Media” program on the Leap-15.1 optical discs and that the data written on those optical discs may actually all be okay. Once again I remind you that in Windows 10 the results of “Verify after disc burning” were no reported errors for any of the three optical discs I have so far been discussing in this “thread” of postings. Furthermore I provide the powerful data that in two different “burns” of the full Leap-15.1 .iso file on different optical discs the results of “Check Installation Media” were “Error in reading block 7922948.” So if there were a “burn” problem, as opposed to a problem in the original data, I think it would be surprising for it to occur at the same block number in two different “burns.”

Now I speculate concerning the possible cause of these data. Suppose that the same “Check Installation Media” program was used in both versions 15.0 and 15.1 of the openSUSE installation .iso files and that data in some new format were written in the Leap-15.1, .iso files for which that “Check Installation Media” program was not programmed to be able to “read.” If this speculation would turn out to be correct, then the “Check Installation Media” program used in the Leap-15.1 .iso files would have to be modified to accommodate the new data format which I hypothesize might exist in the Leap-15.1 .iso files. And the new data format may have existed in just one block of the data written on each of the three optical discs.

I suppose irrelevant: From the Internet I learned that there is a way to have slower “burning” within the to-me unknown version of Windows Media Player that I have installed in Windows 10 Home Edition. That was with its “Burn” tab selected, after moving my computer’s touchpad arrow a tiny “arrowhead”-looking symbol near the top-right-hand portion of the open, main window of Windows Media Player I saw “Burn options” appear in an ensuing context-sensitive menu. After clicking on that “arrowhead” in an ensuing drop-down list I saw “More burn options” and selected that. Then on the ensuing “Burn” tab I saw “Burn speed.” And beside that I changed the “Fastest” setting to the “Medium” setting and probably clicked on an “OK” software “button.” That setting persisted in a later entry into Windows Media Player. But I’m not sure whether it persists outside of Windows Media Player or not. Anyhow, the second one of the two DVD-Rs I have been discussing that I “burned” from the same, full, Leap-15.1, .iso file was “burned” after I so-lowered the “burn” speed within Windows Media Player.

I did find some instructions on

https://en.opensuse.org/SDB:System_upgrade

for upgrading openSUSE using commands, for example in a terminal computer program. But in my case at least one instruction there may need to be added because again in my case Leap 15.0 already had a repository the alias name of repo-update. So perhaps that Leap-15.0 repository would have to be removed before one with the same alias could be added for Leap 15.1. Presumably Leap 15.0 could be upgraded while online using a list of terminal commands, including many of them on

https://en.opensuse.org/SDB:System_upgrade

.

4

I don’t use virtualbox. I’ve been using KVM. And to boot a KVM virtual machine from USB, it is easier to do on reboot. So I first boot to something. Then I plug in the USB, which is picked up by the virtual machine. And then on reboot, I can get to boot from the USB, provided that I turned on the boot menu for the VM.

It’s usually easier to configure the downloaded iso to be a virtual CD/DVD, and boot from that.

5

Here is a hint installing into any virtual machine including Virtualbox…

Don’t burn your downloaded ISO to a DVD.

Instead, save all your ISO files in a specific folder (I created a folder called ISO, that’s really expected, right?) and place your 15.1 ISO file in it.
Now, when you run the Virtualbox “Create Machine” app,
Do everything the usual way but before actually running the virtual machine the first time,
In your Guest Machine Settings,
Go into Storage > Controller IDE and click on the optical disk icon in the right pane.
Since this is likely the first time you’ve done this, it’s probably set to point to your DVD drive, instead, you will want to browse to your 15.1 ISO file.
After you do this for your first virtual machine, any time you create a new Guest or want to re-configure an existing Guest, this selection will be available to you without file browsing.

Once completed, your Guest should read the ISO file as though it’s an optical disk and you can now install.

TSU

6

A few words on checksums, iso images, and burning DVDs / CDs.

Hi 2009Newbie,
I do not refer to virtual machines, since I run openSUSE directly, and since you already find replies above covering that.

From your postings I saw that you already run openSUSE Leap 15.0 (oS 15.0). In order to calculate checksums you then don’t have to go to the internet, because in oS 15.0 there are simple command line tools named ‘sha256sum’ or ‘md5sum’.
Let us assume you have a file named
‘openSUSE-13.2-DVD-x86_64_read_from_DVD.iso’
in the folder
/home/user/openSUSE/
In order to calculate the checksum of that file you open a terminal, navigate to that folder, enter e.g.

sha256sum openSUSE-13.2-DVD-x86_64_read_from_DVD.iso

and wait until sha256sum has finished and outputs the result in the terminal window.
If you are using the KDE desktop, then this is even more simple, because you then can use Dolphin to navigate to the folder /home/user/openSUSE/ and open a terminal in the lower part of the Dolphin window in which the right path/location is already set.

Burning and checking installer DVDs using oS 15.0:
If you already installed oS 15.0, then you don’t need to use some Windoze Media Player to burn CDs or DVDs.
In order to burn CDs and DVDs I ever used the graphical tool ‘K3b’ which is available from the standard repositories of all openSUSE versions I had (starting from 10.2 I think).
With respect to the CDs and DVDs I then knew pretty well what I was doing.

Independent of the operating system or the tool used, the general advice is to burn CDs and DVDs at the lowest speed possible, if a minimum of errors is desired.
Burning CDs and DVDs using K3b in that way, I never had problems with the result of ‘Check installation media’.

You express doubts concerning the algorithm behind ‘Check installation media’.
But there is no secret new code in the .iso image you obtained: An .iso image is an .iso image and remains an .iso image.

However, there is a second independent way to check your DVDs, I just tried it out using an old installer DVD of openSUSE 13.2 x86_64 which I burned a few years ago (using “Check Media” of YaST - which you mentioned - no errors were found on that DVD).
I used K3b to create an .iso image of that old DVD (i.e. physically reading this old DVD), and named it ‘openSUSE-13.2-DVD-x86_64_read_from_DVD.iso’ (see above).
Then as described above, I calculated the sha256 checksum of the file obtained in that way.
That checksum was exactly the same as the sha256 checksum for that installer image which can still be found on some openSUSE mirrors on the internet. That wouldn’t have been the case if my good old installer DVD would have been faulty.
In other words, you can read your two burned DVDs again into .iso files and compare the checksums of those to the checksum of the downloaded .iso. These checksums should all be the same.

Finally, the message “Error reading block 7922948” that you saw, to me is a clear indication of a hardware error - or maybe an error caused by the virtual machine etc., see the advice of tsu2 above, to not burn your downloaded ISO to a DVD and install from there.
Read the message “Error reading block 7922948” that you obtained well: It complains that the data on the disk couldn’t be read. This is the first step, and it comes before the data can be checked in a second step. Verification then has to be stopped, because if the data can’t be read, then it can not be checked.

Good luck

7

As inferred by above posts…
You may have done a checksum on your download, but if you burn the image to optical disk, then you also need to checksum that. Some DVD writers will do the checksum automatically, others not.

But, as I described you shouldn’t even be burning your images if you’re using the ISO images to build virtual machines.

TSU

8

Thanks, ratzi and other posters, for kindly taking some time to post information in this “thread” of postings. First, I’m sorry that I probably had the incorrect type of “tags” around Uniform Resource Locators (URLs or urls) in my previous postings in this “thread” of postings; namely I should have used “url tags” or “Link tags” instead of “HTML tags” around URLs. Secondly I apologize because according to what I learned from the Internet, DVD stands for Digital Versatile Disc instead of the definition Digital Video Disc I have previously provided.

Writing figuratively for some fun, in this project there have become two, possible, different “trails” for me:

“trail” A: determining the cause of and/or eliminating reading errors in “Check Installation Media” concerning the 64-bit openSUSE Leap-15.1 installation DVD-Rs (Recordable DVDs) I have “burned” and

“trail” B: upgrading 64-bit openSUSE Leap from version15.0 to version 15.1. Here I will provide some more data concerning “trail” A without having definitely and specifically solved it.

Though “trail” A has had some interesting aspects associated with it, today I left “trail” A, at least for a while, if not permanently, to “travel” on “trail” B in order to reach my “destination” of an upgraded openSUSE system, via some terminal commands given on https://en.opensuse.org/SDB:System_upgrade on the Internet in the process of an online upgrade of 64-bit openSUSE Leap from version 15.0 to version 15.1. Sorry, I did things differently than I earlier wrote.–That is instead of deleting a Leap-15.0 repository with the alias name of “repo-update” in a list of repositories on my computer, I renamed it with “15.1”s in it; and afterward I refreshed both it and some other repositories via the Internet.

  1. I performed tests of my Dell notebook computer’s computer, including of its optical-disc drive, in two ways: a) via pressing my computer keyboard’s F12 key after a restart of it and selecting “Diagnostics” and b) via Dell’s SupportAssist feature while online. In each of these testing procedures the only fault found with my computer’s hardware was that my computer’s battery needs to be replaced. But since I can use 120-volt Alternating Current (AC) electric power with my computer, I don’t consider this problem to be serious. Of particular interest the ReWritable (RW) DVD drive of my computer passed several tests via method “b:” DRAM (perhaps Dynamic Random Access Memory), flash ROM (probably Read Only Memory), main IC (maybe Integrated Circuit?), OP (which might stand for Optical Pickup head), and spindle tests.

  2. I “burned” a third, Leap-15.1 installation DVD-R from the same downloaded .iso file which after downloading had the openSUSE-supplied, SHA-256 checksum. And, just as with the previous two “burned” DVD-Rs from that .iso file, after starting VirtualBox, running “Check Installation Media” from that DVD-R resulted in exactly the same error message of “Error reading block 7922948. The medium is broken” as found for two other DVD-Rs “burned” from that same, checksum-confirmed, .iso file

  3. On the other hand on May 24, 2019 running “Check Installation Media” from a Leap-15.0 DVD-R I “burned” on May 25, 2018 resulted in “No errors found,” the same as on May 25, 2018.

4a) Following the kindly provided advice of nrickert, I used the application K3b to convert both the third Leap-15.1 and the Leap-15.0 installation DVD-Rs back to .iso files. The pleasant reported news in each of those cases was “Successfully read source disk,” really the DVD-R.
4b) Then afterward I used commands of the form “sha256some FileName.iso” to determine the SHA-256 checksums for each of those so-produced .iso files. The results in each of these cases were that the SHA-256 checksums did not agree with the checksums for each of those original .iso files supplied by openSUSE’s workers.

  1. Here are some data I saw while running “Check Installation Media” from the Leap-15.0 and Leap-15.1 installation discs:

From the Leap-15.0 installation DVD-R:

linuxrc 5.1.11, kernel 4.12.14-lp150.11-default. Also the Leap-15.0 installation program’s version was 5.1.11. Also I saw openSUSE-Leap-15.0-DVD-x86_64-Build267.2-Media. For that Leap-15.0 installation disc the result of “No errors found” was obtained on both May 25, 2018 using probably version 5.2.12r122591 of VirtualBox and on May 24, 2019 using version 6.0.8r130520 (Qt5.6.2) of VirtualBox.

From the Leap-15.1 installation DVD-R:

linuxrc 6.0.10, kernel 4.12.14-lp151.27-default. Also I saw openSUSE-Leap-15.1-DVD-x86_64-Build470.1-Media.

So, despite what I speculated earlier in this “thread” of postings, there were some differences in the software used in the process of “Check Installation Media” from Leap-15.0 and Leap-15.1 installation DVD-Rs.

Drawing conclusions from these data may be somewhat risky because there might be other factors I have not considered. Nevertheless I now try to draw some reasonable conclusions regarding the cause of the messages of the sort “Error reading block…” while executing “Check Installation Media” on four of five optical discs I have discussed in this “thread.”

i) I would expect a hardware problem, such as a laser’s intensity varying randomly over time, in reading or writing data from or to an optical disc to be random, or not always occurring at the same block number of an optical disc. Yet within a particular block number is what what actually occurred in three of three Leap-15.1 installation DVD-Rs “burned” from the same Leap-15.1 .iso file. So with this notion of randomness in mind, the data reported in items 1-4a do not support the hypothesis of a random hardware failure causing the “Error reading block…” from the Leap-15.1 installation DVD-Rs. This conclusion is further supported by “Check Media” in YaST2 reporting the successful reading of two of two such DVD-Rs and successes reported after the “burning” and verifying of the “burns” of all three DVD-Rs discussed in this “thread.” The fact that in “Check Installation Media” the “Error reading block …” always occurred at the same block number in all three DVD-Rs made from the same Leap-15.1 .iso file “points” to there being something written in that particular block which is different from the rest of the blocks on that DVD-R, not to some random-over-time hardware writing or reading error.

ii) From the successes reported in item 3 with the Leap-15.0 installation disc and the different versions of VirtualBox used in them reported in item 5, the change in VirtualBox versions seems unlikely to have caused the “Error reading block 7922948” in executing “Check Installation Media” from the three Leap-15.1 installation DVD-Rs discussed in this “thread;” else one may have seen an “Error reading block…” type of error with the Leap-15.0 DVD-R using the later version of VirtualBox, again something which did not occur.

iii) In item 4b the discrepancy between the checksums of the original Leap-15.1 .iso file and the .iso file obtained by restoring the Leap-15.1 DVD-R data back to a .iso file could by itself at first appear to be consistent with a hardware failure. But there may well be another cause for that discrepancy due to the .iso file being somehow modified in the cycle of a “burn” of it and then an attempt to restore it back to a .iso file.—This is because that sort of discrepancy between such a pair of .iso files also occurred with the Leap-15.0 .iso!—And up to now there is no reason to expect any problem with the readability of data written on the DVD-R made from the downloaded, Leap-15.0 .iso, due to “No errors found” from “Check Installation Media” for that DVD-R, or, due to the SHA-256 checksum confirmation, the data themselves in the original .iso.

iv) Based in part on the differing version numbers cited in item 5, I can expect there to be differences between both the original .iso files and the software used in “Check Installation Media” for the Leap-15.0 and 15.1 installation DVD-Rs. So some combination of these differences seems to be a possible cause for in Leap-15.1’s “Check Installation Media,” but not in Leap-15.0’s “Check Installation Media,” encountering “Error reading block 7922948.” It could be interesting for someone to see what is unusual in that block of data on such Leap-15.1 DVD-Rs, which I suppose corresponds to some data in the downloaded .iso! So far this “Error reading block …” type of error has occurred in “Check Installation Media” for both the “burns” of the “DVD Image” and “Network Image” .iso files for Leap 15.1.

9

I do not recommend converting ISO files to optical media and back again.
Far better is to download the file a second time if you deleted the first ISO file you downloaded.
You can also skip the checksum if you download using a torrent client app that automatically checksums each chunk and then the overall file after the entire file has been put together.

Then, as I described if you intend to build a Virtualbox virtual machine, then point your installer to the ISO file instead of your physical DVD-ROM.

TSU

10

My online upgrade of 64-bit openSUSE Leap from version 15.0 to 15.1 using some “zypper,” et cetera, commands gratefully went okay for me by my skipping some matters relating to my Compact-Disc (CD) repository. Thanks, tsu2, for your writing in this “thread” of postings. I started the process you suggested of placing the SHA-256-checksum-verified, Leap-15.1, installation, .iso file in a new folder. Then in VirtualBox I clicked on “Settings,” then “Storage,” and then under “Controller: IDE” I clicked on “Hard Drive ‘D:’”. Then on the far-right-hand side of the open “Storage” pane I clicked on the symbol of an optical disc, selected “Choose Virtual Optical Disk File…,” selected my downloaded, Leap-15.1, .iso file, and probably clicked on an “OK” software button. Afterward it was important for me to move the optical drive up to the top of the boot-order list on VirtualBox’s “Settings,” “System,” and click on “OK.” Then in VirtualBox I clicked on “Start.” A window opened. In it the appearance was just as if I had booted from an openSUSE, installation DVD-R! So I selected “More…” and then “Check Installation Media” with no optical disc in my computer’s DVD-RW (ReWritable Digital Versatile Disc) drive. After a while I chose “other device” and input the directory and file name for my downloaded, Leap-15.1, .iso file. I received the message “Invalid device name.” So I repeated the “Check Installation Media” process up to my choice of “other device” and this time instead selected “sr0….”, still with no optical disc in my computer’s DVD-RW drive. I received the surprising message “No errors found.” So “Check Installation Media” could be used to check the downloaded, Leap-15.1, .iso file for errors and produced the result that none of them was found in that .iso file.

This showed that my earlier conclusion here was wrong. So the remaining possibilities I can imagine for three DVD-Rs each having been “burned” from the same, checksum-verified, .iso file and all of them having the same “Error reading block 7922948” message are as follows:

  1. In Windows 10 a problem with “Burn disc image” being unable to “burn” some type of data in the downloaded .iso file.
  2. A hardware “burning” problem. In this regard I should mention that the checks of my DVD-RW drive likely did not include checks of its disc-“burning” capabilities, since I was not asked to insert a Recordable Compact Disc (CD-R) or Recordable DVD (DVD-R) into my computer’s DVD-RW drive for those tests. The likelihood of three DVD-Rs all being bad at the same, corresponding, physical locations on them would I suppose not be impossible; but I consider this hypothesis highly unlikely to be correct.

Now I am curious whether a .iso file not from openSUSE could be “burned” properly or not onto an optical disc using the combination of my computer’s DVD-RW drive and “Burn disc image” in Windows 10.

11

Glad to hear you got your Virtualbox and ISO file working, but it shouldn’t have been so difficult…
There is no need to re-order the disk controllers, VBox unnecessarily but perhaps for clarity configures an IDE controller for your optical disk and a SCSI controller for your hard disk.
Below each disk controller, you will find an entry for a mounted storage… a SCSI HDD and an IDE optical disk.
With the optical disk selected on your left, you can view the details pane on the right… and now if you click <not> the text but the icon at the far right, you will see a dropdown with the following choices…

Choose Virtual Optical Disk File...
Host Drive [DVDR device]
Any previously configured ISO files
________________________________________
Remove Disk From Virtual Drive

From the above, by default and the first time you display these options, your Host Drive will be selected.
Select the top option instead to browse to an ISO file (Install source for new installations)

TSU

12

I tried burning a DVD with K3B for the upgrade 15.0 to 15.1. Nothing but grief, namely the same problem - something could not be read, ignoring that (a bad idea, I know), the whole business got hung up when the default kernel was said to have been 100% installed. I tried a fresh install of 15.1, fresh DVD, same problem.
I am assuming a local hardware difficulty (probably with burning) and shall try again, perhaps with an online upgrade. It is notable that the difficulty appears to be the same as that discussed in this thread, for what that is worth.

13

With help from a kind, somewhat distant neighbor I tried blowing dry, 150-pounds-per-square-inch compressed air over the ReWritable Digital Versatile Disc (DVD-RW) drive in my Dell notebook computer; the air pressure was so high that I saw part of that DVD-RW drive move during that blowing; so perhaps that air-blowing operation was too “rough” on that DVD-RW drive. Some dust was blown away from that drive’s frame. Later I was somewhat concerned that some of that dust may have been blown onto the lens above the DVD-RW drive’s laser. (But eventually I saw that that lens looked very shiny.) Afterward I selected “Burn disc image” in Windows 10 to “burn” another Recordable Digital Versatile Disc (DVD-R) from a previously downloaded 64-bit, openSUSE, Leap-15.1, Linux installation file. After executing “Check Installation Media” from that disc I saw “Error reading block 7770432,” a block number different from the common earlier block number of 7922948 at which there was a disc reading error when attempting to check multiple such discs in this way for errors.

I replaced my Dell computer’s DVD-RW drive (Toshiba Samsung Storage Technology Corporation [TSSTcorp] DVD±RW SU-208CB) with a new one (TSSTcorp DVD±RW SU-208FB). The old DVD-RW drive’s drawer facing, called a bevel, and its mounting tab and screws were removed and used to replace those components on the new DVD-RW drive in order to fit my Dell notebook computer well. After that replacement, in 64-bit Windows 10 Home Edition operating system selecting “Burn disc image” to “burn” a disc image of a downloaded Leap-15.1, International Standards Organization (.iso), installation file, and then “booting” from that resulting disc in Oracle Virtual Machine (VM) VirtualBox and selecting “More…”, “Check Installation Media,” I gratefully received the message “No errors found.”

So eventually a not definitely determined problem might have been developed that regularly appeared with my previous DVD-RW drive contained in the Dell notebook computer I purchased almost 6.3 to 6.4 years ago. Excepting a period of time when I had some trouble with some optical disc media, over a period of years of time I gratefully was able to successfully use that DVD-RW drive to write on quite a number of Recordable Compact Discs (CD-Rs) and DVD-Rs.–The error-reading-disc-block-number problem when executing “Check Installation Media” on a recently “burned” disc began to regularly appear with that drive slightly less than 5.5 years after I purchased that computer and its DVD-RW drive, but not after those approximately 5.5 years with a Leap-15.0 installation DVD-R “burned” within probably the fifth year after I purchased that DVD-RW drive and the Dell computer containing it. So although the problem was detected in an attempt to read some recently “burned” discs, its “root” cause appears to have instead been a problem in “burning” discs within about 5 to 5.5 years after my Dell computer and its DVD-RW drive were purchased.

I read on the Internet that a laser (presumably its output intensity of electromagnetic radiation) in presumably a Compact Disc (CD) or DVD drive could weaken with time. But if so, in my case it seems hard to explain how such a problem would occur at the same block number on multiple DVD-Rs “burned” in my installation of a host, Windows operating system, which was the case for me before I used compressed air to attempt to clean the old DVD-RW drive and/or the lens above its laser.

14

The Laser device in any consumer product is just that – a consumer product – and therefore, cheap.

  • The Laser devices in industrial products are more expensive but, they also have a “Mean Time Between Failure
    ” «MTBF» – which is usually, somewhat longer than the MTBF for consumer products. - Therefore, do not expect that, a consumer product will “last forever
    ” – even though, these days, some consumer products, occasionally, function reliably for many years …