Read error: [0x0000001B] The drive cannot find the sector requested when writing VHD image #2468
Comments
|
Hi Carlo, Can you elaborate on your "are no longer compatible with Rufus 4.x" statement? What error do you see, and where does it happen? I am not seeing any issue writing the In short, as much as I'd like to help, I'm afraid you're not providing enough details with regards to the exact nature of the issue you see, so more details would be welcome... |
|
Hi Pete, with Rufus 4.4 the error appears at the end of writing, see screenshot "Read Error"
The problem appears on 2 PCs with Win10 64Bit, also tried 3 different Pendivers of 4GB and 8 GB
On the same PCs if I use Rufus 3.2 instead, nope problem the write happens correctly.
To the vice versa:
If I use Rufus 4.4 to clone the Pendrive, the USB image created, I can write it with Rufus 3.x perfectly, no error
Good Night
CarloMessage ID: ***@***.***>
|
|
Please go to #2468 and attach the screenshot there, as screenshots sent through e-mail replies are not attached, and nobody but you can see them. Also, as requested in the checklist you were asked to follow when opening the issue, it is MUCH BETTER, if you want your issue to be properly investigated, to attach the log from Rufus (the checklist tells you explicitly how to access it), as screenshots are next to worthless when I cannot replicate an issue, as is the case here. For instance, here's my log writing For the record, Now, my guess is that the issue you may be facing probably has to do with the fact that you are using a VHD image, which is NOT a flat disk image, as it contains an additional 512 bytes of data, which you are trying to restore to a drive of the exact same size as the one you used to create the VHD. If you do that, then, these extra 512 bytes should produce an error because you are effectively using a VHD in lieu of a compressed flat disk image, and this is not something Rufus can support (the fact that it might have somehow worked before is no guarantee that it should ever have been supported), and you need to decide as to whether you want to use a proper compressed flat disk image, in which case it should just be that (i.e. not a VHD with the extract 512 bytes, but the part before that) in a zip file, or a proper compressed Microsoft VHD image, a.k.a. a VHDX. You simply cannot have it both way, because Rufus was only ever designed to support flat disk images inside of compressed archive, and any support of VHD inside of an archive would have been an accident that has been rectified, and that I have no plan to "revert". In short: Do not zip uncompressed VHD images and expect software to be able to handle those. Either compress a pure |
|
Thanks for the advice Pete, unfortunately I cannot use the VHDX format, if I try to create a Pendrive Image I get the same error you see in the screenshot attached below "Read Error" attach log Strange though that with Rufus 3.2 I never had any problem with all the USB VHD images created so far, I have created many AROS One Images (Many versions) and all compacted in ZIP and never had any problem. Regarding the strange screenshot that on your E-Mail does not show the screenshots, I on my E-mails never had any problem to display the screenshots attached to my E-mail ! Anyway I attach link with the screenshot showing the error |
|
VHDX is a different issue that will be fixed in the next release. Please show me the log from when you use the official
(which by the way is inaccurate since Rufus does not create zipped VHD, so if you do zip a So can I please have the log of what Rufus reports when you write As to e-mail attachments, please bear in mind that I do not receive your e-mail replies directly. Instead, GitHub receives them, processes the content (and strips any attachment), generates a GitHub issue update, and once that issue update has been added, it generates an e-mail notification from the update, and not from your original e-mail. At any rate, screenshots when reporting issue are next to worthless. Please consider them the same as a picture of a body taken by the police at a crime scene. It'll just confirm that somebody is dead, and maybe give some hints, but it's pretty much never enough to tell you exactly what happened. On the other hand, the log is like CCTV footage of the crime scene when the murder happened, and it is invaluable of telling you the sequence of event of how the crime happened, as well as who committed it. Which is why, when an application does include logging, and the developer asks you for a log, you shouldn't ignore their request and think a mere screenshot will be good enough... |
|
Ok thanks I will no longer ZIP compress the VHD images, I was doing it to speed up the Download I attach Log Error AROS One Image-USB-2.4.zipper with Rufus 4 |
pbatard
changed the title
|
Thanks. It looks like I am finally able to replicate the error (not sure why I didn't get it earlier on). Let me investigate this so I can figure out where it comes from. |
|
This will be fixed in the next version. This is actually a benign error and the resulting drive contains all the data. Ironically, I'm pretty sure you only got this error because you worked with the uncompressed VHD and not the zipped version, and I sure wish I had had your log right from the start so that I could see that you were opening the At any rate, thanks for the report, but next time, please do follow the check list, as it's only there to help you get your problem sorted in the most timely manner, by avoiding a lot of unnecessary back and forth. |
|
Hi Pete I tested the new version 4.5 beta, the request error is now gone, the "Burning" of the Pendrive image is now done correctly.
But be careful, with Rufus 4.5 beta the images created in the "VHDX" format, if you then try to burn, a request warns that the image is not supported by Rufus, if you need it I'll take a screenshot.
If instead with Rufus 4.5 I create a VHD Image, the "Live Pendrive" boots, shows the Grub, but then the partition is not detected (it stops at the AROS "Cat Eyes" logo)
If I use Rufus 3.2 the VHD Image created by Rufus 4.5 also works fine, the Live Pendrive boots correctly and shows the Operating System.
Greetings
Carlo
Message ID: ***@***.***>
|
Can you please send me your log instead? Again, I very much need to see your full log whenever you think you encounter an issue, as a screenshot is next to useless, as it tells me practically nothing outside of "Yup, you are seeing an error", which I don't doubt, but which I will have a very hard time to try to replicate and fix unless you provide a full log... |
|
I am sending you 4 logs
Rufus 4.5 Burn Image VHD created with Rufus 4.5
Rufus 4.5 Burn Image VHDX created with Rufus 4.5
Rufus 4.5 Burn Image VHD create con Rufus 3.2
Rufus 3.20p Burn Image VHD create con Rufus 3.20p (Ok This Live Pendrive works fine)
Allega il file di registro dell'archivio
ID messaggio: <pbatard/rufus/issues/2468/2105869548 @ github . com>
|
|
As I explained earlier, sending log as attachments will not work, because you are sending them to a GitHub bot which will discard them. You need to log on to GitHub and attach them to the issue using the web interface if you want them to be shared. At any rate, I think I have found the issue, and I will fix it, but I wouldn't mind to see the logs to make sure that I am addressing the same thing, rather than have you come back after the Rufus 4.5 release to tell me you're still seeing a problem. |
|
I attach the Logs here, fifth Log added Rufus 3.20p Burn Image VHD create con Rufus 4.5 (Ok This Live Pendrive works fine) |
|
Thanks. I believe the fix I am going to push, and which will be part of the 4.5 release, should address the issue. |
* Addresses the error reported in #2468. * Also use memmove instead of memcpy where overlapping data is involved.
|
I tested the new version of Rufus v4.5 and found this: Image creation VHD and VHDX, successful Booting from PC the "PenDrive Live" Burned with both VHD and VHDX Image, after displaying the GRUB Menu, the AROS partition is not found, "Read error -6 on block 0". Tried to burn the same VHD Image created with Rufus v4.5, with Rufus 3.20p and AROS One booted regularly, no error. I could not test the VHDX Image because it is not supported by Rufus 3.20p. I enclose Log Burning VHD Image with Rufus 4.5 |
Then from Rufus: Then back on Linux with the drive created by Rufus plugged back in (and the VHD saved by Rufus also copied into What the above demonstrates is that, no, Rufus 4.5 does not alter the data it saves to VHD from the original source disk data, or alter the data it writes to a target disk from the original VHD data and therefore that any differences you see come either from your environment, or from Windows itself interfering with the data on your drive because it might have decided that it needs to be "fixed". And you will be mindful that even though we wrote the same data as was previously on the drive during our test, we did zero the drive in between I don't have access to your environment, or your source images or your hardware and I'm afraid that, since we have conclusively demonstrated that, for something that Windows does not know how to access, not a single byte is being modified when using Rufus to create or write VHDs, then if you observe an issue, you will have to investigate it on your own and/or report it to Microsoft if it turns out that, when using the Microsoft native APIs to read to/write from VHD (Rufus 4.5), content is being altered compared to using direct sector read/writes (Rufus 3.20). There's only so much I can assume with the manner in which you conducted your tests and again, formal testing demonstrates that Rufus 4.5 does not alter VHD data (which it couldn't do since it's using the Windows APIs and is no longer manipulating sectors, so the only alteration that could occur would be to tell the API to stop writing data early, which is the issue that was happening earlier, but that got fixed). So you will have to explore exactly how your data is being altered, if it really is being altered, and where, by performing tests similar to the ones I laid out above, as it should give a clue as to what in your environment might be causing the alteration. And please also make sure to test your devices for bad blocks, as we can't rule out a defective device. |
|
Hi Pete and Thanks for answering, to be sure of what I write I did several tests with 3 Pendrivers of different sizes (4GB, 8GB)
With all 3 Pendrivers the "Burning" of the VHD Image with Rufus 3.2 was correct, no errors when writing, no errors when booting the Live Pendrivers to PC
With Rufus 4.5 all 3 Pendrives were burned without errors, but the Pendrives did not boot, all after Grub stop on the same Aros error request.
If you want to do some testing yourself, if I remember correctly you had an Amiga as a kid, Aros is the same.
Creating a Live Aros Pendrive is very easy, just boot an ISO from VMWare or other Virualizer and click on the InstallAROS Icon on the Desktop, if you need I can make a video tutorial.
For the ISO you can use a small Build (37 MB) from this link: https://axrt.org/downloads-aros
Have a nice day
Carlo
Message ID: ***@***.***>
|
|
I'm sorry but I just don't have the time for this kind of testing. I have demonstrated that Rufus does write VHD data as expected, and therefore, that whatever happens must be external to Rufus as I cannot vouch for what Windows does with the drive post write (or even during write when using the Windows VHD writing APIs, if Windows interprets your specific data in a manner that it doesn't like). If you have VHD images to share, I may take a look, but I am certainly not going to invest any time trying to create my own in the hope that I can replicate your issue as, again, there are way too many parameters, that are specific to your environment, that are outside my control and that can play. There is only so far I will go to test VHD writing, when I have already demonstrated that VHD writing should and does work exactly as advertised with standard random data. |
|
Pete I attach a link to download a VHD image of AROS One (latest version not yet distributed) created with Rufus 4.5
https://drive.google.com/file/d/1vNBwcHbYzXB03CLumTZlvSb_7qKiJ9my/view?usp=sharing
If you burn this VHD Image with Rufs 3.20p, the created Live Pendrive will work perfectly, and you will be able to boot AROS One x86 in seconds.
Out of curiosity, the VHD Image created with Rufus 4.5 will also boot perfectly if you use the "Whale Etcher" software
This Image if you burn it with Rufus 4.5 AROS One will not boot due to the described error "RDB Partition / SFS Filesystem not found".
Regards
Carlo
ID messaggio: <pbatard/rufus/issues/2468/2141891479 @ github . com>
|
|
It seems there might be something wrong with that image (either that or there is either a bug in Rufus or something is wonky with the system i was using) (Turns out the download was corrupting, likely due to a download manager) Log from Rufus: |
|
Nah, I can open and write it alright, and from what I can see, somehow the last 512 bytes of data from the image are not written as expected (whereas the rest of the image, up to the last 512 bytes matches 1:1). Note that I am talking about the last 512 bytes before the extra 512 bytes that any uncompressed VHD image also has, which are not part of the image data itself, but contain the VHD metadata. However, those erroneous 512 bytes do not appear to be due to a short write (where Rufus would somehow "forget" to read or write the last 512 bytes of data) as we definitely do write (and read) the expected amount of bytes. Instead it does appear that the last 512 bytes of the buffer we use to write the final data have been misread somehow. From what I can also see, when accessing it through different means, the data from the virtual drive we read from is the expected one, so it's currently a puzzle that will probably require time before I can figure it out. I also can't explain why this issue would not manifest itself on the other tests I had ran, such as the one I highlighted above, as if this was a consistent issue, we would have had comparison errors before EOF (which is actually how I found that the bytes started to differ at end of drive - 512). So the size of the source VHD seems to have an effect as well... Again, when I have more, I will report, but don't expect much for a while. |
|
Thanks Pete for the tests, I will continue to create the VHD image with Rufus 4.5, but will advise users to burn the VHD image with Rufus 3.20p,
Have a good weekend
ID messaggio: <pbatard/rufus/issues/2468/2141891479 @ github . com>
|
|
@AMIGASYSTEM, I believe that, if you partition your drive so that the last partition does not end at the end of the disk, but one (or a few) sector(s) prior, then you should still be able to use Rufus while I figure out this thing. I'm assuming that, at the moment, you partition the disk to use all the space available, but if you are creating public images for people to use, I figure you can probably reduce the size of the SFS partition by a small amount, in which case the issue with Rufus should not trigger. |
|
Thanks for the advice Pete, but unfortunately the partitions are created automatically by the AROS installer.
The installer also provides for partitioning the disk, but then it does everything automatically.
There is a way to make the partitions manually with the HDToolBox application, but this is a more complicated operation, HDToolBox, is a very Complex Application for experienced users only that I rarely use.
As soon as I have some time, I will do some experiments.Message ID: ***@***.***>
|
|
Well, the other option is to just rename the |
|
Ciao Pete, renaming .img works! Rufus 4.5 can now burn the USB Pendrive image correctly
Have a nice evening
carloMessage ID: ***@***.***>
|
|
This last issue will now be fixed in the next release of Rufus. As I suspected, this didn't really have anything to do with Rufus, but instead with Windows completely losing its marbles when you attempt to read past the end of a mounted VHD/VHDX because, when you do that, not only will Windows return extra data that doesn't exist, but it will also corrupt the data that does exist. In every other Operating System (or when reading directly from a file) attempting to read past the end of a file or device is something that's 100% allowed and handled gracefully (i.e you can rely on file I/O operations to return EOF or no data and let you go on your merry way), but it seems that the team that implemented VHD handling at Microsoft didn't get the memo, because boy will it screw you when you are issuing asynchronous operations. But I guess that's what you get from expecting an Amiga-level of proper OS design from the Redmond boys... As a result, I reworked the code to make sure that we don't ever attempt to read past the end of the image/VHD source, which seems to keep Windows happy and now allows it to return the expected data. |
* If you attempt to read past the end of a mounted VHD, not only will Windows happily return data that doesn't exist (instead of returning End of Disk), but it will also corrupt the existing data! * So, to appease the capricious Windows gods, we now make sure that we never attempt to read (or write) past the boundaries of the source or target when writing images. * This should address the last issue from #2468. * Also set version to rufus-next and make some small improvement in winio.h.
|
Thanks Pete, I'm glad you solved it.
Have a nice dayMessage ID: ***@***.***>
|
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Hi Carlo (70 Amiga User) I am also the developer of AROS One x86, some years I had asked you if Rufus could write an ISO of AROS x86.
Later I solved it by installing AROS x86 on Pendrive, and creating a USB Image from the Pendrive.
Now I have encountered a problem with Rufus 4.x, basically the USB Images (Pendrive) created with Rufus 3.x are no longer compatible with Rufus 4.x
Which version do you recommend I use in the future?
If you want to do some testing, you can find the AROS USB image (created with Rufus 3.x) on my link:
https://sites.google.com/view/arosone
Then test the Live Pendriver created on a supported PC, on older PCs it should boot.
The text was updated successfully, but these errors were encountered: