Seagate Disk Manager 9.57 Boot Iso FREE DOWNLOADl
Edel Dieringer
As far as I could tell, the problem was simply that the Kingston drive was too slow. Before it could finish loading those items, the boot sequence would time it out. Apparently the boot sequence would retry those items: the installation did eventually produce a normal-looking and -functioning Ubuntu desktop.
I wanted to create an ISO file that would capture an image of a customized, bootable Ubuntu USB installation. Ideally, that ISO would be compressed, so as to serve as backup for that Ubuntu installation; and, ideally, it would work in USB-burning tools like Rufus and YUMI, giving me single- or multiboot USB drives as needed.
This post focuses on Ubuntu tools that appeared capable of producing that Ubuntu ISO. As such, this post is a response to an earlier post discussing Windows tools that could similarly create and burn an ISO containing an Ubuntu installation on USB.
Answers to an Ask Ubuntu question presented a number of Linux solutions that may have been useful at some point, during the 12 years that had passed since that question was posed in 2011. As a few of the more recent answers and comments indicated, most of those solutions no longer worked and/or the software underlying them had eventually been abandoned. This post pursues one that did work.
At this writing, the most popular answer to that Ask Ubuntu question consisted of a manual approach written for Ubuntu 11. The last comment affirming this method was posted in 2019 and pertained to Kubuntu 18. I hesitated to pursue this potentially viable approach because it relied upon a number of commands that (judging from comments) may or may not have functioned as intended at this point, and that I did not understand well enough to troubleshoot effectively.
I wondered whether that shrinking of the primary partition would make the source drive unbootable. So at this point, I stopped the parade and used the source drive, duly shrunk, to boot another computer. I was pleased to see that it booted just fine, not even complaining about being out of disk space. So we were on to the next step.
Now, in the Ubuntu file manager, I right-clicked on the target drive, in the empty space under that newly created IMG file. That opened a context menu, from which I chose Open in Terminal. On the command line, I typed fdisk -l Output.img. That showed me information about the source drive partitions that Disks had captured in the Output.img file.
Cameron seemed to say I should focus particularly on two items of information: the sector size listed in the first several lines of output (in this case, 512 bytes), and the ending point for the last device that I wanted to keep. Fdisk appeared to indicate that Output.img captured the big program partition (i.e., /dev/sdb3, the one that I had shrunk) as Output.img3, and that it ended at 53110783. After that, there was just the empty wasteland. So my mission was to add 1 to that desired number of sectors (i.e., find where the wasteland began) and use it in a truncate command to get rid of that empty space at the end of the target drive. That command, and several after it, were as follows:
Note that this discussion pertains to a raw (i.e., byte-for-byte) image of the source drive created by Disks. The contents of a compressed image, such as that produced by pigz in my dd drive imaging command, would probably not be laid out in a sequential order that truncate could coherently modify.
There were two potential responses to that: either find a way to achieve, in GPT, what I had just achieved in MBR, as described above; or convert the GPT drive to MBR, and then use the method for MBR drives (above). This section explores the conversion option.
There appeared to be several possible ways to perform such a conversion. One was to perform a direct conversion. There were methods to convert GPT to MBR (and also vice versa) without losing data. A previous post describes one such method, involving eight distinct steps, and mentions another, involving the Windows program known as DiskGenius.
This time, I tried the DiskGenius approach. I found that, although Windows generated an error message as soon as I plugged in the Ubuntu GPT ext4 drive, DiskGenius recognized that USB drive nonetheless and provided an option (at menu > Disk) to Convert to MBR Partition Table > toolbar > Save All. I found that the drive was still bootable at the end of that process: it gave me a working Ubuntu system, same as before. GParted reported nothing amiss in its partitions and indicated, moreover, that that partition table was now msdos (i.e., MBR).
I assumed but did not verify that I could proceed, at that point, to subject that now-MBR drive to the truncate procedure described in the previous section. Instead, I contented myself with writing up the notes of other GPT-to-MBR conversion methods I attempted before rediscovering that DiskGenius method.
For recent versions of Ubuntu, such as my 22.04 LTS, it appeared that this could be more difficult than one might expect. The process would begin with creation of an Ubuntu installer. For that, among the options addressed in 1 2 Ask Ubuntu answers, I tried two approaches.
First, I chose the one using Rufus on a Windows machine. This did not work for me. I preserve the information here for possible future reference. The key points were to choose MBR partition scheme, BIOS or UEFI target system, and otherwise accept defaults. With an Ubuntu 22.04 installation ISO, Rufus produced a USB installer that booted an old Lenovo ThinkPad E430 laptop equally well in both Legacy (BIOS) and UEFI modes. With the machine booted in Legacy (BIOS) mode, I used that installer to install Ubuntu on another USB drive. I chose a minimal installation and declined to download updates during installation. At the Installation Type screen, it said the target drive had no detected operating system. I went with the default option: Erase disk and install Ubuntu. When it finished, I booted the newly created Ubuntu system. Here, again, that resulting USB drive booted equally well in Legacy (BIOS) and UEFI modes. (See also Ask Ubuntu.) Unfortunately, regardless of whether I booted the installer in Legacy or UEFI modes, the Gnome Disks utility confirmed that this resulting installation drive was partitioned as GUID Partition Table (GPT).
Maybe I did something wrong in that effort. Or maybe I misunderstood its GPT-to-MBR conversion potential. At any rate, if I did find a way to create an MBR installation, it seemed that I might be able to use that as a preliminary conditioning step: make it an MBR drive; then use something like GParted to copy the partitions from my preferred (i.e., more complex) Ubuntu installation to replace those on the newly created basic Ubuntu MBR drive.
For this, I posted a question. At this writing, the answer to that question appeared to be that there was no natural method of downsizing an image of a GPT partition. Instead, as elaborated in an Ask Ubuntu answer and a LinuxConfig tutorial, the solution would begin with a technically impermissible truncation of the GPT space, followed by a rescue attempt using gdisk and/or a script called gpt-fix. (The Ubuntu man page described gdisk as the GPT version of fdisk, with an ability to modify GPT partitions.)
There was still work to be done. The booted system immediately notified me that it had low disk space. GParted reminded me that this was because I had shrunk the now-restored partition. That problem would be rectified by restoring onto a suitably large USB drive, and then enlarging the program partition after restore.
Later, I realized there might be another way to see the outcome. Cameron had given me a way to create a 27GB Output.img that was much smaller than the original drive, eliminating the empty space that dd would preserve. Optionally, I could rename Output.img as Output.iso (see other post), so that an Everything search would find it among my other ISOs. Then I could use 7-zip to crunch it (as e.g., Output.iso.xz).
I had installed Ubuntu onto a USB drive, and configured that installation in various ways. I wanted to save that installation in a compressed ISO file that I could use as backup, and when needed could burn onto other USB drives, either single-boot (via e.g., Rufus or Balena Etcher) or multiboot (via e.g., YUMI).
This post reviews several Windows tools that seemed to have the potential to convert an existing USB drive to create that compressed ISO file. Another post reviews Ubuntu tools for that same purpose. It appeared the Ubuntu tools were likely to be more useful. (A different post explores Windows tools for converting Windows USBs to Windows ISOs.)
As such, this post adds to the explorations found in an earlier post and in posts linked in it, including the most recent update. Within a focus on converting Linux (especially Ubuntu) virtual machines (VMs) to physical installations, those posts looked at Ubuntu software that seemed to offer ISO-creation capabilities. The results were not particularly encouraging. It was possible that I overlooked solutions of merit, though those seemed to be relatively thorough explorations. Various websites (e.g., Ask Ubuntu 1 2 3) had explored possible methods and difficulties in the bootable USB-to-ISO process.
The central conclusion, from the following paragraphs, was that PowerISO, DiskGenius, and other Windows 10 programs could convert the contents of an Ubuntu USB drive into an ISO file, but that ISO would have important limits. Specifically, those programs captured those contents in raw form. That is, they copied everything on the source USB drive, byte for byte, without attempting to make sense of it. The result was an ISO as large as the drive itself.
My question was about the other half of that process. Could PowerISO, running in Windows, convert the contents of a USB drive, bootable in Ubuntu, into an ISO that could then be used to create another Ubuntu-bootable USB drive?
So I went ahead with the IMG option. To my surprise, the trial version copied the entire 25GB contents of the 64GB USB drive into its IMG file. That is, there did not presently seem to be any size restrictions on that particular operation.
7025e2c3df