OS Platform Compatibility, in a Laptop Recovery View - Filesystem Compatibility, Binary Incomptibility

Recently, my primary laptop became effectively bricked, insofar as booting from the laptop's internal hard drive and booting to the MS Windows 7 installation, on that laptop. It's a Toshiba model, an A665, with a thin form factor not affording much air circulation internal to the laptop. The laptop has a wide screen and a contemporary Nvidia graphics card. It has been my "main laptop," for a couple of years. Tasks that it is not bricked for would include:

•  Boot from external DVD drive or flash media
• Chroot to the Linux partition on the internal hard drive -- the SystemRescueCD can be used to manage the chroot environment of the same, for simple recovery tasks, albeit with some concerns as in regards to kernel compatibility and device creation under devfs
• Mount the Windows main partition or either of the recovery partitions on the internal hard drive

I've tried to fix the MBR on the internal hard drive, using TestDisk, such that is distributed on the SystemRescueCD. However, the laptop is still not bootable from its internal hard drive. I plan on holding onto the laptop nonetheless, until if I may be able to replace the internal hard drive with an internal SSD drive, and to re-image the "Good partitions" from the existing internal hard drive onto the ostensible SSD drive, certainly not carrying over any "Bad bits" from the MBR sector or however.

In short, I can boot the laptop from an external DVD drive, and can mount and chroot to the Linux partition on the laptop, and from there, I can mount the Windows partitions. It's fine for filesystem recovery, but with the internal hard drive in an unbootable condition, and with the recovery media unable to boot the existing Windows partition -- though it can mount the same --  to my observation, it's effectively "Nil" for running any of the Microsoft Windows software installed on the same.

I've reverted to an older laptop, an older Toshiba, such that has Windows Vista installed. That's been sufficient for running the software required for courses at DVUO, however I am certainly interested in rendering my "Main laptop" usable, again, at least on its Linux partition, and without the DVD dongle. It would serve at least as a cross-compiling platform for the ARM architecture.

As of when my "Main laptop" became unbootable, then my Chromebook became the effective "mainstay" for developing on Linux, on my "Home network." It's a Samsung Chromebook. Samsung Chromebooks use an ARM architecture -- I'd chosen the particular model of Chromebook, as due to that, when I purchased the Chromebook from BestBuy, on my student budget. I've since enabled Developer Mode on my Chromebook and installed a KDE desktop environment into a chroot, using Crouton, furthermore referencing a "How To" published by HowToGeek, How to Install Ubuntu Linux on Your Chromebook with Crouton.

The chroot environment on the laptop is using Ubuntu Linux, edition 12.04. "Precise". The Linux kernel is version 3.8.11, armv7l architecture.

To my understanding, QEmu is unable to create a VM on the ARM architecture. Virtualbox is not available for Linux ARM, either. Failing any other alternatives for OS virtualization on Linux ARM, my Chromebook therefore cannot serve as a virtualization host.

There are a number of software applications that I would prefer to use on my Chromebook -- including Modelio, and the latest edition of the Eclipse IDE -- but which are not immediately available on Linux ARM, and are available on amd64, such that is the architecture of the Linux installation on my main laptop. Given that my ARM chromebook cannot emulate an amd64 environment, not to my understanding, I shall have to either do without those applications, indefinitely -- an undesirable situation, certainly -- or I shall have to figure out how to recover my A665 laptop, at least so far as that it can boot without the "DVD dongle"

My A665 laptop can boot from USB. Of course, all that I need to have it boot from USB would be: The boot loader, ostensibly. There's already a working configuration of a Linux root partition and swap partition, accessible after boot, on the internal hard drive of the laptop. I might as well wish to install a minimal OS configuration onto the flash media, however -- something that could at least run a shell, in an event of that flash media being the only usable media in the laptop.

I've yet to find a "Pre-built" Linux USB thumb drive distro that would be clearly compatible with this particular use case -- basically, just an external, chained boot loader -- moreover in a minimal filesystem configuration.

This morning, I have begun to read up about Ubuntu Core, a minimal Linux distro.

If I was able to run a virtualization environment on my Chromebook, I could begin to configure a thumb drive for using Ubuntu Core, immediately, using chroot and/or QEmu. There would be a certain matter of "platform difference", as between the host platform and the target platform, however, when my Chromebook (ARM) is the host platform, and the A665 (amd64) is the target platform.


Here is a model for a Platform view of my own PC environment, expressed in a sort of ad hoc UML notation:

[Target Platform <<Platform>>]-*----+-[Filesystem]
  |
  |+
  |
  |
  |+
  |
[Host Platform <<Platform>>]-*----+-[Filesystem]

In the situation in which the Ubuntu chroot on my Chromebook (armv7l) would the ostensible "host platform," and the "target platform" is amd64, but the former is a host platform that is currently unable to run virtualization software, to my best understanding. The ARM and amd64 architectures would be  incompatible, moreover, as due to "something in regards to ABI,"broadly.

Effectively, an ARM Chromebook cannot serve as a complete host platform for building and testing of a recovery disk for an amd64 OS.

Of course, a host platform running an ARM Linux OS can be used to transfer a filesystem image to a storage device supported by the host platform, and can mount an EXT2 or later edition EXT_ filesystem from a supported storage device or, can mount a filesystem directly from a block device image -- like as in a manner of flesystem compatibility. However, if the target platform does not implement a processor architecture similar to that of the host platform, then the host platform cannot  effectively chroot to the target platform's root filesystem, as the machine-dependent files on the chroot 'target' would be binary incompatible with the machine architecture of the host platform.

In summary:

• ARM and AMD64 Architectures : Binary incompatible, in machine-dependent files
• EXT4 Filesystem: Compatible with any OS such as can mount an EXT2 or later EXT_ edition filesystem. Mounting an EXT4 filesystem as EXT2, of course, would entail a certain loss of features available in EXT4 (cf. filesystem journaling) for the duration of time in which the filesystem would be mounted, in the host OS.

In extension: Use cases for a dynamic host platform modeling interface

• Filesystem Imaging
• Integration with functional filesystem management tooling (favoring command-line tools)
• Cross-Compilation
• Integration with functional distribution management tooling (favoring command-line tools)
• Network Management
• Integration with functional user authentication interfaces (Kerberos, etc)
• Integration of network models (Ethernet/WLAN, IPv4 protocol stack, etc)
• Integration with networked host control interfaces
• SSH - Command line interface
• CORBA - Distributed network host management interface TBD