MX-Linux in VBox

[raymac46]

After my glitch with EndeavourOS, I have now installed MX-Linux in Vbox. It works very well, with the Guest Additions giving a full screen. I'll update as needed and see if I have any issues. Since MX is Debian-based and uses apt, if I have trouble, it'll be because of Vbox itself, I think.

[securitybreach]

Cool, enjoy

[crp]

8 hours ago, raymac46 said:

After my glitch with EndeavourOS, I have now installed MX-Linux in Vbox. It works very well, with the Guest Additions giving a full screen. I'll update as needed and see if I have any issues. Since MX is Debian-based and uses apt, if I have trouble, it'll be because of Vbox itself, I think.

passing the buck already

 

[raymac46]

MX is more stable and uses a different package manager so if I have the same issue I would conclude that the root cause lies with VBox.

[Hedon James]

3 hours ago, raymac46 said:

MX is more stable and uses a different package manager so if I have the same issue I would conclude that the root cause lies with VBox.

I would tend to agree.  But you can't rule out the combination of something in Arch-based distros (pacman, octopi?) in combination with something in VBox.  2-prong errors are extremely difficult to diagnose, and sometimes you need a little luck to figure it out.  Wishing you that little luck...just in case!

[raymac46]

Nothing here is mission-critical and I could back up the working machine if there were any critical data. But it must be some sort of VBox issue since you don't get it in another VM and I haven't seen it in any bare metal installation. Agree it would be hard to diagnose.

I think some files related to the keyring and the mirrorlist are getting truncated and hence corrupted, so Pacman won't work. That link I posted suggested a fix, but it isn't worth the hassle when a reinstall takes about 10 minutes.

Virtual machines are great but they do add a level of complexity (one more thing to go wrong.)

[raymac46]

Just updated the kernel, rebuilt a number of modules, and rebooted. All is well so far.

[abarbarian]

On 11/11/2024 at 1:54 PM, raymac46 said:

Virtual machines are great but they do add a level of complexity (one more thing to go wrong.)

 

Agree completely. Which is why all those article/test/review authors should run their article/test/review distros on bare metal but most of the lazy sods do not and yet they claim to be "experts". 

[Hedon James]

4 hours ago, abarbarian said:

 

Agree completely. Which is why all those article/test/review authors should run their article/test/review distros on bare metal but most of the lazy sods do not and yet they claim to be "experts". 

anyone who self-claims anything makes me IMMEDIATELY skeptical.

 

I know LOTS of "smart" people, but I have never once heard any of them proclaim their intelligence.  Same with "experts".  Those adjectives are conveyed by others; it doesn't count if you give it to yourself.

[securitybreach]

The more you know about a topic, the more you realize what you do not know.

[raymac46]

I think it depends on your expectations. Any long-term test of stability or otherwise *must* be conducted on bare metal. However, if it's a brief look at a distro's desktop and applications I don't see a problem with checking it out in a VM.

When I first got interested in Arch Linux I installed it several times in VirtualBox before attempting a "real" installation. That way if I borked things halfway through it was easy to nuke and start over.

Some VMs I've found (mostly Debian types) are pretty stable. A VM experiment is usually better than running a distro Live. And certainly less risky than dual booting in my experience.

[sunrat]

A good thing about KVM/QEMU is if you do a test install you can copy the VM to bare metal. Something like:

convert the .qcow2 to a raw image:

qemu-img convert test.qcow2 -O raw disk.img

Then copy the .img to the target partition:

dd if=/path/to/disk.img of=/dev/sdX

I guess you'd need to sort out the boot loader as well.

I haven't done this but have seen it mentioned on Debian forums.

[Hedon James]

On 11/27/2024 at 7:46 AM, sunrat said:

A good thing about KVM/QEMU is if you do a test install you can copy the VM to bare metal. Something like:

convert the .qcow2 to a raw image:

qemu-img convert test.qcow2 -O raw disk.img

Then copy the .img to the target partition:

dd if=/path/to/disk.img of=/dev/sdX

I guess you'd need to sort out the boot loader as well.

I haven't done this but have seen it mentioned on Debian forums.

I had never considered this before, but those steps make sense.  I've converted *.vdi and *.vmdk to *.qcow2, and I was aware of the *.img and *.raw formats, but never gave it much thought because I was so focused on converting VBox to VMM native format. 

 

