Linux failed to setup loop device

Не удается смонтировать файл ISO в качестве устройства петли: Ошибка: «не удалось настроить устройство петли»

Сначала убедитесь, что вы установили модуль ядра петлевого устройства. Итак, бегите:

Если вы не получите никакого вывода, это означает, что вы должны смонтировать модуль ядра устройства цикла. Так:

Повторно запустите следующее, чтобы убедиться, что модуль загружен. Вы должны получить некоторые результаты:

Теперь, чтобы смонтировать файл ISO в качестве устройства цикла, сделайте следующее:

Тем не менее, я думаю, что это также должно работать без -t iso9660 части.

Я подозреваю, что вы слепо выполняете некоторые инструкции о том, как монтировать образ Ubuntu ISO с помощью устройства loop.

Это создает каталог, которым cdrom владеет root, /media если он не существует, и предназначен для использования в качестве точки монтирования файловой системы;

Это изменяет текущий рабочий каталог вашего экземпляра терминала

на сокращение, которое расширяет путь вашего домашнего каталога;

Это попытается смонтировать все совпадающие файлы ubuntu-* (все файлы, начинающиеся с имени файла ubuntu- ) в вашем домашнем каталоге, используя устройство цикла и / в качестве точки монтирования. Просто не делай этого. Совсем бесполезно сопоставлять с подстановочным знаком, если вы пытаетесь смонтировать один ISO-образ, оставляя в стороне тот факт, что вы хотите, чтобы / точка монтирования продолжала удерживать корневой раздел. Смонтируйте ISO-образ, указав точное имя файла, и смонтируйте его в точке монтирования, которую вы только что создали ( /media/cdrom ). Для этого убедитесь, что ISO-образ, который вы хотите смонтировать, присутствует в вашем домашнем каталоге и замените его ubuntu-* на полное имя ISO-образа. Например, чтобы смонтировать официальный образ 64-битной версии Ubuntu Desktop 14.04.2, необходимо выполнить следующую команду:

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

mount . failed to setup loop device: Operation not permitted [SOLVED]

mount . failed to setup loop device: Operation not permitted [SOLVED]

Post by portlock » Tue Apr 14, 2020 2:38 am

I’ve scoured Google and other forums and had no luck.
I didn’t use to have this problem and I’m not sure what part of my system broke.
This syntax works fine when I boot into Linux Mint LiveCD. I’ve tried all kinds of other syntaxes and nothing works.
The image is clean, bootable, and mounts fine as read-only, and nothing is wrong with the mountpoint.

Thanks
(FYI, this is what I wanted my post to say instead of the other pending post, which contained incorrect info—the kernel had nothing to do with it; I was mistaken.)

Re: mount . failed to setup loop device: Operation not permitted

Post by hal8000 » Tue Apr 14, 2020 5:11 am

Re: mount . failed to setup loop device: Operation not permitted

Post by portlock » Tue Apr 14, 2020 10:53 pm

The journal reports nothing useful. With /temp:
Apr 14 19:47:52 Unknown sudo[13579]: user : TTY=pts/5 ; PWD=/home/portlock ; USER=root ; COMMAND=/bin/mount -o loop,rw image.img /temp

/temp:
Apr 14 19:52:01 Unknown sudo[13661]: user : TTY=pts/5 ; PWD=/data/sys/dumps ; USER=root ; COMMAND=/bin/mount -o loop,rw user : TTY=pts/5 ; PWD=/home/portlock ; USER=root ; COMMAND=/bin/mount -o loop,rw image.img /home/portlock/temp

Again, it will successfully mount read-write to /temp in LiveCD.

Re: mount . failed to setup loop device: Operation not permitted

Post by hal8000 » Wed Apr 15, 2020 8:41 am

/temp doesn’t work , I’m assuming you got the same «Opertaion not permitted» message.

Re: mount . failed to setup loop device: Operation not permitted

Post by portlock » Wed Apr 15, 2020 3:13 pm

It doesn’t like my loop device. Was something corrupted? Maybe a package wiped out by a system crash? I read about others out there appearing to ‘rebuild’ their loop device with various commands. Those posts were regarding this error message but for very different systems and problems.

