[Continued from previous log entry]

During the course of my research, I discovered a helpful guide on AUTUIN's Blogspot article, which showed the steps for installing Debian on an emulated ARM machine. The guide provided a link to an archive containing QCOW2 images of pre-installed Debian Squeeze versions, suitable for running on QEMU. This was exactly what I needed, as it seemed to be the most feasible solution to obtain a Debian version with a kernel closely matching the ACN Iris 3000.

In the archive, there were two types of Debian Squeeze: a standard version and a desktop version. The standard version operated through a command-line interface, while the desktop version came with a comprehensive graphical user interface. Considering performance and compatibility, I decided to go with the standard version. The downloaded files included the kernel image (vmlinuz-2.6.32-5-versatile), the initrd image (initrd.img-2.6.32-5-versatile), and the QCOW2 image pre-loaded with Debian Squeeze (debian_squeeze_armel_standard.qcow2).

Before moving forward, I needed to ensure that Debian Squeeze would work flawlessly on QEMU. Thankfully, the instructions for this were provided on the archive page. Here is the Linux command used to run the above-mentioned files in QEMU:

qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1

Once this command was executed, a QEMU window appeared, and Debian Squeeze began to load. Upon completion, I was able to log in using "root" for both the username and password.

With Debian Squeeze confirmed to be running properly in QEMU, the next phase was was to transfer the virtual disk from the QCOW2 image (already loaded with Debian Squeeze) onto an SD Card. At this point, I was no longer dealing with a QCOW image but rather a QCOW2 image, an upgraded version of the QCOW format. Both versions, however, follow the same transfer process to physical media.

Before proceeding with the transfer, I had to determine the size of the virtual disk within the QCOW2 image. This was crucial for ensuring that there was adequate space on the SD card to accommodate the data transfer. While running Debian Squeeze in QEMU, I ran 'fdisk -l' to find out the size of the virtual disk. To my surprise, it revealed a size of around 26.8 GB, much larger than the original QCOW2 image size of 305.9 MB. The difference was quite significant.

The reason for this discrepancy lies in the fact that QCOW images use a copy-on-write strategy, which helps save space and grow as data is added. To better explain this, think of a QCOW image like an expandable suitcase. When it's empty or only partially full, it takes up minimal space, which is akin to the actual size of the QCOW image file. However, like a suitcase that can expand to accommodate more items, the QCOW2 image has a 'maximum defined capacity' or a 'full potential size'.

So, when this QCOW2 image is loaded into QEMU or transferred to an SD card, it's not about how much it currently holds (actual used space) but rather, its total capacity to hold more (maximum defined capacity). That's why I opted for an SD card that had enough room to fit this maximum capacity, and I chose a 32 GB SD card for this purpose.

Although technically I could have shrunk the virtual disk to reflect only the actual used space, allowing for the use of a smaller SD card, I chose not to go down that route. This decision was motivated by concerns of potential data corruption and the complications that could arise from such an operation. Furthermore, it's usually beneficial to have additional free space for system operations and performance, including software installations.

Taking all these considerations into account, I committed to transferring the entire 26.8 GB virtual disk onto a 32 GB SD card, as stated before. This choice signified the conclusion of QEMU's role in this particular project.

[To be continued...]