Wubi fails to install from my cd-rw but does from my dvd-rw

Wubi should extract the ISO into in C:\ubuntu\install\.
Can you please check that the md5 of the ISO thus generated is correct?
That would mean that I can safely ignore such errors.

Yes the MD5SUM is correct as it installs via the dvd-rw is is only not installed via cd-rw that it doesn't.

Also it has install Ubuntu via live cd.

I know this will sound strange but...
My Cd-rw has always been a slave firstly to my hard drive and then to my Dvd-rw. Could it have anything to do with the numbering/naming of the disc?

Longshot I know.

As suggested by Hampus, skipping the last loop in ImageCreator.cpp might help things.
That would involve adding:

if (bytesWritten == mTotalBytes) break;

I will make a build with the above change tonight.

Could you please if there is the same issue with the latest build in http://wubi-installer.org/devel/minefield/
You will need to keep the Ubuntu CD in the tray.

Problems are still reported.
http://ubuntuforums.org/showpost.php?p=4637599&postcount=11

Agostino I have some time on my hands right now for a re-test which exe would you like me to test and does it matter which version of the cd is in?

Use the latest wubi for test rev 482+

I am not sure if this bug is exactly the same as my original reported bug (215129) that has been marked as a duplicate.
In my case the dvd fails and the cd works.
Executed rev 482 today with dvd in the drive. Still running into the same error after reaching 100%:
"Could not access CD, please make sure other applications are not using it and try again".
Clicking Retry reruns the whole thing and ends with the same message.

Just to be absolutely clear, are you referring to the support medium (CD disk vs DVD disk) or to device drives (CD drive vs DVD drive)?
Does it work if you only have the DVD drive connected?

I was not referring to the drive. I am running the test on a Sony Vaio laptop with a blue-ray drive.
With this drive I burned the image to a dvd-rewritable disc and to a cd-recordable disc.
The dvd fails to install, but the cd installs fine.

Just to be clear also mine is with devices not discs.

