Im having a bit of fun with unetbootin with linux mint 16 setup in it. However when I try run the default menu item I get an error that ends with this: can not mount /dev/loop0 (/cdrom/casper/filesystem.squashfs) on //filesystem.squashfs) any ideas?

I work a lot with imaged drives, meaning a do a dd-copy of the drive in question and then work on the image instead of the drive itself. For most work, I use kpartx to map the drive's partitions to a device under /dev/mapper/. What I'm wondering here is if there's a way to find which of the mapping belong to which image. Consider this: root@vyvyan:/tmp# kpartx -a -v Image1 add map loop1p1 (254:4): 0 10240 linear /dev/loop1 2048 add map loop1p2 (254:5): 0 10240 linear /dev/loop1 12288 add map loop1p3 (254:6): 0 52848 linear /dev/loop1 22528 root@vyvyan:/tmp# kpartx -a -v Image2 add map loop2p1 (254:7): 0 33508 linear /dev/loop2 2048 add map loop2p2 (254:8): 0 39820 linear /dev/loop2 35556 Now, let's say I forget which image went to which mapping. Is there a way to let kpartx - or the kernel, or anything else - tell me which image goes where? *EDIT* Also, if I accidentally rm the image-file while kpartx has added the mappings, how do you remove the mappings? kpartx wants the actual image to be present.

