Issues with making EasyOS run (in a virtual machine)

Well how about I draft out all the essential points, then you finish it off as a reply. ? It is your post.
I envisaged something brief and pointed… not a longwinded rewrite of the whole post.
There are lots of findings , other than the final solution. Noone is going to read through 120 replies to find them. We need to gather them.

Regards
Neville

But perhaps dealing with a virtual drive is a bit different…

Yes because a virtual drive is actually a file. It has a size limit set when it is created. A drive usually has some spare space.
That is apparently what @Akito 's resizefs deals with, but you were able to do it with dd

1 Like

One might ask… how is someone who has never installed raspbian (or easyos) supposed to know about this need to enlarge the image on disk?
Apparently even the developer of Easyos was not aware of the issue?
EasyOS documentation needs an overhaul.

@nevj
It did work and even booted, I was trying to do something with VB, but it did not work. I see no need in tying up a whole, or at least half a drive with a few MB install of EasyOS. Although I will install Puppy Linux, on my slower PC, using VirtualBox.

1 Like

@nevj
I can tell you in a few words why. EasOS is just an .img make, of another base system, with probably read and write permissions, you take the .img and flash it on any usb that is large enough, the catch is that EasyOS has to see the device as writable, and a VB .vdi does not please EasyOS. Now I can take the usb I have and either clone for Windows and dd for Linux to any system I wish, but why, just plug in the usb, enter bios, and boot the usb.
Might be valuable to have if I wanted to boot some other PC and wreck havoc.

1 Like

Yes, but there also has to be space for it to write to. That is the key bit we all missed… except Akito

1 Like

@nevj
Maybe, but I never used the resize command, maybe Balena/Etcher did at some point. I agree with you that the install instructions for EasyOS, is in need of updating.

2 Likes

Hi all, :wave:

now that I´ve got EasyOS running I´d like to add some afterthoughts. Perhaps they might be of some interest… :blush:

Running the OS the way I did was o.k. The OS started in the vm (qemu/kvm) but I noticed
I couldn´t make snaphots. :exclamation:
The respective entry in virt-manager was greyed out and I couldn´t do it from the command-line either.

E.g.
LIBVIRT_DEFAULT_URI=qemu:///system virsh snapshot-create-as vm1

failed as well..

Digging a bit deeper I found out that such a snapshot can´t be created when dealing with an img in raw format. :slightly_frowning_face:
And EasyOS was using that img format.

The solution was to convert the img to the qcow2 format:

sudo qemu-img convert -f raw -O qcow2 easy-4.3.4-amd64.img easy-4.3.4-amd64.qcow2

That produced a new img which I then chose to run the vm from. Could be easily done from within virt-manager.

Here´s the difference between the two files:

file easy*
easy-4.3.4-amd64.img:   DOS/MBR boot sector
easy-4.3.4-amd64.qcow2: QEMU QCOW2 Image (v3), 3012558848 bytes
 du -sh ./easy*
2,9G    ./easy-4.3.4-amd64.img
1,3G    ./easy-4.3.4-amd64.qcow2

First the qcow2 img was just over 800 MB in size but when running it in the vm the size began to grow. I guess that´s how it should be. :wink:

I ran df -h in both instances to see whether there´d be any difference. As it turns out both are exactly the same :wink: :

(left: qcow2; right: raw)

Running the qcow2 image did allow for snapshots and that´s certainly preferred. :smile:

Now to mounting a qcow2 image:

I did it the following way:

(took How to mount qcow2 disk image on Linux as a source)

  • qemu-utils has to be installed on the system

  • sudo modprobe nbd max_part=8 # loads the nbd kernel module. The max_part=N option specifies the maximum number of partitions we want to manage with nbd

  • sudo qemu-nbd --connect=/dev/nbd0 /home/rosika/Desktop/kgw_prov/easy-4.3.4-amd64.qcow2 # exports the specified disk image as a network block device (/dev/nbd0). As a network block device, you can use /dev/nbd0, /dev/nbd1, /dev/nbd2, etc. whichever is unused. As for the disk image, make sureto specify its full path.
    After this, existing disk partitions in the disk image will be mapped to /dev/nbd0p1, /dev/
    nbd0p2, /dev/nbd0p3, etc.

  • lsblk says:

