ubuntu


How to mount a qcow2 disk image that does not contain an Ubuntu LVM installation

Mounting a qcow2 disk image on your host server can be accomplished with the help of this fast method. Thanks to this feature, it is possible to reset passwords, alter files, or recover data even while the virtual machine is not running. This specific method does not allow mounting disks with LVM as they are not properly recognized the volume group tools (e.g. vgdisplay).

Enable Network block device (NBD) module on the host

sudo modprobe nbd max_part=8;

Network block device, or NBD, is a protocol on Linux that the OS can use to forward a block device (usually a hard disk or partition) from one system to another. This can be accomplished by sending the block device over the network.
For instance, a hard disk drive attached to another computer may be accessed by a local machine that is part of the same network.

Connect the QCOW2 image as a network block device

sudo qemu-nbd --connect=/dev/nbd0 /var/lib/libvirt/images/miner.qcow2;
#Use QEMU Disk Network Block Device Utility

We used the above command to export the QEMU disk image (miner.qcow2) using the NBD protocol and connect it to the NBD device (/dev/nbd0).

Identify the available partitions.

Check if the device has a UUID of an LVM partition in the QCOW2 image

sudo lsblk -f /dev/nbd0;

The lsblk command will provide information about all available block devices or the ones you choose. To obtain information, the lsblk command reads the sysfs filesystem and the udev db. It then attempts to read LABELs, UUIDs, and filesystem types from the block device if the udev db is unavailable, or if lsblk was compiled without udev support. In this particular scenario, root rights are required. Sample output can be seen below:

NAME         FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
nbd0                                                                                          
├─nbd0p1                                                                                      
├─nbd0p2                                                                                      
└─nbd0p3     LVM2_member LVM2 001       xniXr3-gWWj-xS0J-8TaT-EtDt-vZtR-92Z5ms                
  └─ubuntu--vg-ubuntu--lv
             ext4        1.0            be0a2dba-ac27-4dfd-9f90-60ae9196d5e6

Identify the virtual machine partitions

fdisk /dev/nbd0 -l;

fdisk is a program that is driven by dialog to create and manipulate partition tables. It can read GPT, MBR, Sun, SGI, and BSD partition tables. If no devices are specified, the operating system will use the devices listed in /proc/partitions (provided that this file already exists). Devices are always displayed in the order that they are specified on the command line or in the order that they are listed by the kernel in /proc/partitions, whichever comes first.

Mount the partition of the virtual machine

After you identify the partition that you need to mount, use the mount command to perform the action to a mounting point of your choosing.

#In this example, we assume that we want to mount nbd0p1 to /mnt/miner that we created.
sudo mkdir /mnt/miner/;
sudo mount /dev/nbd0p1 /mnt/miner/;

Upon successful execution, all the files of that partition will be available through our mounting point. If you try to mount an LVM partition, you will get the following error:

sudo mount /dev/nbd0p3 /mnt/miner/
mount: /mnt/miner: unknown filesystem type 'LVM2_member'.

In this tutorial, we do not handle this problem using this method. See below how we handled it using the guestfish tool.

Clean Up

After you are done, unmount, disconnect, and remove the NBD module if you do not plan on using it further.

#Unmount the partition
umount /mnt/miner/;
#Disconnect the image from the NBD device
qemu-nbd --disconnect /dev/nbd0;
#Unload the NBD module
rmmod nbd;

How to mount a qcow2 disk image that contains an Ubuntu LVM installation

In one case, we had an issue where we needed to mount a disk image of a VM that contained an LVN installation. The above solution did not work, as we could not access the LVM partitions properly. The volume group tools did not recognize the partitions as they were network block devices. To handle this scenario, we used guestfish.

Examining and altering the filesystems of virtual machines is possible with the help of the shell and command-line tool known as Guestfish. It uses libguestfs and makes all of the features of the guestfs API available. So, we installed guestfish straight from the repositories as follows:

sudo apt-get install guestfish;

Then, we connected to the image that contained the LVM installation as follows:

sudo guestfish --rw -a /var/lib/libvirt/images/miner.qcow2;

After connecting to the image, we executed the following:

  • run
    With run, we initiated the library and attached the disk image
  • list-filesystems
    We listed the file systems found by libguestfs
  • mount
    After identifying the partition we needed to mount, we used this command to assign it to the root path /
  • ls
    This command works as expected, we were able to list the files in various directories, etc.
  • edit
    We used edit to modify the file we needed to process
  • exit
    We used exit to terminate this session

Below is a sample example of our execution.

Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.

Type: ‘help’ for help on commands
      ‘man’ to read the manual
      ‘quit’ to quit the shell

><fs> run
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
><fs>  list-filesystems
/dev/sda1: unknown
/dev/sda2: ext4
/dev/ubuntu-vg/ubuntu-lv: ext4
><fs> mount /dev/ubuntu-vg/ubuntu-lv /
><fs> ls /home
tux
bob
><fs> edit /etc/default/grub

An easy way to SSH into a Gnome Boxes OS

Recently, we set up an Ubuntu Server in a Gnome Boxes virtual machine. We wanted to perform an ssh connection into it to make administration easier. In the properties of the VM that are visible from the GUI, there was no option to edit the network cards and set up a virtual network between the host and the virtual machine.

To allow ourselves to perform the ssh connection, we decided to go with the option of reverse ssh tunneling. To do so, we needed to install and start the ssh server.

After that, we got the IP of the host machine.

Then, we used the terminal of the virtual machine to execute the following ssh command:

ssh -N -T -R 22222:localhost:22 host_machine_user@host_machine_ip;

That created a connection to the host machine and blocked the terminal as expected since it was an active application.

Finally, from the host, we executed the following to ssh into the virtual machine:

ssh -p 22222 virtual_machine_user@localhost;

The biggest disadvantage of this method is that you need to enable ssh on your host machine.

The biggest advantage is the ease with which anyone can set it up.

Notes on the ssh parameters:

-N Do not execute a remote command. This is useful for just forwarding ports.

-T Disable pseudo-terminal allocation.

-R remote_socket:host:hostport Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded to the local side.


Ubuntu Distribution Upgrade: Not enough free disk space

Recently, we tried to upgrade an Ubuntu 20.04 desktop to a 22.04. At some point in the update, we got the following error:

The upgrade has aborted. The upgrade needs a total of 10,6 G free space on disk '/'. Please free at least an additional 8201 M of disk space on '/'. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'. The upgrade has aborted. The upgrade needs a total of 430 M free space on disk '/boot'. Please free at least an additional 38,4 M of disk space on '/boot'. You can remove old kernels using 'sudo apt autoremove' and you could also set COMPRESS=xz in /etc/initramfs-tools/initramfs.conf to reduce the size of your initramfs.

First of all, we tried to use the command apt autoremove to clear up some space, which unfortunately was not enough.

sudo apt autoremove;

Then to clear up some space, we needed to find remnant memories of older versions of the Kernel. To do so, we used the following command. The following command finds the current version of the kernel and shows the user the remaining packages that do not reflect the active kernel.

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d;/^linux-\(headers\|image\)/!d';

Then we removed all the headers and the images that we did not need using the command apt-get purge.

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d;/^linux-\(headers\|image\)/!d'
linux-headers-5.13.0-52-generic
linux-headers-5.15.0-46-generic
linux-headers-generic-hwe-20.04
linux-image-5.15.0-46-generic
linux-image-generic-hwe-20.04

$ sudo apt-get -y purge linux-headers-5.13.0-52-generic linux-headers-5.15.0-46-generic linux-image-5.15.0-46-generic;

Doing so was enough to clear up the space that was needed for the upgrade to continue.


Error mounting filesystem

After installing the ewf-tools the right way on a GNU/Linux Ubuntu machine, we executed the following command to create the ewf1 mounting point for our .E01 image:

mkdir /mnt/ewf;
ewfmount ./DISK.E01 /mnt/ewf/;

After the operating system created the mounting point, we opened the ewf1 file that appeared in /mnt/ewf/ using the Gnome Disk Image Mounter. This action made a new entry in the Gnome Disks Utility, showing our new disk.

After clicking on the play button (labeled Mount selected partition) we got the following error:

We then tried to use the terminal to gain more control over the mounting parameters. To proceed with the following commands, we copied the Device value, which was /dev/loop54p3 in this case.

$ mkdir /mnt/loc;
$ sudo mount /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop54p3 read-only.
$ sudo mount -o ro /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop54p3 read-only.
$ sudo mount -o ro,loop /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop58 read-only.
$ sudo mount -o ro,loop -t ext4 /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop58 read-only.
$ sudo mount -o ro,norecovery,loop -t ext4 /dev/loop54p3 /mnt/loc;

The command that worked for us was the following:

sudo mount -o ro,norecovery,loop -t ext4 /dev/loop54p3 /mnt/loc;

The parameter that did the trick was norecovery. norecovery/noload instructs the system not to load the journal on mounting. Note that if the filesystem was not unmounted cleanly, skipping the journal replay will lead to the filesystem containing inconsistencies that can lead to any number of problems. This problem occurred because the machine did not shut down properly before it had its image cloned, so after we mount, we might not get the latest state of the disk.