I'm trying to mount and access a floppy image file in the .ima format (raw dump to floppy, similar to .img ) on ArchLinux. This file is part of a set of 30. It is not bootable, but rather a continuation of a set. The purpose is not manipulation for the sake of installation or cloning. I'm interested in the documentation contained with other data on the disk. Image file information ---------------------- Here is some info about this image file: # file U19.IMA U19.IMA: PC formatted floppy with no filesystem # fdisk -lu U19.IMA Disk U19.IMA: 1.4 MiB, 1474560 bytes, 2880 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes (parted) print Error: /home/meh/Downloads/U19.IMA: unrecognised disk label Model: (file) Disk /home/meh/Downloads/U19.IMA: 1475kB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Mount fail ---------- Here's the generic error message: mount -o ro,loop U19.IMA /mnt/cd/ mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error I've tried many combinations trying to specify a type with -t i.e. ntfs, msdos, iso9660, vfat, and always getting that same error. I thought it's maybe some kind of ntfs file format but ntfs-3G doesn't do much better so no it's not: # ntfs-3g -o loop U19.IMA /mnt NTFS signature is missing. Failed to mount '/home/meh/Downloads/U19.IMA': Invalid argument The device '/home/meh/Downloads/U19.IMA' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? # ntfsclone -r -o file.img U19.IMA ntfsclone v2013.1.13 (libntfs-3g) ERROR: Input file is not an image! (invalid magic) Someone suggested maybe a Minix fs. While it is not clear if I can really mount such a filesystem with my current configuration I tried: mount -t minix -o loop U19.IMA /mnt/cd which gave the generic error but there was this at the bottom of the log: VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0. It seems this is not conclusive, as when you specify a specific type of filesystem you will have a specific type of error in the log. Also tried fuseiso : # fuseiso U19.IMA /mnt/cd init: wrong standard identifier in volume descriptor 0, skipping.. init: wrong standard identifier in volume descriptor 1, skipping.. init: wrong standard identifier in volume descriptor 2, skipping.. init: wrong standard identifier in volume descriptor 3, skipping.. init: wrong standard identifier in volume descriptor 4, skipping.. init: wrong standard identifier in volume descriptor 5, skipping.. init: wrong standard identifier in volume descriptor 6, skipping.. init: wrong standard identifier in volume descriptor 7, skipping.. init: wrong standard identifier in volume descriptor 8, skipping.. init: wrong standard identifier in volume descriptor 9, skipping.. init: wrong standard identifier in volume descriptor 10, skipping.. init: wrong standard identifier in volume descriptor 11, skipping.. init: wrong standard identifier in volume descriptor 12, skipping.. init: wrong standard identifier in volume descriptor 13, skipping.. init: wrong standard identifier in volume descriptor 14, skipping.. init: wrong standard identifier in volume descriptor 15, skipping.. init: wrong standard identifier in volume descriptor 16, skipping.. init: wrong standard identifier in volume descriptor 17, exiting.. Where I can see such things with dmesg: [ 5316.082629] FAT-fs (loop0): invalid media value (0xf6) [ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem Also, lsmod | grep loop gives loop 18511 0 There is no alternate superblock of any kind: # mkfs -n U19.IMA mke2fs 1.42.8 (20-Jun-2013) U19.IMA is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 184 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=1572864 1 block group 8192 blocks per group, 8192 fragments per group 184 inodes per group Contrary to many cases I read about, there seems to be no need to specify any offset here as there are no partition built in the image. In such cases, sometimes the dd command is used to transfer the content to a similar image using an offset value which allows mounting. This seems the same as specifying an offset to the mount command directly. But this should be easy, like in this other case where a simple losetup is used and then the loop device is mounted. I can link the .ima file with losetup but when I try to mount the loop device I end up with my initial error message. Data integrity -------------- Finally, safecopy --stage1 doesn't report any issue with the data and the output up to stage 3 remains the same and yields the same error: # safecopy U19.IMA test.img --stage1 Low level device calls enabled mode: 2 Reported hw blocksize: 4096 Reported low level blocksize: 4096 File size: 1474560 Blocksize: 4096 Fault skip blocksize: 147456 Resolution: 147456 Min read attempts: 1 Head moves on read error: 0 Badblocks output: stage1.badblocks Marker string: BaDbLoCk Starting block: 0 Source: U19.IMA Destination: test.img . ;-} 100% Done! Recovered bad blocks: 0 Unrecoverable bad blocks (bytes): 0 (0) Blocks (bytes) copied: 360 (1474560) Here's the top of the file and the content seems to be intact: dd if=U19.IMA | hexdump -C | head -n 10 00000000 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 |................| * 00004600 34 2e 30 2e 32 20 33 38 36 75 6e 69 78 20 46 6e |4.0.2 386unix Fn| 00004610 64 20 53 65 74 20 35 20 6f 66 20 31 30 0a 00 00 |d Set 5 of 10...| 00004620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ---------- "Forensics" ----------- > Since a raw image consists of a sector-by-sector binary copy of the > source medium, the actual format of the file contents will depend on > the file system of the disk from which the image was created (such as > a version of FAT).[...] Since IMG files hold no additional data beyond > the disk contents, these files can only be handled by programs that > can detect their file systems. Following suggestions, I proceeded to analyze some of the other image files in the set(30): fdisk -lu U14.IMA Disk U14.IMA: 1.4 MiB, 1474560 bytes, 2880 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 This doesn't look like a partition table. Probably you selected the wrong device. Device Boot Start End Blocks Id System U14.IMA1 3840 11519 3840 0 Empty U14.IMA2 2425393152 4850786447 1212696648 0 Empty U14.IMA3 ? 2425393296 4850786591 1212696648 90 Unknown U14.IMA4 ? 2425393296 4850786591 1212696648 90 Unknown Sorry but it does look like a partition table but it is unusual. It includes the *id 90* property : 90h MBR, EBR CHS, LBA x86, 68000, 8080/Z80 Hidden, Filesystem FreeDOS Free FDISK Hidden FAT16 (corresponds with 04h i.e. MS Fat16 DOS 3.0+ < 65536 sectors) So trying to mount the image I get: # mount -t auto U14.IMA /mnt/cd mount: unknown filesystem type 'sysv' <----- As someone hinted, you need to have something specific like '*System V and Coherent filesystem support*' compiled in the kernel in order to use something like mount -t sysv. The sysv string is not so suprising, since this is part of AT&T UNIX System V/386 Release 4 Version 2.1 install media - a port which was supported by Sun until 2006 - and these images ended up in the wild in 2007. Actually a text file bundled with the images indicates that they are required for installation because of the nature of the boot sector and the format in use. There is an indication that the material was originally in Teledisk (TD0) format . I want to stress here that this is not original material. In any case I can't actually calculate the offsets like explained in the question - either I don't end up with integers when dividing by 512, and even if I try it seems I can't find the proper offset - dd: cannot skip to specified offset, 0 writes etc. So at this point the answer is about forensics, and no longer about an image file. Quick historical image source OS emulation with qemu ---------------------------------------------- AT&T UNIX System V Release 4 Version 2.1 LABEL Version X of X AT&T UNIX SVR4.0 2.1 -------------------------------------------------- U01.IMA Maintanace Disk1 2.1 2 of 2 U02.IMA Remote Terminal 2.1 1 of 1 Package U03.IMA BSD Comp. Pkg. 2.1 1 of 2 U04.IMA BSD Comp. Pkg. 2.1 2 of 2 U05.IMA Networking Supp. 2.1 1 of 1 Util. Pkg. U06.IMA Xenix Comp. Pkg 2.1 1 of 1 U07.IMA FACE Pkg. 2.1 1 of 1 U08.IMA FMLI Pkg. 2.1 1 of 1 U09.IMA Editing Utils. 2.1 1 of 1 U10.IMA OA&M Basic & Ext. 2.1 1 of 3 U11.IMA OA&M Basic & Ext. 2.1 2 of 3 U12.IMA OA&M Basic & Ext. 2.1 3 of 3 U13.IMA Foundation Set 2.1 1 of 10 Base System Pkg. 2 User System U14.IMA Base 2.1a 1 of 10 U15.IMA Base 2.1 2 of 10 U16.IMA Base 2.1a 2 of 10 U17.IMA Base 2.1 3 of 10 U18.IMA Base 2.1 4 of 10 U19.IMA Base 2.1 5 of 10 U20.IMA Base 2.1 6 of 10 U21.IMA Base 2.1 7 of 10 U22.IMA Base 2.1 8 of 10 U23.IMA Base 2.1 10 of 10 U24.IMA Maintanance 1 2.1 1 of 2 U25.IMA Base 2.1 9 of 10 U26.IMA Printer Pkg 2.1 3 of 3 U27.IMA Printer Pkg 2.1 2 of 3 U28.IMA Printer Pkg 2.1 1 of 3 U29.IMA 16 to unlimited 2.1 1 of 1 User License U30.IMA 2 to 16 User 2.1 1 of 1 License As was suggested, I installed from a prior image in the set. It involves using qemu like explained here basically starting with image 14 (first losetup /dev/loop0 U14.IMA then a simple qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a), as U19 is not bootable. What is nice here is that you don't have to mount/umount images in the OS itself, you just use ctrl-alt-2 or 1 with qemu to access or leave the monitor and you use list blocks to see what is mounted and change floppy0 imagename in that interface to change the image file i.e. during install for instance. I had to supply U19.IMA (disk 5) during installation (for a textual log of the install, see this - a highlight is the reference to MS-DOS!), and I ended up with this i.e. a properly installed AT&T UNIX Sys V 386 OS, so this pretty much confirms U19.IMA is a working disk image: By default /dev/fd is mounted on /dev/fd and there is also floppy access through a block (/dev/dsk/f0) and raw (/dev/dsk/f0) device. Changing directory to the floppy just shows files numbered from 1 to 23 (this is just the structure of the character device I guess). You can also cat the raw and block devices and see the floppy data is there but that's as close as it gets. I've noticed that in that OS, you don't install stuff from floppies by launching some script from a directory on them like you do with decompressed binary files for instance - here you use pkgadd -d diskette1 (surely that last word is some alias, but I found a reference to the -d switch in the SCO stuff for pkgadd(1M) and generally it appears often in commercial Unix (Oracle, HP share pkgadd(1M) ). Issuing the command launches a routine where you supply floppies and you have no control, except saying "no" after the routine finds out what's in the drive. In the case of disks which begin an installation sequence (U03, U05 etc.), this will install then ask for the next floppy etc until the package install is complete. If you put a floppy that isn't the beginning of a set, it finds basically nothing but tells you maybe you have to use the installpkg command instead. Will I be installing a physical floppy drive to my rig to access the data in that image file?

I'm trying to build a virtual disk image in Docker. I'm able to create my empty file with dd and create the partitions with parted but once I try to make my filesystem it fails saying the device could not be found. In the Docker container I'm running as root and I've passed --privileged=true to docker run. This works outside of docker and works in Docker on my local machine. It's only failing on my build server (AWS elastic agent). Here is a section of the output showing that the block device exist before the call to make the filesystem. 28-Feb-2019 10:39:33 +./scripts/make.sh:105> ls -l /dev/loop2 /dev/loop2p1 /dev/loop2p2 28-Feb-2019 10:39:33 brwxrwxrwx 1 root disk 7, 2 Feb 28 15:39 /dev/loop2 28-Feb-2019 10:39:33 brwxrwxrwx 1 root disk 259, 8 Feb 28 15:39 /dev/loop2p1 28-Feb-2019 10:39:33 brwxrwxrwx 1 root disk 259, 9 Feb 28 15:39 /dev/loop2p2 28-Feb-2019 10:39:33 +./scripts/make.sh:108> mkfs.vfat -n boot /dev/loop2p1 28-Feb-2019 10:39:33 mkfs.fat 3.0.28 (2015-05-16) 28-Feb-2019 10:39:33 /dev/loop2p1: No such device or address And the section of the script: ## Create zero'd file dd if=/dev/zero of=disk.img bs=1M count=400 ## Find next available loop device local lodev=$(losetup -f) ## Have flat file look like a block device ls -l ${lodev}* losetup ${lodev} disk.img ## Create partition table and partition parted -s -a optimal ${lodev} mklabel msdos parted -s -a optimal -- ${lodev} unit compact mkpart primary "10" "20" parted -s -a optimal -- ${lodev} unit compact mkpart primary "21" "-1" parted -s ${lodev} set 1 boot on ls -l ${lodev}* ## Create filesystem mkfs.vfat -n boot ${lodev}p1 mkfs.ext3 -L rootfs ${lodev}p2 Any ideas why mkfs.fat thinks the block device does not exist when it looks like it does?