Re: mount . failed to setup loop device: Operation not permitted

Post by portlock » Sat Apr 18, 2020 5:12 am

Источник

2.5.0, / . mount: can’t setup loop device: No such file or directory #1132

Comments

youling257 commented Nov 6, 2019

update to 2.5.0, / . mount: can’t setup loop device: No such file or directory
reinstall 2.4.1 can mount success, then update to 2.5.0, also can mount success.

The text was updated successfully, but these errors were encountered:

youling257 commented Nov 6, 2019

reboot Android just now, 2.5.0 mount failed, / . mount: can’t setup loop device: No such file or directory

ElXreno commented Nov 6, 2019

I have the same problem.

Manual mounting with the same parameters works fine.

ElXreno commented Nov 6, 2019

Just checked, it’s a busybox problem.

Mwyann commented Nov 6, 2019

@ElXreno you’re right, I’ve replaced the busybox binary in the /data folder with a backup of the previous busybox that was shipping with Linux Deploy, and it works again.

Uchiha-Peng commented Nov 8, 2019

Danct12 commented Nov 8, 2019

Please update meefik’s busybox.

shuaixr commented Nov 8, 2019

set path /system/bin/
then update ENV

tjchick commented Nov 9, 2019

I have this problem. the /dev/loop0 device is missing

If you do in terminal
su
mknod /dev/loop0 b 7 0

Then it should work after.

meefik — could you add this to the startup of the application?

meefik commented Nov 9, 2019

pbranly commented Nov 10, 2019

I have tried this v2.5.0-155 and the result is the same
The external Hardrives seem to be correctly mounted during the start process but they are not accessible from the Linux session
Please help
Regards
Philippe

ElXreno commented Nov 10, 2019

@pbranly try to fully reinstall application

pbranly commented Nov 10, 2019

Oups surely no !
Further tests:
In normal session external HDD is not accessible
In SU session it is !

beelink@localhost:/storage$
beelink@localhost:/storage$ ls
3668E0DE68E09DBD E2AE6A34AE6A0201
beelink@localhost:/storage$ cd 366*
-bash: cd: 3668E0DE68E09DBD: Permission non accordée
beelink@localhost:/storage$
beelink@localhost:/storage$ su
root@localhost:/storage# cd 366*
root@localhost:/storage/3668E0DE68E09DBD#

zixijian commented Nov 16, 2019

try turn off SElinux

pbranly commented Apr 14, 2020

@sayamsamal
I do not get any good solutions for that issue.
I had to make a new clean installation and the issue did not reappear
Regards from France
Take care
Philippe

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

mount: [image.img]: failed to setup loop device: Operation not permitted (SOLVED)

mount: [image.img]: failed to setup loop device: Operation not permitted (SOLVED)

Post by linx255 » Wed Mar 06, 2019 11:11 am

Mint 18 Mate 64
4.15.0-34-generic

Hello, for years I’ve been using ‘dd’ command to create .img files of partitions, and restoring them by mounting them and rsyncing them to the target partition.

I’ve never encountered any problems mounting my .img files until today when I noticed my newest .img file does not mount but my second oldest .img file does (yesterday I recall having no problem mounting as either ro or rw):

sudo mount -o loop,ro newest.img /temp/ produces the error:

mount: cannot mount /dev/loop0 read-only

sudo mount -o loop,rw newest.img /temp/ produces the error:

mount: /data/newest.img: failed to setup loop device: Operation not permitted

sudo mount newest.img /temp/ produces the error:

mount: /data/newest.img: failed to setup loop device: Operation not permitted

Now when I try mounting the 2nd newest file (and all older):

sudo mount -o loop,ro 2nd_newest.img /temp/ WORKS!

sudo mount -o loop,rw 2nd_newest.img /temp/ produces the error:

mount: /data/2nd_newest.img: failed to setup loop device: Operation not permitted

sudo mount 2nd_newest.img /temp/ produces the error:

mount: /data/2nd_newest.img: failed to setup loop device: Operation not permitted

The ‘dd’ command I’ve always used to create the .img files is:

sudo dd if=/dev/sda$partition of=/data/newest.img

The ‘mount’ commands I’ve always used to mount the .img file (for rsyncing to another mounted partition) is:

The ‘rsync’ command I’ve always used to restore the mounted .img files is:

sudo rsync -advAX —progress —delete /temp/ /sda$partition/

It seems somehow the .img file I’m creating is unmountable ( old ones work fine ). ‘e2fsck’ returned no errors on any partitions and loop devices appear to be all present and working. It just doesn’t like my new .img files.

Without the ability to create and restore partition images I’m having an IT nightmare and my whole system is at risk of destabilizing.
It makes no sense unless some kind of system update changed the way my image capturing works.

Clues, please? Thanks. I’ve been troubleshooting and researching these errors for hours and failed to dig up anything useful.

UPDATE: I just discovered this mount command works for my newest.img:

sudo mount -o ro,norecovery,loop /data/newest.img /temp

The first time I mounted it this way it would not unmount (was busy) and I had to use ‘umount -l’. Now it mounts and unmounts with the norecovery option and does not get ‘busy’.

However, this does not explain why the newest.img requires ‘norecovery’ and the older ones do not.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted

Post by rene » Wed Mar 06, 2019 12:43 pm

and even though that part isn’t, I believe this second part to be not directly related to the first.

As to the first part, consistency with a filesystem needing journal recovery:

That is, after mounting rw one time, ro is fine again (because the journal has been recovered).

However, I (very) vaguely recall some issue with loop devices at around Mint 18 times, which I see you use, and would as such advise an fsck on newest.img; this fixes the ro mount here:

That is, what happens after e2fsck -f newest.img ?

I will say by the way I’m puzzled as to why you not simply dd the images back into place if you dd’ed them from the device in the first place. I.e., why the mount and rsync stuff if you could also just sudo dd if=newest.img of=/dev/sd for the correct C and N?

Re: mount: [image.img]: failed to setup loop device: Operation not permitted

Post by linx255 » Wed Mar 06, 2019 3:28 pm

Oh my, I didn’t realize that such staple commands as mount changed so radically from 18 to 19. I haven’t had time to upgrade to 19. Last time I tried it totally screwed up my theme/colors and there was apparently no way to maintain the same appearance I had with 18, and it was really unusable. So 19 got put on the back burner, and I got busy working on other things. ( If there’s a method to maintaining the exact appearance through the upgrade I’d be interested to know! I think I posted about that. )

When I got time later today I will try to repair journals, or do fsck/e2fsck on newest.img. So echo foo | sudo tee tmp/foo will damage the journal of clean.img?

I’m deploying the .img files to different partitions so they contain the same data, for redundancy.

The problem with dd is it also grabs all the inodes and what ends up happening is the inodes on each partition deployed to are identical and control the same files, so it effectively breaks the isolation between the partitions, and creates a massive, confusing Siamese twin file system/ total wreck.

Rsync, on the other hand, creates new inodes every time any file is created/or at least uses the existing one which isn’t normally identical to any other.

Also, I haven’t verified it but logic dictates that dd grabs along deleted data in the partition and rsync only grabs non-deleted files. If someone can verify this let me know; I haven’t tested forensic software on it yet, but it occured to me that syncing the image back with rsync probably fails to capture the deleted data, making file recovery either impossible or impaired due to the deleted data potentially being overwritten, but that’s better than having an inode catastrophe ( I posted about this too )! Or you might want to make deleted data unrecoverable. I’m trying to figure out different ways to manage partition data. For now I’m alright with rsync because I have a fairly robust backup system so forensic recovery is not really needed, and dd is only useful for a partition for which there is no duplicate.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted

Post by rene » Thu Mar 07, 2019 5:37 am

Ah, no, I was just talking about the «UPDATE:» you added to your own message.

What I expect happened is simply that you forgot to cleanly unmount the source partition before grabbing «newest.img» from it; i.e., basically the same manner in which I simulated things. because, no, the only thing that «echo» did was write something to the filesystem. It’s creating the image (cp clean.img unclean.img, in the simulation) before cleanly unmounting when some data IS still in flight that creates a filesstem with a journal needing recovery.

