1

Referring to @goldilocks Reverse the expand root FS

I'm using the latest Rasbian Stretch and have sent an rsync backup to my NAS which is mounted via an NFS mount. Now I am attempting @goldilocks guide to create a new blank image file on the NAS to send the rsync backup into. There are 2 problems....

"dd if=/dev/zero of=test.img bs=4096 count=1000" creates a 4M file not 40M

Making the file 40M and continuing up to the losetup line where I hit an error that I cannot bypass. 

losetup -o 4194304 /dev/loop1 test.img"

Changing the file.img permissions to 777 doesn't help this error

losetup: /dev/loop1: failed to set up loop device: Permission denied

Is the because Rasbian Stretch is different, or is just me?

Ghanima
  • 15,855
  • 15
  • 61
  • 119
TimR
  • 19
  • 2
  • 1
    Thanks for catching that 4/40 MB thing (now corrected). "Changing the file.img permissions to 777 doesn't help this error" -> Did you try as root or via sudo? A different loop device (ls /dev should show half a dozen or so)? sudo losetup -D in case a prior attempt did something odd? – goldilocks Jan 13 '18 at 15:15
  • Yes, ls /dev shows loop0 to loop7 along with loop-control. But attempt to cleanup didn't help. Running " sudo losetup -o 4194304 /dev/loop1 test.img" completes without error... – TimR Jan 13 '18 at 15:33
  • @goldilocks Subsequent commands to mkfs.vfat and losetup -D also require a sudo to complete. mkdir works as listed, but mount needs sudo to work. The first mount completes successfully, but the second one complains "/test.img: overlapping loop device exists" – TimR Jan 13 '18 at 15:45
  • Yes -- near the beginning of the original post I wrote "Some of these commands need to be run root so I recommend you just su root." If you search downward for "overlapping loop" you will find a note about that and a link (not all versions of mount have this issue). The link is another long answer so you may again want to search downward for "overlapping loop". – goldilocks Jan 13 '18 at 16:46

1 Answers1

0

Changing the file.img permissions to 777 doesn't help this error

You do need read-write permission on the image file, but the error here is probably about the permissions on the device node in /dev; stat /dev/loop1 will likely show it as 660, uid root, gid disk.

You could change the permissions or ownership on that, but it would probably be better to use sudo, or if that doesn't work, su root and do it (if you don't have a root password set you'll have to sudo passwd root first).

Note the file nodes in /dev are virtual and are created by the kernel, so if you do modify anything the changes will not persist across boot.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Yes, sudo works fine and su root also works. Regarding the failure to "mount -o offset=14680064 -t ext4 test.img two" I cannot find anything wrong in your offsets. Looks good to me. Puzzled.....
    Device Boot Start End Sectors Size Id Type test.img1 8192 28671 20480 10M c W95 FAT32 (LBA) test.img2 28672 79999 51328 25.1M 83 Linux     – TimR Jan 13 '18 at 16:00
  • Some versions of mount (e.g., the one used by Debian/Raspbian) need you to also specify a size for a partition inside an image file if it does not use the whole file; see my comment on the question here or the bit about "overlapping loop" in the original Q&A. – goldilocks Jan 13 '18 at 16:49
  • So the only other to do it is " mount -o offset=14680064,sizelimit=26279936 -t ext4 test.img two" since we have 51328*512 for size. This still complains that overlapping loop device exists. Maybe I am not understanding your helpful pointers? – TimR Jan 13 '18 at 17:57
  • In this folder, along with the test.img file, we have 2 empty folders, one called one, and one called two. Neither one has any lost+found directory in it. – TimR Jan 13 '18 at 18:01
  • If it successfully mounted as ext4 (you can check by running mount | grep test.img; there should be something like test.img on /some/path/two type ext4) then it should be fine. Mkfs should have created that folder, it is used by filesystem repair tools like e2fsck to put bits of files found when resolving some corruption. So if in the end it isn't there create it, uid root gid root permissions 700. – goldilocks Jan 13 '18 at 18:37
  • /test1# mount | grep test.img /mnt/robinDisk1/downloads/test1/test.img on /mnt/robinDisk1/downloads/test1/one type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) – TimR Jan 13 '18 at 18:41
  • Don't I need a successful mount of two first? You can tell my linux skills are in great need. Thanks for your patience. – TimR Jan 13 '18 at 18:43
  • My goal here is to have an online pi that will be sitting here at home while I am halfway around the world for the 6 months. I need to have it stay backed up while I am gone so once a week when the NAS is up, the PI will back itself up to the NAS. Finally now I need to be able to restore the backup to a fresh SD card just in case it fubars.... – TimR Jan 13 '18 at 18:47
  • I meant the second (ext4) partition; the little first one is vfat. So it looks like it did not mount, which might explain why you did not find lost+found. If you use -v with mount, it is more verbose (although it should indicate failure no matter what). If mkfs.ext4 runs correctly, it takes maybe 30-60 seconds and reports stuff as it is working. All I can say is go through it again. It is the kind of thing that is tedious and frustrating until you get the in and out of it. – goldilocks Jan 13 '18 at 20:57