Has any of you tried to create an iso from the failing disc/drive using another application (like your burning program or similar)? Would be interesting to know if that works. Perhaps you could even compare the result (if any) to the original iso (using something like http://en.wikipedia.org/wiki/Md5sum). The md5 hashes are (depending on if you have a 32 or 64 bit processor):

61c87943a92bc7bf519da4e2555d6e86 ubuntu-7.10-desktop-amd64.iso
d2334dbba7313e9abc8c7c072d2af09c ubuntu-7.10-desktop-i386.iso

It would be extremely useful if anyone found an open source application that could successfully do this, but first of all it is interesting to see the results of any other application. Whatever happens, it would be interesting to know about it. Messages appearing during the iso creation might be useful...

Forgot that the latest version installs Ubuntu 8.04. You'll find the md5 hashes here: http://releases.ubuntu.com/8.04/MD5SUMS. It's one the "desktop" isos, depending on your processor...

Agostino Russo

Wubi 486sh.exe + cd build ubuntu20080411 = fail same fault (Could not access the cd, please make sure other applications are not using it and try again.)

Problem was caused by bad DVD-rewritable!

Ok, tried to create an iso of the dvd using Roxio......but it failed!
Burned the iso to a different dvd-rewritable and all my problems were gone....
Sorry for all the noise... :-(
Invalidated the duplicate bug.

Regards and thanks for help anyway.

Reopening since there have been other reports.

It would be interesting to know if that is casued by a CD which has been burnt but not finalized and what type of media (CD, CD rw, DVD+r, DVD-r) and drive was used.

Got the same issue with wubi. Trying to install using an external DVD-RW. Downloaded the Ubuntu 8.04 final ISO from two different offical mirrors with no luck. Used Imgburn 2.4.1.0 to burn/verify the ISOs btw.

I copied the Ubuntu 8.04 image to a DVD+RW that was finalised using Nero burning ROM and managed to run wubi.exe without problems. It did not work, as above, when recorded to a CDW.
For me, problem solved.

Note that Wubi does not need a physical CD, it can work directly with the ISO. Hence the workaround is straightforward: put ISO and wubi.exe in the same folder and run wubi from there.

Burning the ISO to DVD fixes the issue. Thanks Ediz!

Could it be that in some cases the use of GetDiskFreeSpaceEx is not appropriate?

mTotalBytes = getDiskSize(driveLetter);
double getDiskSize(string driveLetter)
{
 ULARGE_INTEGER TotalBytes;
 string diskPath = driveLetter + ":\\";
 BOOL result = GetDiskFreeSpaceEx(diskPath.c_str(), NULL, &TotalBytes, NULL);
 if(result == 0) return 0;
 return TotalBytes.QuadPart;
}

The use of a max buflen of 8192 might also help.

It would be interesting to compare the value of GetDiskFreeSpaceEx for the problematic CD with the size of the original ISO.

I'm getting the same error at the end of the "Creating image ..." step in Wubi, just after reaching the 100%.
The message is "Could not access CD, please make sure other applications are not using it and try again".

The error in the log is:
CD2ISO C:\ubuntu\install\installation.iso
CD2ISO failed: LastError = 1 Incorrect function.

The media I used is a CD-R burnt using a DVD writer with Nero and finalizing the CD. My device is a "TSSTcorp DVD+-RW TS-L532B" as reported by Nero 6.

I called the function GetDiskFreeSpaceExW for the D: drive and gives me 733079552 of total bytes, the same size as the ISO file I downloaded.
I checked the md5 of the downloaded ISO file and is the same as the original one (8895167a794c5d8dedcc312fc62f1f1f ubuntu-8.04-desktop-i386.iso).

Hope this helps to find the issue.

Juan

* This is the Python script I used:

from ctypes import *

drive = "D:\\\\"
freeSpace = c_ulonglong(0)
availableSpace = c_ulonglong(0)
totalSpace = c_ulonglong(0)
rv = windll.kernel32.GetDiskFreeSpaceExW(unicode(drive), byref(availableSpace), byref(totalSpace), byref(freeSpace))

print totalSpace.value

I've put together a small exe-file that only runs the iso creation algorithm, with a lot more logging than usually. It would be useful if some of you who have troubles with this would download and run this test application. Save the exe-file on your hard drive, put a disc into your CD/DVD drive and run the exe in a command prompt with the drive letter of your CD/DVD device as the only argument (eg "cd2iso D"). It will create a log file called "cd2iso-log.txt". Post your log file here if you think it might be useful! If this test application works better than Wubi for you (ie gives no error messages) that would be very interesting to know, but I don't think it will.

Hampus, as you guessed it failed too.
Hope the log gives you some clue.

E:\Programmering\Hampus\C++\CD2ISO\DeviceReader.cpp:72 (ERROR): ReadFile() failed! LastError = 1 Incorrect function.

In my last post I executed cd2iso with the Ubuntu 8.04 CD I created from the official ISO file.
I tried again using Ubuntu 6.10 CD this time and it works (see log file attached).

This is the failed attept from my cd-rw.

A here it working on the dvd-rw in the same machine

Hampus, it might help if everything is in bytes and before each read you show bytwswritten and buflen

PS could it be that the file pointer gets shifted someohow (SetFilePointer)? So we do not start the read at bytwswritten? Also see if the asyn example helps http://msdn2.microsoft.com/en-us/library/aa365690(VS.85).aspx

Other odd thing. Isn't the buflen capped at 65536 bytes?

buflen = mTotalBytes - bytesWritten;
if (buflen > 65536) buflen = 65536;

...

char buf[buflen];
DWORD bytesRead = 0;
if (!ReadFile(mDeviceHandle, buf, sizeof(buf), &bytesRead, NULL))

Why is it that from the log each read is 17.5MB? Is this a logging artifact or is the stand-alone code slighltly different?

The progress is only logged in cd2iso.exe when it has incresed 2.5% since the last time it was reported. In reality the program makes 10000+ reads and therefore the log files would become quite large if something was logged about each of them. Inside the "main loop" cd2iso.exe only reports errors right now. The buflen and byteswritten are logged after a read failure though (and they aren't changed in that case either, so it's the same before and after the read).

So the progress reported is a logging artifact. The test app and plugin are slightly different though... I'll attach the source code, so that anyone can examine and/or experiment with it. It's easily compiled with Code::blocks (http://www.codeblocks.org/), in windows. A project file is included, so you only need to open it and press the compile button.

I don't think it's likely that the file pointer and bytesWritten get out of sync. It's hard to explain why it works in some cases then... Actually, it appears like the test application runs perfectly fine - even when it fails! Windows returns an error on the last ReadFile call, but as far as I can see there's nothing wrong with the actual calls. Cd2iso works under most circumstances, but sometimes windows returns some kind of error. The error codes are quite strange, but I think they are all some kind of "read errors".

Taking all this into consideration, the only explanation I can think of is that the cd2iso implementation makes the correct API calls and that the errors returned by ReadFile arise when Windows actually is unable to read from the CD/DVD. It is a little strange that this always happens at the end of the disc, but it can still be something that depends on Windows, the installed drivers, the CD drive and/or the disc used. My guess is that this mostly depends on the combination of the disc and drive.

I surfed the web a bit to find out more about CD/DVD read errors and apparently low quality CD:s and/or "sensitive" CD drives sometimes cause read errors (similar to the ones we are dealing with here). The CD might work in another CD drive and another CD might work in the problematic CD drive. The combination can cause errors, though. Burning a CD at lower speed seems to make the CD easier to read and therefore decreses the risk of read errors (the discs expand and vibrate when they spin very fast). To change the drive and/or disc media could make things work too (as we have seen in the comments above)...

It would be nice if we could find further evidence for this theory (or if someone could come up with another one, which would be good too). Your help, Juan Hernandez and davmor2, have been very valuable! The same goes for everyone else who have commented. One more thing that would be interesting to know is what would happen if davmor2 (or someone in his situation) tried to run cd2iso.exe with another CD in your cd-rw drive (the failing drive). Could you try that? Take a CD that you know are of really good quality (perhaps not a burned one).

If we are able to conclude that this actually is the cause of all these cd2iso failures, then we could add something about that in the installation guide and perhaps make the error mess...

Hampus,

I find the following report very interesting: http://ubuntuforums.org/showpost.php?p=4820648&postcount=27
But then he wasn't able to reproduce (see next post)

I can confirm that the issue seems to be a general Windows problem experienced with other ISO extracting tools as well (see for instance http://www.google.com/search?q=iso+%22The+parameter+is+incorrect%22+%22Incorrect+function%22 ). A bad medium seems to be one of the reasons, it is puzzling that the error usually happens at the end of the process though.

If no other solution can be found, we might want to trap the errors and display a clearer message.

A workaround is to only copy the squashfs filesystem as opposed to extract the full ISO (we already do md5sum check for it). This requires changes to casper though. See bug #230716

Tried running windbg to get a better result on cd2iso.exe . Everytime I try to add the process to windbg it hangs. Everytime I try to run the command from within windbg it dies.

This was tested by davmor2 in bug #204128, since that too involves installing off a CD

hmm re-reading davmor2 comments in 204128 I am not sure they satisfy 207137 since he did not specify whether he used the same CD device that created the original issues.

Can someone experiencing the same issue please test using Wubi 8.04.1 rev 504+ (http://wubi-installer.org/devel/minefield/Wubi-8.04.1-rev504.exe) and a CD created from the latest daily ISO (http://cdimage.ubuntu.com/hardy/daily-live/current/)?

I did test this and although I cannot reproduce the original bug, it worked for me and I did not experience any new problem (save bug #243105)

Because of bug #243105 we will have to revert the changes for 8.04.1

This is still an issue on my machine on the iso's set to be .1 . I've had to move on to test other things though so if you need logs ping me I will reinstall after and get them for you.

I've tried to debug cd2iso's source code. It seems that the ReadFile() always fails and spits out an error code 23 (CRC error) when read any of the last two sectors (or the last 4096 bytes) of my Xubuntu-8.10 (bug #306151) and Ubuntu-8.04 CDs. Then, I found an article <http://support.microsoft.com/kb/138434/en> which use almost the same way as cd2iso to retrive data from CD. However, there is a difference from cd2iso when you read "... the buffers used for the reads must be aligned on addresses that fall on sector boundaries ... An easy way to guarantee the that the buffer will start on a multiple of 2048 is to allocate it with VirtualAlloc ..." in the article. Tried to follow the article's instruction by modifying cd2iso's code...but it turns out to fail with the same problem again. After that, I started to suspect whether the CDs other than *ubuntu have the similar problem? ...yes, I did find a WinXP CD-R that makes the ReadFile() fails at the last two sectors, too. But, interestingly the error code this time becomes 87 (invalid parameter) rather than 23....

I believe there should be some way else to create iso images coz I can use Nero to create iso with respect to problematic CDs. And this bug may be too tough to be solved to me. But It seems not to be a critical problem for wubi as Hampus and Agostino probably have found the workaround for the issue as I can see from the previous discussion. Just wait for future releases at the moment.

Justin, thanks, very interesting, we did try to play with the buffer size but it didn't go too far, I am aware of other ISO extractors having the same issue, and I am sure there is a solution, but I wasn't able to find any literature on the topic and since I cannot reproduce the bug on my machine, it is quite tricky to debug this one. The workaround is to copy the CD content as opposed to extract the ISO, but at the moment that route is blocked by #243105

Just read the bug #243105 but I don't get it well (sorry, just a Linux beginner). So according to your post, does that mean there is no way to fix the bug so far? Because I can install Intrepid from CD (Wubi) without any problem, not sure if that means a solution has actually been found. Hopefully this bug can be fixed in the future...although I'm able to install Xubuntu and Hardy by DAEMON Tools. As Wubi is so important for any Windows user new to Ubuntu. Although I'm not an experienced Linux user, I believe that Ubuntu is the only version where the feature of Wubi can be found among all other versions of Live CDs such as Debian, Finnix, Gentoo Linux, Fedora, gNewSense etc.

I have had the same problem with my install within windows. I was able to solve this issue. I have dabbled with Linux from time to time with limited success so I guess a bit of a newbie. I will let the technical people sort out why this worked.

iso that I used ubuntu-8.10-desktop-i386.iso
Install symptoms were the same as described.

I re-burned my .iso using Nero 7 but changed two things(sorry hard to troubleshoot accurately with changing two things). I reduced the burn speed to the minimum 12X but I think more importantly I burned it as disk at once. Not track.

Successful install on my Dell at work and one my system at home.

If I can provide you any other information just ask.

Could you please test again with wubi 9.04 r97+?

Failed with 105

Did it happen at the end of the CD extraction process as before?

Dave, can you please check the md5 of the generated ISO (c:\ubuntu\install\installation.iso), the md5 of the CD, and the md5 of the original ISO? Ideally all 3 should be the same, even on error.

 I have asked Evan to provide a special build with a potential patch, you might want to test that too.

MAnaged to install off the folder and ubuntu is now alive! but cant use the cd as a source for getting my wirless card to run as it keeps denying its there! is this becuase i havent used a cd?! how can i get aorund this ?

Once you boot into ubuntu you should be able to see the CD under /media/cdrom or similar

yeah ic an see it and get accsess to it however evverytime i try to install new packages it keeps asking for the ubuntu cd and wants it in the dirive . its there~! it just cant seem to read it! :(

This problem still exists in 10.04. See #599884

I have done some testing creating a CD with Nero Burning ROM 6.6 from ubuntu-10.04-desktop-i386.iso.
As reported by nicobar in comment #48, if Disk-at-once is selected the CD is OK. Using track-at-once, the last 3 segments of 2048 bytes, which are all zero, seem not to get written and the problem occurs.
I used a hex editor to set the last few bytes of the iso to a non-zero value and burnt this to CD . Wubi copied this CD to the temporary iso successfully but then rejected it because the MD5sum was wrong.

I have looked at each of the desktop-i386 isos from 7.10 though to 10.4 burnt with Nero. I used a python script based on the code in 'copy_file'. In every case, it fails trying to read the last 6144 bytes (3 sectors) of the CD, which are all zeroes in the original iso file.
Has anyone had this problem with any burning software other than Nero ?

The copy produced by my script, which is attached, has the same MD5sum as the original iso