Also, no, there is/was no fundamental change wrt. mount between 18 and 19; it’s just that I recall some issue/buglet with loop devices around that time. As mentioned, very vaguely recall and am not finding it again now, but I’d until the fsck was attempted still consider the also failing rw mount a separate issue.

The «identical inodes» thing doesn’t seem to make overly much sense to me (identical FS UUID does but you can change that after the fact) but I’ll assume there’s a reason. Certainly it IS indeed the case that the images of the source partition include deleted data and that simply dd’ing them back would as such have the destination partitions include it as well. Yes, certainly rsync doesn’t.

Anyways, I expect the issue will be solved after e2fsck -f newest.img and will then consist of the advise to not forget to unmount before grabbing an image.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted

Post by linx255 » Thu Mar 07, 2019 10:36 am

What I was trying to explain about dd is that if you restore an image to two partitions, not only with the UUIDs will be identical, but the inodes of every file in each partition will be identical which means if you change a file on one partition those changes will be reflected on the other because the inodes in each of the partitions actually points to the same place.

When I first started experimenting with dd for managing file systems I started experiencing this and got frustrated when the two partitions seemed fused even though I had set unique UUIDs and fstabs after writing the images. Someone on the forum identified the problem and sure enough when I switched to rsync, problem solved. Of course, if the partitions are on two physically separate drives then dd could be used without this problem.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted (SOLVED)

Post by rene » Thu Mar 07, 2019 10:46 am

Know what you were saying but that doesn’t in fact make sense: inodes are a per fs resource. Perhaps you on both systems had the for example same fs mounted on /home, or was accessing through inter-device symlinks, or.

Anyways; good to know the problem’s solved.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted (SOLVED)

Post by linx255 » Thu Mar 07, 2019 12:10 pm

I’m not sure I understand. Of course, two OS’ on different partitions will generate different inodes as new files are created, but as I understand it, when using dd, the inode numbers of existing files are copied and still point to the same location on the hard drive. Then the OS has no idea it was cloned from dd, shrugs its shoulders, and carries on thinking all its existing inodes are unique.

This is consistent with the effects I experienced. I would login to one OS, make changes, and then see those same changes by logging into the other OS. Or I could make a change to a file in the file system in /dev/sda5, mount /dev/sda6 and see the same change there. I made sure each partition was set to a different UUID and that fstab pointed to those UUIDs ( with one /home residing in /dev/sda5 and another in /dev/sda6 ) to make sure each partition was actually separate from the others, and this had no effect.

It seems like another senior forum member actually tipped me off to this phenomenon; I’d have to look back to confirm. It seems this happens because the neither the OS nor dd were really intended to manage identical OS’ on the same hard drive—probably an uncommon setup. If they were, then dd would have an option to regenerate inodes either when restoring an image.

If there is an expert (or if you are one) in this area I’d like to confirm my understanding.

And thank you for confirming the dd / rsync difference regarding deleted data persistence.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted (SOLVED)

Post by rene » Thu Mar 07, 2019 12:30 pm

No, this is not the case. What inodes hold (directly or indirectly) are the numbers of the actual datablocks for a file, but per-fs: block N from the filesystem on /dev/sda1 is completely independent from block N from the filesystem on /dev/sda2. If you clone a filesystem onto a different partition then changes to file «foo» in block 1234 on the original filesystem have no effect whatsoever on file «foo» in block 1234 on the cloned filesystem and vice versa.

You explicitly claim to have experienced otherwise but you’d have to provide me with a reproducible example for me have a chance of telling you what the issue in fact is/was; it’s not anything inherently to do with dd; duplicating inodes is fine; they’re per-fs. As said, one thing I can think of is that you were in fact from both systems mounting one and the same filesystem on e.g. /home in which case clearly changes by both are changes to said same fs but imagination otherwise fails me. If you were told this was to be expected, «because of inodes» or otherwise, you were told wrong.

Re: mount: [image.img]: failed to setup loop device: Operation not permitted (SOLVED)

Post by linx255 » Thu Mar 07, 2019 4:26 pm

Источник