The boot loader comment catches my eye, because VMM uses "TianoCore" for MBR/BIOS and GPT/UEFI implementations; and the lack of a bootloader for the VM OS will boot into TianoCore "shell", with options to select for the shell; much like lack of a bootloader on bare metal will provide opportunity to boot to BIOS/UEFI and tinker with settings.  In theory, a VM built in VMM has a bootloader with corresponding EFI partition that ties to TianoCore.  Also in theory, Calamares installer provides for option of MBR vs UEFI installation.  Could it be as simple as installing an "installer" (looking at Calamares, or Anaconda, or Ubiquity, etc...) to handle the bootloader tie-in to bare metal installation?  Or, maybe install rEFInd to handle boot sequences?

 

Assuming that boot issues are resolvable, converting to *.img and using dd to make a live media is GENIUS!  I've always remixed & remastered in a VM, then created the ISO within the VM, then created the LiveMedia.  Converting the VM *.img would save 2 lengthy time-consuming steps, and would allow the process to be done on the NATIVE machine, rather than within the VM, with a disk size larger than needed to accommodate the ISO creation process.  Less steps=fewer variables=more efficient, IMO.

 

Got any links I can check out?  I'd definitely be interested in learning more about this concept!

[sunrat]

8 hours ago, Hedon James said:

Or, maybe install rEFInd to handle boot sequences?

 Yeah I reckon one could copy the image to HD/SSD then boot with REFind or some similar method, then do a grub-install to add it to ESP. If it's the only distro on the computer, obviously create an ESP before copying the image over.

 

There's a brief explanation here - https://askubuntu.com/questions/195139/how-to-convert-qcow2-virtual-disk-to-physical-machine-and-reversely

Doesn't really say much more than I already posted though.

[Hedon James]

6 minutes ago, sunrat said:

 Yeah I reckon one could copy the image to HD/SSD then boot with REFind or some similar method, then do a grub-install to add it to ESP. If it's the only distro on the computer, obviously create an ESP before copying the image over.

 

There's a brief explanation here - https://askubuntu.com/questions/195139/how-to-convert-qcow2-virtual-disk-to-physical-machine-and-reversely

Doesn't really say much more than I already posted though.

If you convert a qcow2 disk to img disk, the ESP partition will be included for TianoCore booting.  Could it be as simple as chroot into the newly installed/copied OS and install grub or rEFInd to overwrite the ESP on the newly installed OS?  Then boot into the new system?

[securitybreach]

16 hours ago, Hedon James said:

TianoCore booting

 

I had to look up that but what is the point besides complicating things further in the boot process?

[securitybreach]

Quote

TianoCore lacks the specialized drivers that initialize chipset functions, which are instead provided by coreboot, of which TianoCore is one of many payload options. The development of coreboot requires cooperation from chipset manufacturers to provide the specifications needed to develop initialization drivers.

 

https://en.wikipedia.org/wiki/UEFI#Criticism

[Hedon James]

23 minutes ago, securitybreach said:

 

I had to look up that but what is the point besides complicating things further in the boot process?

Not trying to complicate the boot process....trying to anticipate a potential problem, and potential solution for this exercise in intellectual curiousity.

 

I've converted VM disks before, and am familiar with that.  And I've created LiveMedia with "dd".  But it has never occurred to me to convert a VM disk from *qcow2 to *img, and then write that IMG to an ISO for LiveMedia.  And if I include Calamares on the VM disk/image/iso, it should be installable on new virtual disk or bare metal.

 

Sunrat referenced dealing with bootloader issues.  I KNOW VMM uses TianoCore for BIOS/UEFI implementation, so any VMM disk converted will include the ESP for the TianoCore boot.  What I don't know is if Calamares will install/copy the ESP from the LiveMedia, or create a new ESP based on the hardware probed by Calamares.  If Calamares probes and installs NEW ESP, everything is golden.  But if Calamares copies old ESP with TianoCore config, I'm thinking about how to overwrite & resolve that.  Speculating that a simple chroot into newly installed OS with LiveMedia and updating GRUB or installing rEFInd would overwrite the ESP.

 

But I don't know what I don't know.  If I have incorrect assumptions, or you have thoughts, I'd love to hear them.  I'm just MENTALLY trying to gather information and anticipate POTENTIAL issues and resolutions before I try a PHYSICAL exercise.  Share your thoughts?

[securitybreach]

2 minutes ago, Hedon James said:

Not trying to complicate the boot process....trying to anticipate a potential problem, and potential solution for this exercise in intellectual curiousity

 

I wasn't referring to you at all, I was referring to the project itself.

[Hedon James]

28 minutes ago, securitybreach said:

 

I wasn't referring to you at all, I was referring to the project itself.

Gotcha.  I just know that I see TianoCore during boot of VMM before an OS is installed.