Nil said:
If he is, he's talking about something completely different than
everybody else is, even though the subject has been clarified several
times. We've very specific about it being a "Live Linux" bootup disk,
not an install-to-hard-disk situation.
I've got on computer running one of those Wubi installations, and
Unbuntu is presented as a choice by Windows boot manager. This is my
Linux play toy, not something I used day-to-day.
Yes. That's what I've been trying to get across.
I just tried setting up a Wubi based install here, and no dramatics.
First, I had to pull the network cable, so Wubi would recognize
the .iso file with the 700MB of install files on it (located in
the same folder as wubi.exe). If you leave the network connected
for the first phase, it instead starts the 700MB download for itself
(with no confirmation of what version you want to install). I didn't
want any installs with Unity, so dropped a 10.04LTS .iso file into
my wubi folder. The wubi.exe was extracted from the .iso, with 7ZIP.
It prepares a couple ~4GB files as storage space. I told it, it
could have up to 8GB, and my Windows file system is FAT32. So it
knew not to make containers larger than 4GB each. It made three
containers (for loopback mounting) with its own division of labor
for each one.
It copies the files from the 700MB .iso, into one of the containers.
Looks like the files are uncompressed at that point.
Then, it reboots, and it has meddled with boot.ini, so the system
is now dual-boot on one disk. I select Ubuntu from the Windows boot
menu, and then the installer continues on with the installation.
The installer at that point, could be the regular Ubuntu installer.
The files then seem to be copied one more time, presumably from
the uncompressed store that was created on the first pass.
The usual unnecessary downloads from Ubuntu (stuff not on the CD),
and after about 15 minutes of screwing around, it's done. I'd
plugged the network cable back in, so the network would be
available after the first reboot.
On the next reboot, selecting ubuntu again from the Windows boot
menu, it comes up in the 10.04LTS desktop (which is the file I
located next to wubi.exe). The desktop seems to work. And the
one partition I gave it (a precise copy of my normal WinXP partition),
it has mounted the Windows file system as /host.
So really, nothing bad happened.
The wiki for the usage of wubi.exe, warns about "dirty shutdowns".
It says people who become frustrated, and switch off the power to
the computer in mid session, are their own worst enemy. The article
also mentions you can go to "found.000" in Windows, and sometimes,
your damaged Ubuntu containers can be found there. Since nothing
froze or acted up during this short test, there were no fireworks
to report. And no need to press the reset button or the like.
I can think of a case, where "pressing of the reset button" would
be a natural user response. Canonical was clever enough, on their
servers, to turn off ICMP services. Leaving the servers with a
"black hole" problem. Then, what happens is, the Ubuntu installer
starts downloading additional packages from the Canonical servers,
and the process gets stuck at exactly the same place each time. I
had that problem with native installs to a separate hard drive. I
found a thread with a ton of people complaining about the same thing.
One contributer to the thread, types three words in his message
"change your MTU", with no explanation or anything. OK, so I'm reading
the thread, and considering all the possibilities. And after about
another ten minutes of reading, it dawns on me "Oh, shit, a black hole
problem...". That's what the "change your MTU" contribution meant.
I've dealt with that once before, and changing the MTU did indeed
allow the install to finish.
Now, if you were in "WUBI country", and that bug came up, then
what would you do ? The thing is stuck, you need to escape, everything
is dead (because the kernel is deadlocked at that point). Not even
control-alt-delete works. On a native file system install, no
problem, your ext4 probably needs cleaning on the next reboot, or
if like me, you restart the install, you've probably formatted the
thing again anyway. So no damage done. But if you were doing that from
WUBI and that happened, now the damage could be to the Windows file
system (as a dirty shutdown). Either the file system, or the containers
being used by WUBI, would be candidates for damage. And no way for
me to predict, how likely that would be.
So that's the only exposure that comes to mind. The "black hole" problem
had been around for a while (complaint thread was super-long).
Anyway, I didn't get stuck, so I presume there isn't a black hole
exposure if you're installing 10.04LTS (which is apparently still
supported package-manager wise, until some time in 2013?). Since
Canonical has more than one server for things like this, it's
really hard for me to guess which server had the problem, and
causes the install process to deadlock.
Paul