nbd0      43:0    0   2,8G  0 disk 
├─nbd0p1  43:1    0     7M  0 part 
└─nbd0p2  43:2    0   2,8G  0 part /media/rosika/easy2
  • sudo fdisk /dev/nbd0 -l says:
Festplatte /dev/nbd0: 2,83 GiB, 3012558848 Bytes, 5883904 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xf83565fd

Gerät       Boot Anfang    Ende Sektoren Größe Kn Typ
/dev/nbd0p1 *      2048   16383    14336    7M ef EFI (FAT-12/16/32)
/dev/nbd0p2       16384 5883903  5867520  2,8G 83 Linux

So both partitions are there. :wink:

  • sudo mount /dev/nbd0p1 /mnt # Finally, choose any one partition (e.g., /dev/nbd0p1) and mount it to a local mount point (e.g., /mnt)

  • sudo umount /mnt # unmounting the partition

  • sudo qemu-nbd --disconnect /dev/nbd0 # disconnect the disk image

  • in addition I still had to do this: umount /media/rosika/easy2

So once again: I´ve learned something new. :smiley:

Many greetings from Rosika :slightly_smiling_face:

3 Likes

Hi Rosika,
Do you know why?
Snapshot or screenshot usually writes an image in your home directory.
Does your Easyos in VM from the .img file have a home directory?
Can you write anything else in that home dir?

You are fast becoming a qemu expert. I need to take lessons

Regards
Neville

1 Like

So an nbd device must be writeable… I guess that is why the article uses it, rather than a loop device. The network part of it is not needed for what you want.

I noticed that gnome-disk-image-mounter has an option to make it writeable. That is strange… it is essentially a loop mount, I think?

It would seem that a loop device can be made rw
https://manpages.ubuntu.com/manpages/impish/en/man4/loop-control.4.html
It might require some C programming to call ioctl(2) settings?

1 Like

Hi Neville, :wave:

Yes, I guess that would normally be the case. But as far as I know qemu does it “internally”, so the cqow2 file would be altered.

To be sure I tried to look it up and on https://www.reddit.com/r/linuxquestions/comments/e13wcn/where_does_qemukvm_store_vm_snapshots/ I found the confirmation:

jinglesassy

· 3 yr. ago

Same qcow2 file

Well, I don´t know the reason why the raw format won´t allow for snapshots. Sorry. I guess that´s up to qemu´s policy …
But qcow2 files are supported.

No. actually not. As the qcow2 file is the only one whcih experiences changes (by running the OS or by creating snapshots) I could transfer or copy it to anywhere I like and run it from there…

Right. That´s the way I see it too. Thanks for the clarification, Neville.

I looked it up:


gnome-disk-image-mounter easy-4.3.4-amd64.qcow2

lsblk
[...]
loop0    7:0    0   1,2G  1 loop

ll /dev/loop0
brw-rw---- 1 root disk 7, 0 Sep 20 15:08 /dev/loop0

So the loop device seems to be writable by the user, if I get it right :question:

Thanks for the links, Neville.
I´ll look them up.

Many greetings
Rosika :slightly_smiling_face:

Hi Rosika,

So it would be possible to used gnome-image-mounter to make the loop device, and then boot from that with qemu… right?
but
you would still have to resize the file with dd before mounting it?
That mighf be a third method

Well, I don´t know the reason why the raw format won´t allow for snapshots

There is no home directory for it to write the snapshot to?
You do mean a screenshot, dont you? not some system snapshot for backup? Or have I misread you?

Regards
Neville

1 Like

Hi Neville, :wave:

I guess not.
An answer to that question on virtual machine - How to configure Virt-Manager to save snapshots to another server? - Unix & Linux Stack Exchange
states:

The snapshots virt-manager takes are internal (created and managed inside the disk image), and aren’t saved to a separate image.

(bold by me)

Another answer (same source):

With KVM you have the choice of making internal and external snapshots. Until now, virt-manager only supports internal snapshots.

Ah, now I get it. Well, I´ve been using virt-manager for creating snapshots. Those are the internal ones then.
So actually the image (qcow2 file) itself is modified and the snapshot integrated therein.

Hmm, I tried that:

gnome-disk-image-mounter easy-4.3.4-amd64.qcow2

lsblk
[...]
loop0    7:0    0   1,2G  1 loop

ll /dev/loop0
brw-rw---- 1 root disk 7, 0 Sep 20 15:08 /dev/loop0

sudo kvm -hda /dev/loop0 -cpu host -m 1024 -boot d
qemu-system-x86_64: -hda /dev/loop0: The device is not writable: Permission denied

Doesn´t work though… not writable. :frowning_face:

Many greetings
Rosika :slightly_smiling_face:

So ls says it is writeable, but kvm says it is not writeable??
Did you resize the file?
You used gcow2… I thought you could maybe use img

I dont think we are on top of this yet

Neville

1 Like

Indeed the img file behaves differently: both partitions are seen by lsblk:

gnome-disk-image-mounter easy-4.3.4-amd64.img

lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0       7:0    0   2,8G  1 loop 
├─loop0p1 259:0    0     7M  1 part 
└─loop0p2 259:1    0   2,8G  1 part /media/rosika/easy2

 ll /dev/loop0*
brw-rw---- 1 root disk   7, 0 Sep 20 17:14 /dev/loop0
brw-rw---- 1 root disk 259, 0 Sep 20 17:14 /dev/loop0p1
brw-rw---- 1 root disk 259, 1 Sep 20 17:14 /dev/loop0p2

Still:

sudo kvm -hda /dev/loop0 -cpu host -m 1024 -boot d
qemu-system-x86_64: -hda /dev/loop0: The device is not writable: Permission denied

When running either the img file (raw format) or the qcow2 file with virt-manager the file is automatically resized as changes are accounted for.

When first running the qcow2 file after converting it from the raw format it was just a bit over 800 MB in size.
After running the OS a few times and making one snapshot it´s now 1.2 GB in size.

I seems so.
Perhaps the loop device isn´t meant to be written to as it is discarded in due course … :question:

For the sake of comparison I just powered up EaysOS (qcow2) with virt-manager.
At runtime lsblk isn´t showing any loop device at all:

lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    1  29,1G  0 disk /media/rosika/74C1-30C7
sdb      8:16   0 931,5G  0 disk 
├─sdb1   8:17   0  23,3G  0 part /
├─sdb2   8:18   0  35,6G  0 part /home
└─sdb3   8:19   0 195,3G  0 part /media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1
sdc      8:32   1  29,7G  0 disk 
└─sdc1   8:33   1  29,7G  0 part /media/rosika/28BC-DAFC
sdd      8:48   0 465,8G  0 disk 
├─sdd1   8:49   0  1000M  0 part 
├─sdd2   8:50   0   260M  0 part 
├─sdd3   8:51   0   500M  0 part 
├─sdd4   8:52   0   128M  0 part 
├─sdd5   8:53   0 439,1G  0 part 
├─sdd6   8:54   0   450M  0 part 
└─sdd7   8:55   0  24,4G  0 part 
sdf      8:80   1   7,4G  0 disk 
└─sdf1   8:81   1   7,4G  0 part /media/rosika/A492-CD29
sr0     11:0    1  1024M  0 rom

It seems an entirely fifferent mechanism is employed here. :thinking:
Of course I may also be wrong …

Many greetings
Rosika :slightly_smiling_face: