modprobe


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

Fedora GNU/Linux : Disable USB Storage Devices

There is this machine that runs Fedora GNU/Linux, for which its owners asked us to block all USB Storage Devices without affecting other peripheral devices like keyboards and mice. The reason for that was to prevent unlawful data leakage that the users of that machine could do.

On Linux there is a kernel module named usb_storage that can be found at /lib/modules/$KERNEL_VERSION/kernel/drivers/usb/storage/usb-storage.ko.xz (to get the kernel version, execute uname -r;) which operates as the USB Mass Storage driver for Linux.

Apparently, we just needed to block the usb_storage module.  Initially, we tried to block the module by using the /etc/modprobe.d/blacklist.conf file but with no success. We failed to blacklist the module using the following commands (we were not sure which of the two names are correct, so we tried both, one at a time. It appears that both can be correct..):
echo -e "usb_storage\n" | sudo tee -a /etc/modprobe.d/blacklist.conf;
echo -e "usb-storage\n" | sudo tee -a /etc/modprobe.d/blacklist.conf;

After creating/updating the blacklist.conf file we restarted the machine as the module does not get loaded on boot automatically, it only gets loaded when needed. Unfortunately, as we mentioned before, these attempts led to no solution as we were still able to use USB storage devices even after creating the blacklist.conf file.
Since this method failed, we had to turn our heads towards a different solution, that due to its nature, it can be considered a hack.

Solution

What we did was to create a new configuration file in /etc/modprobe.d/ that would prevent usb_storage from being loaded by redirecting any requests to load the specific module to the /bin/true application.


echo "install usb_storage /bin/true" >> /etc/modprobe.d/disable-usb-storage.conf;
# Or the following (both names usb_storage and usb-storage seem to work)
# echo "install usb-storage /bin/true" >> /etc/modprobe.d/disable-usb-storage.conf;

Then, we had to make sure that the module was not already loaded. To see if the usb_storage module was already loaded we executed:


lsmod | grep -i usb_storage;

When lsmod | grep -i usb_storage; did not return any results, then it meant we were done! Since it was not in the list, it meant that the module was not loaded and so the next time someone tried to use a USB mass storage device they would not be able to load the module.

In cases were we got a line back (and thus the module was already loaded), then we needed to unload it manually or restart the machine. To avoid rebooting the machine we used modprobe to unload the usb_storage module.


modprobe -r usb_storage;

Some times, we would get the following error: modprobe: FATAL: Module usb_storage is in use.. This error meant that some other kernel module was using usb_storage and would not allow us to unload it. Using lsmod | grep -i usb_storage; we would get back a line like the following: usb_storage 73728 1 uas. The last column is a comma separated list of kernel modules that use usb_storage and we would need to unload them as well (replacing commas with space characters). Since we had only one dependency, our command became like the one below:


modprobe -r uas usb_storage;

And we were done!

To Re-enable USB mass storage devices (revert)

That is the easy part, to re-enable access to the USB mass storage devices, all we had to do was delete the configuration file:


rm /etc/modprobe.d/disable-usb-storage.conf;

Of course, to block them again, the we would have to follow the steps in the above solution.