I created a loop device using losetup /dev/loop90 /tmp/disk1, where /tmp/disk1 is a 512M file I have created. Then the loop device was detached using losetup -d /dev/loop90. It was removed from the output of losetup -a, but the entry in /dev and /sys/devices/virtual/block is still present. Because this entry is present, whenever a udev scan is performed, all the removed devices are also listed. How can these loop devices be completely deleted and all the entries removed without a reboot?

I am trying to mount an image file which has been downloaded by coldsnap for a snapshot of AWS, but I am unable to mount it in Amazon Linux 2. I Tried multiple commands as mount -o loop disk.img /mnt/disk, losetup -f disk.img && mount /dev/loop0 /mnt/disk but it's not working:

-shellsession
[root@ip-172-31-29-177 ec2-user]# mount -t ext4 /dev/loop0 /tmp/disk/

mount: /tmp/disk: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

Can anyone please help me on this error?

I am trying to make it possible to make and mount loop devices from within a container. This happens to work on my own development system, but is failing to work on our build server where it must be done for an automated build. I am ensuring that I'm starting the container as privileged. My container start line: docker run --privileged -it --rm :latest /bin/bash. From within the container I try the following steps [from the losetup man page](https://man7.org/linux/man-pages/man8/losetup.8.html) :

# dd if=/dev/zero of=/var/tmp/file.img bs=1024k count=4
...
# losetup --show --find /var/tmp/file.img
...

This should provide me the next unused loop device and have associated it to /dev/loop*n*. However, instead I'm presented with the following (and showing that the loop module is loaded and /dev/loop-control is present):

[root@64a3a6900e0d /]# losetup --show --find /var/tmp/file.img
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or modprobe loop.)
[root@64a3a6900e0d /]# ls /dev/loop*
/dev/loop-control
[root@64a3a6900e0d /]# lsmod | grep loop
loop                   28072  0

On my own dev box, this works. I loaded loop and started the container as privileged and was able to make loop devices. What should I check for now?

Given the annoying feature of snap's loop devices, my iostat output in an Ubuntu 18.04.02 is kind of like this Is there a way to filter out loop devices other than | grep -v loop ? $ iostat -xm Linux 4.15.0-47-generic (pkara-pc01) 04/22/2019 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 19.85 0.03 5.64 2.18 0.00 72.30 Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util loop0 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 7.00 0.00 0.00 2.88 0.00 0.50 0.00 loop1 0.06 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.25 0.00 0.00 1.80 0.00 0.09 0.00 loop2 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 7.47 0.00 0.00 6.57 0.00 1.06 0.00 loop3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.40 0.00 0.00 2.50 0.00 0.00 0.00 loop4 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 8.54 0.00 0.00 2.44 0.00 1.54 0.00 loop5 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10.29 0.00 0.00 2.86 0.00 0.76 0.00 loop6 0.05 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.55 0.00 0.00 1.89 0.00 0.17 0.00 loop7 0.06 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.39 0.00 0.00 1.75 0.00 0.24 0.00 sda 0.07 0.00 0.00 0.00 0.00 0.00 5.32 9.09 9.29 41.60 0.00 12.47 3.20 9.51 0.07 sdb 23.40 103.81 0.40 38.12 8.47 10.16 26.59 8.91 8.48 6.17 0.84 17.49 376.07 0.94 11.93 dm-0 31.96 113.83 0.40 38.08 0.00 0.00 0.00 0.00 12.17 10.89 1.63 12.74 342.57 0.82 12.00 dm-1 31.91 113.30 0.40 38.08 0.00 0.00 0.00 0.00 12.19 10.95 1.63 12.74 344.17 0.83 12.04 dm-2 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.51 0.00 0.00 19.90 0.00 0.41 0.00 dm-3 0.05 0.00 0.00 0.00 0.00 0.00 0.00 0.00 9.82 58.91 0.00 10.21 2.91 10.02 0.05 dm-4 0.03 0.00 0.00 0.00 0.00 0.00 0.00 0.00 14.23 64.80 0.00 14.69 3.20 14.35 0.05 loop8 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10.54 0.00 0.00 9.13 0.00 2.67 0.01 loop9 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11.83 0.00 0.00 2.66 0.00 1.79 0.00 loop10 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 28.96 0.00 0.00 20.96 0.00 3.20 0.00 loop11 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 31.20 0.00 0.00 20.80 0.00 4.80 0.00 loop12 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 18.56 0.00 0.00 9.28 0.00 1.56 0.00 loop13 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11.77 0.00 0.00 9.36 0.00 2.12 0.00 loop14 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 13.65 0.00 0.00 9.76 0.00 0.71 0.00 loop15 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 30.40 0.00 0.00 20.96 0.00 4.08 0.00 loop16 0.04 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.85 0.00 0.00 5.22 0.00 0.49 0.00 loop17 0.03 0.00 0.00 0.00 0.00 0.00 0.00 0.00 5.23 0.00 0.00 2.48 0.00 1.00 0.00 loop18 0.03 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.66 0.00 0.00 2.50 0.00 0.70 0.00 loop19 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 14.86 0.00 0.00 6.27 0.00 3.29 0.00 loop20 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12.48 0.00 0.00 9.15 0.00 1.65 0.00 loop21 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 8.66 0.00 0.00 9.83 0.00 1.29 0.00 loop22 0.04 0.00 0.00 0.00 0.00 0.00 0.00 0.00 5.10 0.00 0.00 5.09 0.00 0.70 0.00 loop23 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 16.32 0.00 0.00 3.05 0.00 1.16 0.00 loop24 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 20.60 0.00 0.00 2.50 0.00 4.20 0.00 loop25 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 16.30 0.00 0.00 2.44 0.00 2.37 0.00 loop26 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.60 0.00 0.00 0.00

