I was trying, without success, to boot a desktop machine, using Ubuntu 10.10 or 12.04. I had both versions available on CD and also on a YUMI multiboot USB drive. I was doing this at a time when I was distracted by other projects and especially unwilling to devote time to this particular issue; hence, this post wound up being long and tangled, where in other circumstances I would have broken it out into two or more shorter and more focused pieces.
The just-cited post on YUMI was followed by a couple of comments. The second such comment indicated that the problem I was now experiencing seemed to be related to the specific computer, since Ubuntu had booted successfully from these same CD/USB sources on other machines. It seemed, moreover, to be a problem with Linux specifically, on that specific computer: the computer would boot and run a Windows 7 Repair/Recovery CD, and would also run GParted, but not Knoppix, from the YUMI drive.
A search seemed to indicate that this was a common problem. Some of the answers posted in response to other questions of this sort were addressed to common troubleshooting steps (e.g., make sure the CD was burned properly; make sure the machine was set to boot from CD). The preceding paragraph seemed to address some of those ordinary suggestions.
As I browsed a Wikipedia comparison of Linux distributions, it occurred to me that the problem might be that the desktop computer was a 64-bit machine, whereas the other computers on which I had previously tested these CDs and USB drives were 32-bit. I looked at the architecture table in that Wikipedia page, to find a version of Linux that would support a 64-bit system. But I saw there that, while Knoppix did not claim to, Ubuntu did. Generally, the distributions seeming to support the largest numbers of architectures were Debian (on which Ubuntu was based) and Gentoo, but many distributions were said to support the x86-64 architecture.
I wondered if a different Linux distribution might fare better. I searched for favored distributions, looking particularly for those that seemed to be well-supported and robust (i.e., most likely to roll over hardware problems that would stop others). Along with Ubuntu, for my purposes one webpage suggested Linux Mint (a Ubuntu variant); a Lifehacker page echoed that and also mentioned Fedora, Debian, and maybe OpenSUSE; a Techradar webpage named these same distros and added Puppy Linux to the list. Another webpage, while again mentioning largely these same distros, also suggested that CTKArch provided the fastest live CD. Finally, among the two dozen Linux distributions cited on a MakeUseOf webpage, it tentatively appeared that it could be worthwhile, under present circumstances, to try Bodhi Linux, which (like Puppy Linux) was supposedly very adaptable to older (and perhaps generally less cooperative) hardware.
Based on writeups for these distributions, I decided to try Mint, Debian, Puppy, CTKArch, and Bodhi. I downloaded both 32- and 64-bit options where available. This took a while. (I could have used YUMI’s installer to download them one at a time, at installation time, but I wanted to set up the downloading project and turn to something else, using torrent downloads to ease the load on the servers where possible.) When the downloading had finished, I had the option of putting these ISOs onto separate USB drives, assuming I had enough drives available (or was willing to redo the process, overwriting whatever had been previously installed on a given single-purpose USB drive). For the single-purpose approach, I would use Universal USB Installer or UNetbootin. The former (and probably also the latter) had specific options for most if not all of the Linux versions mentioned above. One apparent exception was CTKArch, for which I would apparently have to use the “Try Unlisted Linux ISO” option on Universal USB Installer (or whatever the equivalent would be on UNetbootin).
Before turning to that more limited single-purpose method, I decided to see if I could add these Linux distributions to my existing YUMI drive. I plugged in my 16GB USB flash drive, waited for Windows 7 to tell me that it had installed the driver software, and ran YUMI. Proceeding through these new distributions in the order indicated at the start of the preceding paragraph, I looked first for Linux Mint 13, which was the version that I was downloading. Mint 13 wasn’t on the list. Apparently I needed a newer version of YUMI. I downloaded and ran that. I had downloaded Linux Mint Cinnamon 32- and 64-bit ISOs, and the new YUMI offered separate options for each, so I went ahead and ran the YUMI process for the 32-bit version. It looked like it was going to run for several minutes, but then it quickly gave me “File is broken” error messages. When I closed the error message dialog, the YUMI process continued; but since the installation was apparently flawed, I re-downloaded the 32-bit version. I chose the option to install more ISOs. I noticed that the 32-bit option had disappeared from YUMI’s menu, so I chose the “Remove an Installed Item” option to enter Uninstaller Mode. I uninstalled and reinstalled the 32-bit version, and then went ahead with the 64-bit version. That installed without errors, requiring maybe two minutes altogether. The process was pretty much the same for the 32- and 64-bit versions of the other distributions listed above: Debian, Puppy, CTKArch, and Bodhi. YUMI offered only one Bodhi option, so I used that for the 32-bit version and then used the Unlisted option for the 64-bit version. Aside from that first problem with the 32-bit Mint, none of these installations gave me any problems. At this point, I had used up all but about 1GB of my 16GB USB flash drive, so I was pretty much maxed out on Linux distributions for the time being.
Now it was time to try that hopefully new, improved YUMI USB drive. I plugged it into the troublesome desktop computer and tried to boot it. I got the YUMI menu with, as expected, an enhanced list of Linux distributions including two (i.e., 32- and 64-bit) versions of Debian and Mint, and with Puppy and Bodhi (in the order in which I added them, unfortunately — not in alphabetical order); and under the Directly Bootable ISOs menu pick I now saw two additions for CTKArch. For Unlisted options like CTKArch, the names listed in YUMI were the names of the ISOs (e.g., ctkarchlive-0.7-i686.iso), not pretty names like “CTKArch 32-bit.” I tried booting 64-bit Mint. (I had opted for the live version, where that was an option; Mint was one of the distributions that had offered that.) Unfortunately, it froze at the same “Freeing initrd memory” line that had stopped one or more of the previous Ubuntu and/or Knoppix attempts (above). This was not a terrible surprise, since Mint was apparently derived from Ubuntu. (For some of these boot efforts, I would wind up with a “boot:” prompt. Hitting Enter got rid of the “boot:” prompt and put me on through to the YUMI menu.)
I feared the same for 64-bit Debian, from which Ubuntu was in turn derived. But I was wrong: Debian froze at an entirely different place. The line that was trying to load in this case said “[0.768216] pci 0000:02:00.0: PME# disabled.” Progress! (not really). Next, going down the list, how about Puppy Linux? It sure looked different from Ubuntu at this startup stage, with just a few colorful, mostly plain-English descriptions of what it was doing. And, yes! Houston, we had an interface! It booted, and finished with the sound of a barking dog that was plainly no puppy. I’d say it was two, three years old at least. But no matter. Puppy liveth! I rebooted and tried the others that I had just installed. I got the “Freeing initrd memory” freeze for Bodhi, and I got a dead cursor with CTKArch, after an initial “Booting Boot ctkarchlive-0.7-x64.iso from Memory” message. I wondered if maybe the latter would have worked if I had configured YUMI not to use the install-from-RAM option for the Unlisted ISO menu selection.
I thought for a moment that something else might be happening with CTKArch. At one point, that dead screen flickered, and the YUMI penguin logo was back (or maybe it had never really left) — but I wasn’t seeming to get any serious action. I let it sit while I was typing these words, and after a couple of minutes YUMI took it back home, back to the YUMI menu. That is, YUMI kept me from having to do a system reset (i.e., punch the reset button) to get back to the YUMI menu; it killed the dead program automatically. I wondered if this was a special feature of YUMI’s Directly Bootable ISOs menu — it didn’t offer any such service for the Ubuntu-style frozen screens, no matter how long I let them sit.
So Puppy Linux was my one success story. It seemed that I might have had more success stories if I had chosen another one or two distributions that did not have close ties to Ubuntu or Debian. Like SUSE, maybe, or Fedora. For purposes of future modification of the YUMI multiboot USB drive, I knew now that there might be situations when it would be useful to include one or two Linux distributions other than Ubuntu, Mint, or Debian. The ability to use Puppy Linux told me that the problem I was having with that computer was not necessarily with Linux per se, nor with the use of a YUMI drive on that computer. It seemed to be ultimately traceable back to Debian.
The immediate need that had motivated me to try to boot that computer into Linux was that I wanted to run GParted to check my hard drives. I had found that GParted provided a good, quick glimpse of whether it would be necessary to run a time-consuming CHKDSK /R process on that computer’s various partitions. Puppy Linux did have a copy of GParted, so apparently I was home free. I poked around to see what else it had. I didn’t see Firefox, and wondered what its built-in Internet browser might be. I saw something called Dillo, but when I clicked on that menu option, the Puppy froze. Hmm — maybe this Linux distribution was a dog. I rebooted and went directly to GParted; no more fooling around. For one drive, it gave me an “unallocated” error that I thought I had fixed in a previous struggle. The problem was surely with GParted, there: I had just been using that partition in Windows a short while earlier. Could this error possibly be due to running 32-bit Puppy on 64-bit hardware? Puppy also offered a Pdisk partition manager, and I ventured into it as far as the point where it was asking whether I wanted to use FDISK or CFDISK; and since I didn’t know the difference, I bailed out. Now, I thought, would be a great time to try something else.
Back on the computer where I was doing my downloading, I fired up the YUMI installer and viewed its options. At random, I looked in vain for a YUMI option to add TestDisk. There was nothing for it per se, but CGSecurity said that TestDisk was available on a number of other live CDs, including those for BootMed, GParted, Parted Magic, and SystemRescueCD. (It could be added to many Linux distributions, but that was cold comfort to those who wanted a self-contained live CD.) This line of inquiry led me around to a Wikipedia list of bootable data recovery tools, including BartPE and Hiren’s BootCD. Of these, the ones that were new to me or had recently been updated (see previous YUMI post) were BootMed, GParted, Parted Magic, and SystemRescueCD. I decided to download and install these on the YUMI drive, along with Fedora.
To make space for these new additions, I used YUMI’s installer to remove nonworking programs and distributions from the flash drive. This called for some attempt to verify (from the previous post and from new experiments) a clear list of installations that did and did not work on a 32-bit and/or a 64-bit machine. Along with the nonworking ones, of course, I did not need to install those that were already included in some other catch-all program like UBCD. At worst, there might be a few that I would have to install later. I would have to balance the aesthetic demerits of installing programs later, not in neat alphabetical order, against the aesthetic demerits of cluttering my drive and its menu with nonworking crap.
The resulting experiments revealed a simple but important flaw in my previous installation. As many simpletons might know (but I did not), a space in the filename of an ISO could be enough, by itself, to render it nonworking in YUMI. No doubt this information was in the manual. With a space in the filename, I would get the “find –set-root –ignore-cd /multiboot/ISOS/” error mentioned (I think) in the earlier post; without a space in the filename, I would sail right past that . . . and wind up with a BSOD a few seconds later. As I had learned some years earlier, this was the difference between a failed and a successful installation of Windows 98. Or of XP, as was more the case at present. I found, also, that the 32-bit counterparts of the 64-bit versions that had failed (above) (e.g., Mint, Debian) all ran on a 32-bit computer, except for CTKArch.
After removing the spaces from those filenames and reinstalling the ISOs, these new additions to the YUMI drive all ran on at least one computer, if not both, except for BootMed, SystemRescueCD, and Hiren’s Boot CD. YUMI’s installer had led me to think that I had successfully installed version 9 of Hiren’s, and yet it did not even appear on the menu. (Webpages purporting to be related to Hiren claimed to offer a version as late as 15.1 for download, but provided no actual download link. The ISO was also not available at CNET or Softpedia. I’d had this same problem a few months earlier. I was not sure whether Hiren’s webpage was a joke or was just an attempt to get people to click on as many Hiren-related webpages as possible, to generate advertising revenues. In any event, this YUMI USB did not include a copy of Hiren’s Boot CD.)
These efforts resulted in the following revised list of programs and Linux distributions that I wanted on a YUMI USB drive that I would be using on 32- and 64-bit machines:
Of these, Puppy was the only one that would work on the 64-bit machine.
Acronis True Image Home 2011
Hard Drive Diagnostics (Hitachi, Samsung, Seagate, Western Digital)
Microsoft Windows Memory Diagnostic
Super Grub Disk
Super Grub2 Disk
Universal Boot CD (UBCD)
U.S. DoD Lightweight Portable Security
Windows 7 System Rescue CDs (32- and 64-bit)
Windows 7 Full DVD
I didn’t know if I would ever need that last item. I suspected it would be much faster to install an operating system from a DVD than from a USB drive. For tasks other than installation, the System Rescue CDs would be adequate.
Note that, when I say these programs ran successfully on the YUMI drive, in some cases I just mean that they ran without any problems that seemed relevant to YUMI. Some (e.g., Samsung, Windows Memory Diagnostic) had other problems (related to e.g., computer memory exceeding 4GB, or no Western Digital hard drives being found in the system). I didn’t instruct YUMI to run any of these from RAM, since I could not predict what kinds of machines I might need to use this on.
I had to reformat the USB drive and start over from scratch, once I had experimented and figured out my list, because (as I discovered) the YUMI installer did not offer a removal option for any of the items that I had installed under its Unlisted option. I couldn’t have a clean menu, and make space for the additional programs that I was now installing or might install in the future, without first eliminating those that were not serving any purpose.
With that done, I hoped I now had at least some kind of updated version of, or good replacement for, GParted, such that I could boot the Windows computer from the USB drive and quickly check whether any partitions needed me to boot from the Windows DVD (or, now, from the YUMI drive) and run CHKDSK /R, without wasting time on unnecessary CHKDSK operations. I had noticed the claim that GParted had recently been updated, though I couldn’t quite figure out how: the version number didn’t seem to have changed. But whether using GParted or something else, I hoped that at least one of these multifunction tools would have something capable of checking NTFS file structures.
With that objective in mind, I plugged my newly reshaped YUMI drive into the 64-bit machine and set out in search of a GParted-type tool. The field was quickly reduced to a few candidates. More precisely, when Partition Wizard froze, there was only one choice: Ultimate Boot CD (UBCD). Within UBCD, there was Cute Partition Manager, GParted, Parted Magic, Partition Resizer, Partition Saving, Ranish Partition Manager, and several FDISK variants. This field, in turn, was narrowed as well. Cute Partition Manager (circa 2007) gave me an “Error loading partition table. Reason: Lba out-of-range,” presumably meaning it wasn’t built to handle hard drives as large as 1TB. The version of GParted included in UBCD was incorporated in Parted Magic, which froze just as surely here as it had before, the first time ever I ran it in this project. The low RAM settings alternative for Parted Magic seemed unnecessary and did not in fact make any difference.
We came slightly closer to home with Partition Resizer. The note at the bottom of the screen, when I ran that program, said it would handle drives up to 2TB. This was heartening. I was only momentarily deterred by its emphatic warning not to proceed without reading the README.1ST file. I wasn’t sure where that was. Partition Resizer proceeded to check and give me information that I had overlapping partitions, a FAT partition damaged or not formatted, and a partition extending outside the disk limits. Memory of my earlier problem (see previous post) vaguely suggested that this last error was the reason why GParted was balking. It asked me if I wanted to ignore those errors and continue. It warned me that I must be ABSOLUTELY sure I knew what I was doing. It was a lot to ask, really. But, yes, now that they mentioned it, it probably was easier to bail out.
The only other program on the list, other than venturing into command-line territory with FDISK et al., was Ranish Partition Manager. It offered three kinds of options: UMBPCI (fast), EMM3868 (more compatible), and UMB (unexplained). The sub-options seemed on target: the notes said that I should use a defensive mode (such as UMBPCI’s “semi-defensive”) if the computer froze. I started with UMBPCI semi-defensive. It put me into an old Norton-style text-based screen with information on hard drive partitions — or no, as I looked at it, it was starting with information about the USB drive. I hit F5 to toggle through the other drives in the system. On hard disk 2, I saw red print. When I went to that partition, it listed problems: “Partition addresses are out of range” and “Boot sector doesn’t have valid information.” Well, but what was I supposed to do about that? I hit F4 to change modes, but this just toggled display modes. F1 for Help listed options to erase, format, copy — but nothing that looked like repair. Ah, but then I understood: I was supposed to just go ahead and type what the correct values should be. My problem was, I had no idea. I hit Esc and exited.
This encounter with Ranish taught me something. It taught me what a hellacious advance GParted was, in comparison with the tools I had struggled with in the 1980s and 1990s. Not for people who understood this stuff, but for those of us who did not. I booted into Windows, just to stop being scared, and hit Start > Run > diskmgmt.msc. It said, “Everything is fine. Get some sleep.” Seriously, it saw no problems with any partitions. Once again, this was what I had gotten last time around. So whom was I to believe: Windows, which could be terribly clueless, or these antiquated programs with specific numbers of blocks and cylinders that didn’t add up? And, just as important, why was this problem recurring? I had used GParted to create these partitions; what changed?
I looked back through my previous post again. Partition Wizard seemed like a serious tool. A bit of browsing revealed that MiniTool, its creator, had come out with a new version. I wasn’t seeing a version history webpage, but my version 5.2 (apparently downloaded in January 2011) was already getting long in the tooth: the current version was 7.5. I should have checked before trying that older version. So, OK, I went into YUMI’s Uninstaller Mode, removed the old version from the USB drive, and downloaded and installed pwhe7.iso (i.e., the “bootable CD” file for version 7.5) on the YUMI drive. I booted the 64-bit machine with the YUMI again. Now, for some reason, there were two Partition Wizard entries on the YUMI menu (though it appeared this could be edited). But no matter: both froze at the same place. The last visible line read, “system 00:01: [io 0x0290-0x0294] has been reserved.”
I hadn’t checked all of these various failing Ubuntu distributions and programs (like Partition Wizard 7.5) on single-purpose USB drives. But I didn’t expect good results from such an endeavor: Ubuntu had failed to boot on this 64-bit desktop computer, regardless of whether I tried booting it from a single-purpose or multipurpose USB drive or a live CD. Just to be sure of the situation, I tried booting some of these programs and distributions from the YUMI drive on a second desktop computer with very similar hardware, running the same 64-bit version of Windows. But — whoa, what’s this? — on that 64-bit computer, 32-bit Ubuntu booted! I tried two other programs that had failed on the other desktop computer: Partition Wizard and Parted Magic. The former ran; the latter had an error message that appeared to be related to the program (“The pmagic-6.6.sqfs file could not be found”), presented in pretty little multicolored letters, unlike the coarse white-on-black error messages that I had been getting previously. So the problem I had been encountering was apparently due to the specific hardware of the one machine as distinct from the other.
Well, that seemed like something that I should have tested for previously. Blame it on the wee hours and the full moon. At this moment, I wasn’t inclined to test all aspects of the hardware on the troublesome machine, but perhaps I could do a partial quick test as to whether the problem was video-related. I unplugged the monitor from the video card and plugged it into the onboard port, and rebooted. But that test yielded nothing except the bending of a (or possibly the discover of a bent) DVI pin: no difference in the success or failure of Ubuntu booted from the YUMI drive. On both computers, I did notice that sometimes (apparently after a hard reset) the system would ignore the YUMI drive and proceed directly into Windows, despite BIOS settings to the contrary, requiring a soft reboot to recognize the YUMI drive. But this was an issue I did not pursue.
There were a few other possible sources of the hardware problem. I suspected RAM, and made a note to test it, but those tests almost always went OK. The other possibility was the more souped-up CPU I had running in this recalcitrant machine. I was not inclined to test all the possibilities now.
The situation seemed to be that I had at least two distinct problems. First, for some reason, this particular computer was not interested in running live (i.e., CD- or USB-based) versions of Ubuntu and some other programs, most if not all of which may have had a shortcoming traceable back to Debian or to Linux (or, I suspected, to some particular drivers related to some specific hardware in that computer). Second, when I ran GParted on this refractory system, I got an “unallocated” error on one drive. It was a problem that other tools (above) had been more articulate about, and seemingly more able to fix. For that, one option would be to put the drive in the other computer and use Partition Wizard or some other program there. Another option would be to install a Windows-based partition editor like EaseUS Partition Master (free version) and modify the drive that way. (Later, when I did this, I saw that EaseUS found no problem with the drive, adding to the suspicion that the problem was, rather, with GParted.)
Working out those problems would take further time. They did not necessarily relate directly to the USB drive, so I didn’t elaborate on them here. Hence, this post provided an update and further information in response to the previous post, but did not yet offer a specific solution to the problem that Ubuntu was not booting in that particular computer.