So my setup is like this. $ truncate -s 1T volume $ losetup -f --show volume /dev/loop0 $ mkfs.ext4 /dev/loop0 $ ls -sh volume 1.1G volume $ mount /dev/loop0 /mnt/loop Now I have a 1.1TB volume, as expected. The overhead of ext4 expanded the sparse file to 1.1G, but that's fine. Now to add a file. $ dd if=/dev/urandom of=/mnt/loop/file bs=1M count=10240 $ ls -sh volume 12G volume Cool, now I don't want the file. $ rm /mnt/loop/file $ ls -sh volume 12G volume The free space is still taking up space, as expected, and $ fallocate -d volume frees up 1gb. My question is, how can I zero out the free space here without expanding the volume to the full size? $ dd if=/dev/zero will expand it to full size, and with conv=sparse makes it create a useless sparse file inside the volume. TL;DR: Is there a way to make losetup ignore writes of null blocks to null sectors, while allowing everything else?

In Ubuntu, I have mounted a raw disk .img file as a loop device that contains a LUKS encrypted LVM with an Ubuntu install on it. It is mounted like so: (output is from lsblk -o NAME,PKNAME,KNAME,FSTYPE,SIZE /dev/loop0

`
NAME                      PKNAME KNAME FSTYPE        SIZE
loop0                            loop0               240G
├─loop0p1                 loop0  dm-11 ext4          487M
├─loop0p2                 loop0  dm-12                 1K
└─loop0p5                 loop0  dm-13 crypto_LUKS 239.5G
  └─cloneluks             dm-13  dm-14 LVM2_member 239.5G
    ├─ubuntuclone-lv_swap dm-14  dm-15                 8G
    └─ubuntuclone-lv_root dm-14  dm-16 ext4        231.5G

` Is there any command that I can use in a script to return the root "block device" (I'm not sure if that's the correct term), when I give the mounted LV name? I was hoping that lsblk -no pkname /dev/ubuntuclone/lv_root would work, but it outputs nothing - using kname gives me dm-16. I want to get to loop0. I also saw [this answer](https://unix.stackexchange.com/a/308724/52247) which implied I could use "$(basename "$(readlink -f /dev/VG/LV)")", but I couldn't work out how to use it:

`
 dev=/dev/ubuntuclone/lv_root ; echo "$(basename "$(readlink -f $dev)")"

` outputs dm-16. I can't work out how to get "past" the crypto_LUKS container. This is what I'm looking for: for input: /dev/ubuntuclone/lv_root or ubuntuclone-lv_root I would like to get output: /dev/loop0 Thanks. edit: I think using lsblk --json | jq might be exactly what I want, but I'm having a lot of trouble working out the correct incantations for jq...

There's a number of posts about losetup -d /dev/loop0 not removing a lookback device, even though it returned a successful return code. I believe the root cause of those posts is that the block device has the autoclear flag set, so losetup only calls LOOP_CLR_FD but not LOOP_CTL_REMOVE. Some other process must still be holding a file descriptor, so the loop device is not detached nor removed. This is confirmed via strace:

$ sudo losetup -J -l  | jq '.'     
{
  "loopdevices": [
    {
      "name": "/dev/loop0",
      "sizelimit": 0,
      "offset": 0,
      "autoclear": true,
      "ro": false,
      "back-file": "/example/backing_file",
      "dio": false,
      "log-sec": 512
    }
  ]
}


$ sudo strace -ff losetup -d /dev/loop0
...
newfstatat(AT_FDCWD, "/dev/loop-control", {st_mode=S_IFCHR|0660, st_rdev=makedev(0xa, 0xed), ...}, 0) = 0
openat(AT_FDCWD, "/dev/loop0", O_RDONLY|O_CLOEXEC) = 3
ioctl(3, LOOP_CLR_FD)                   = 0
close(3)                                = 0
...

The common answer is to (a) look for all files open on any filesystems mounted from the loop device, and then (b) unmount the loop device. Typically lsof and /proc/**/fd are recommended. My problem is that I am running into this issue for block devices that were never mounted in the first place. I cannot, for the life of me, find which process is holding a file descriptor to this loop device and therefore cannot get it to close. A quick test C program shows that I can remove the auto-clear flag from the block device:

$ sudo strace -ff --verbose=ioctl /tmp/remove-autoclear
...
openat(AT_FDCWD, "/dev/loop0", O_RDONLY|O_CLOEXEC) = 3
ioctl(3, LOOP_CLR_FD)                   = 0
close(3)                                = 0

write(1, "INFO: Result of sending LOOP_CLR"..., 57) = 57
INFO: Result of sending LOOP_CLR_FD to /dev/loop0 was: 0

openat(AT_FDCWD, "/dev/loop-control", O_RDONLY|O_CLOEXEC) = 3
ioctl(3, LOOP_CTL_REMOVE, 0)            = -1 EBUSY (Device or resource busy)
write(2, "ERROR(16): Sending LOOP_CTL_REMO"..., 94) = 94
ERROR(16): Sending LOOP_CTL_REMOVE to /dev/loop-control for device 0: Device or resource busy

openat(AT_FDCWD, "/dev/loop0", O_RDONLY|O_CLOEXEC) = 4
ioctl(4, LOOP_GET_STATUS, {lo_number=0, lo_offset=0, lo_flags=LO_FLAGS_AUTOCLEAR, lo_name="/example/backing_file", ...}) = 0
write(1, "INFO: Autoclear bit for /dev/loo"..., 40) = 40
INFO: Autoclear bit for /dev/loop0 is 1

ioctl(4, LOOP_SET_STATUS, {lo_number=0, lo_offset=0, lo_flags=0, lo_name="/example/backing_file", ...}) = 0
ioctl(4, LOOP_GET_STATUS, {lo_number=0, lo_offset=0, lo_flags=0, lo_name="/example/backing_file", ...}) = 0
write(1, "INFO: Successfully removed autoc"..., 56) = 56
INFO: Successfully removed autoclear bit for /dev/loop0
close(4)                                = 0

ioctl(3, LOOP_CTL_REMOVE, 0)            = -1 EBUSY (Device or resource busy)
write(2, "ERROR(16): Sending LOOP_CTL_REMO"..., 94) = 94
ERROR(16): Sending LOOP_CTL_REMOVE to /dev/loop-control for device 0: Device or resource busy

exit_group(16)                          = ?
+++ exited with 16 +++







INFO: Result of sending LOOP_CLR_FD to /dev/loop0 was: 0
ERROR(16): Sending LOOP_CTL_REMOVE to /dev/loop-control for device 0: Device or resource busy
INFO: Autoclear bit for /dev/loop0 is 1
INFO: Successfully removed autoclear bit for /dev/loop0
ERROR(16): Sending LOOP_CTL_REMOVE to /dev/loop-control for device 0: Device or resource busy

$ sudo cat /sys/dev/block/7:0/loop/autoclear
0

But interestingly that doesn't make losetup -d /dev/loop0 fail with a hard error. This appears to be because LOOP_CLR_FD sets the auto-clear flag again. This is not relevant to finding the process holding the open file descriptor, I just noted it because it's "spooky action at a distance" and it explains why losetup never attempts to call LOOP_CTL_REMOVE. Any advice for how to go about finding the process holding a file descriptor to /dev/loop0 so that I can properly clean it without rebooting?

$ sudo ls -l /proc/**/fd | grep loop0       
$ sudo ls -l /proc/**/fd | grep backing_file
$ sudo lsof | grep loop0
$ sudo lsof | grep backing_file
$ sudo mount | grep loop

I ran the fdisk command and found the output below:

Disk /dev/loop0: 4 KiB, 4096 bytes, 8 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 258.04 MiB, 270569472 bytes, 528456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 73.89 MiB, 77479936 bytes, 151328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop3: 11.13 MiB, 11673600 bytes, 22800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop4: 516.01 MiB, 541073408 bytes, 1056784 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop5: 91.69 MiB, 96141312 bytes, 187776 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop6: 10.77 MiB, 11292672 bytes, 22056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop7: 44.44 MiB, 46596096 bytes, 91008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 30 GiB, 32212254720 bytes, 62914560 sectors
Disk model: VBOX HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C6D88ED7-FF16-4621-9FE8-D90940408DC6

Device     Start      End  Sectors Size Type
/dev/sda1   2048     4095     2048   1M BIOS boot
/dev/sda2   4096 62912511 62908416  30G Linux filesystem


Disk /dev/loop8: 568 KiB, 581632 bytes, 1136 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

How do I create a partition here?

I have created a loop device and added it to /etc/fstab I got its UUID from the output of the blkid command (it does print a UUID for the particular device after running mkfs.ext4 /path/to/loop) However __despite__ the fact that after editing /etc/fstab the command mount -a was successful, the system after the reboot halted. Insted the following entry in /etc/fstab seems to do the job: /path/to/loop /mountpoint ext4 loop 0 0 Why replacing /path/to/loop with UUID breaks things?

Since the kernel started supporting it, losetup was modified to enable direct IO by default. This can avoid having redundant page cache and also has performance advantages. http://man7.org/linux/man-pages/man8/losetup.8.html > --direct-io[=on|off] > Enable or disable direct I/O for the backing file. The optional argument can be either on or off. If the argument is omitted, it defaults to on. I noticed, when the kernel added this feature, [one commit mentions adding a feature specifically for mount -oloop](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab1cb278bc7027663adbfb0b81404f8398437e11) . Has mount -oloop also been modified so that it defaults to enabling direct IO (if the kernel is new enough)? I can't find it mentioned in the documentation. http://man7.org/linux/man-pages/man8/mount.8.html

I’m trying to include the beginning of a disk block device (the GPT area) read-only in a device-mapper linear mapping. This block device also contains my root filesystem, as such the partition housing it would be in use concurrently with the mapping’s existence. This is so I can pass through parts (but not all of) the same disk to Windows 10 running under QEMU, for use in there. I don’t intend to ever have any sections of the disk read-write in parallel across kernels, but Windows’ partition as well as the ESP (not mounted in Linux) would be. To visualize (partition numbers given): So, the beginning of the disk as well as the partitions one and three I want passed through, maybe I’ll need the end of the disk as well. Write access should only be allowed to the partitions, not to the outer disk parts. I’ve learnt about device-mapper some years ago on another occassion and revisited its docs. Encouraged, I’ve gone on my merry way and constructed the mapping, starting from the beginning, whereby I’ve eventually hit the current roadblock: When attempting to create the mapper device, dmsetup passed on an EBUSY error. I suspect this to have happened because one of the disk block device’s sub-devices, the partition block device with my Linux installation, currently being in use. For troubleshooting purposes, I’ve recreated the situation on a RAM disk (Does brd count as a Linux Arcanum by now?), which (from what I recall) made operations fail in the same manner in which they had failed on the true disk:

#!/bin/sh #This will obviously need root, or maybe CAPs.
[ -b /dev/ram0 ] && exit 1
   #In this script, I rely on brd not being in use and /dev/ram0 being created.
modprobe brd rd_nr=1 rd_size=261120 max_part=2 && [ -b /dev/ram0 ] || exit 2
sgdisk -a=8 -n=0:0:+100M -t=0:ef00 -n=0 -t=0:8304 /dev/ram0
#There’s no filesystem necessary on p1 for demonstration purposes.
mkfs.ext4 -i 6144 -O ext_attr,flex_bg,inline_data,metadata_csum,sparse_super2 /dev/ram0p2
   #Just some example filesystem, taken from my shell history grab-bag.
mkdir /tmp/ExampleMountpoint || exit 3
mount /dev/ram0p2 /tmp/ExampleMountpoint || exit 4
dmsetup create --readonly Example1 --table '0 33 linear /dev/ram0 0' #Output:
#device-mapper: reload ioctl on Example1 (253:0) failed: Device or resource busy
#Command failed.
   #The exit code is 1, but the error message matches EBUSY.
   #To no surprise, adding -f doesn’t help.
umount /tmp/ExampleMountpoint
dmsetup create --readonly Example2 --table '0 33 linear /dev/ram0 0'
   #This one works, but I need it to work with the partition mounted.
ls -l /dev/mapper/Example2
dmsetup remove Example2
#rm /tmp/ExampleMountpoint

On another StackExchange question I’ve found when I started out—I’ve searched for it twenty days ago when I’ve asked on some Linux forum about this (in vain), then I’ve searched for it today again, I really haven’t been able to dig it up a second time—there was an answer that revealed that I could get around the EBUSY status by employing a loop device as an intermediary before the real disk device:

mount /dev/ram0p2 /tmp/ExampleMountpoint #Remount.
LoopDev=$(losetup --show -f /dev/ram0)
dmsetup create --readonly Example2 --table '0 68 linear /dev/loop0 0'
   #Side note: Less than 68s makes sgdisk err out instead of printing the table.
   #This might be a bug, it should, by my reckoning, go down do 1+32+32+1 or even just 33s.
sgdisk -Pp "$LoopDev" #This should print some warnings, then the partition table created above.
losetup -d "$LoopDev"
umount /tmp/ExampleMountpoint
rm /tmp/ExampleMountpoint

So, when redirecting the disk block device through a loop device, dmsetup will comply instead of erring out. Caring much about my data (though I do have pulled an image onto a separate disk) I now wonder, whether this is actually safe to do and give the expected results in the greater scheme of things. (Among them, preventing corruption of partition 4 and the GPI, as well as allowing write access to the partitions 1 and 3 through the VM.) Are there any, I don’t know, additional I/O alignment gotchas to watch out for?

I am trying to add user-data files to images to run cloud-init on boot up. After adding the user-data file I hash the new image to check for changes. I am currently running into an issue where the file has a different hash every time. I'm not sure how that can be. Here are the commands I'm running...

# I have a user-data file and ubuntu.img file
img_name="ubuntu-1.img"

sudo cp ubuntu.img "${img_name}"
sudo losetup --partscan /dev/loop0 "${img_name}"
sudo mount /dev/loop0p1 /mnt/boot
sudo cp user-data /mnt/boot
sudo umount /mnt/boot
sudo losetup --detach /dev/loop0

img_name="ubuntu-2.img"
# repeat above setups using ubuntu-2.img

Running cmp ubuntu-1.img ubuntu-2.img reports a difference and I'm not sure why. Does anyone have any ideas?

I was thinking about proper *swap* solutions for a Linux system, and a very important question arised regarding all of them. As known and confirmed by my experience, a swap device *will* eventually be accessed under an extreme memory pressure situation. In such cases, an OOM kill is hypothetically near, but actually, since overcommit_memory=2 and enough swap space is still *available* in system — the OOM path is unreachable. What happens instead - is that kernel thinks it can swap memory out when needed, but "when needed" is too late. Swap I/O gets submitted to the blockdev driver when the memory pools are already absolutely exhausted. Let the block driver attempt any allocation which is more than some absolute minimum, and the system will be dead locked on memory. Unfortunately, it doesn't even get detected, and the System deadlocked on memory panic path is never taken. Instead the system freezes forever. I attempted many experiments to try to track the problem down. I have put code to print stacktrace where block I/O is happening, to find which alloc-family functions are in the path for popular devices (dm-*, loop+nfs, and other configurations), and how much they allocate. Yet it didn't help me. I experience the issues **most often on the "loop dev+ some FS" setups**, but eventually I have also hit it with dm-vdo (which is a deduplication and compression device), and few else, when using them for swap. I thought that the problem could be solved by increasing swappines and min_free_kbytes values in vm.\* sysctls, but I still hit the described problems. I had an idea of replacing all the alloc-like calls with on-stack allocations in the needed I/O path code (since I have 128kb kernel stacks), but that seemed too unclean solution (think, resolving conflicts on pulls from upstream), and not applicable everywhere. My question is: which of these device drivers rely on (heavy?) dynamic memory allocations in the I/O path? **Which are known to work fine in the Swap role? What considerations should be in mind to set up a reliable swap device? Can these devices be stacked on top of each other as much as needed?** - dm-crypt - dm-verity - dm-linear - loop (--direct-io) + ext4/fat32/? - loop + nfs/fuse - loop (--direct-io) + btrfs/zfs/bcachefs/? You can mention personal experience, of course.

This used to not be a problem, but now it is. I haven't changed anything significant so probably an update broke it. When I run VeraCrypt it complains that it couldn't set up loop device and suggests running modprobe fuse. Running it doesn't work. However, running modprobe fuse **and** modprobe loop fixes it, until the next restart. Shouldn't these modules be loaded automatically at boot? Why not? How do I make them?

how to check how many loop-devices in a linux system are possible to use? i need this in a script, are not more than X possible, than end the script with some message...

Is there a way to create a block device that is backed by a file that grows in size as the block device is written to? I'm looking to use device mapper snapshots (ie: dmsetup create command that specifies snapshot as the type of item to create) and according to the documentation the snapshot needs to be stored on a block device. One way to create this block device is by using losetup to turn a file into a block device. However, that requires as fixed size file. I'm trying to figure out if there is any way to not need a fixed size file but instead have the file that backs the block device that backs the snapshot grow as the snapshot grows.