Puppy initrd init Script: Why umounting /dev does not break the aufs stack?

[miltonx]

In Fossapup64 initrd's init script, the sfs files (eg. adrv_fossapup64_9.5.sfs) is mounted like this:

Code: Select all

  losetup -r $ONE_LOOP $ONE_FN
...
 mount -r -t squashfs -o noatime $ONE_LOOP $SFS_MP > /dev/console 2>&1

I think this means the sfs is first mapped to a loop device (eg. /dev/loop5), then the loop is mounted to a directory (eg. /pup_a), which by further mounting is added to the aufs stack.

But near the end of this script, right before switch_root to /pup_new, these folders are unmounted:

Code: Select all

umount /sys
umount /dev
umount /proc

My question is, when /dev is unmounted, why does it not break the aufs stack? Doesn't the sfs file (eg. adrv_fossapup64_9.5.sfs) still need to stay connected to /dev/loopx?

[fredx181]

My question is, when /dev is unmounted, why does it not break the aufs stack? Doesn't the sfs file (eg. adrv_fossapup64_9.5.sfs) still need to stay connected to /dev/loopx?

Not that I can explain in theory (someone else can probably reply better), but apparently a loop mount in the aufs stack stays as it is, unless you unload it from the aufs stack.
Similar thing: I once loaded an SFS on the fly but then I accidentally deleted that SFS file and to my surprise nothing strange or bad happened, the SFS was still part of the aufs stack and worked OK as before.
Btw, note that umount /dev is unmounting the /dev in the init system (the "start motor"), different thing is /dev in the system once booted to the Desktop.

[wiak]

In Fossapup64 initrd's init script, the sfs files (eg. adrv_fossapup64_9.5.sfs) is mounted like this:

Code: Select all

  losetup -r $ONE_LOOP $ONE_FN
...
 mount -r -t squashfs -o noatime $ONE_LOOP $SFS_MP > /dev/console 2>&1

I think this means the sfs is first mapped to a loop device (eg. /dev/loop5), then the loop is mounted to a directory (eg. /pup_a), which by further mounting is added to the aufs stack.

But near the end of this script, right before switch_root to /pup_new, these folders are unmounted:

Code: Select all

umount /sys
umount /dev
umount /proc

My question is, when /dev is unmounted, why does it not break the aufs stack? Doesn't the sfs file (eg. adrv_fossapup64_9.5.sfs) still need to stay connected to /dev/loopx?

I remember wondering that too when first designing an initramfs for booting the root filesystems I was creating via what I called build_firstrib_rootfs script. I noted it was common practice to umount these but read from switch_root man page:

switch_root moves already mounted /proc, /dev, /sys and /run to
newroot and makes newroot the new root filesystem and starts init
process.

WARNING: switch_root removes recursively all files and
directories on the current root filesystem.

Also: https://unix.stackexchange.com/question ... -initramfs
So if anything it seemed --move /dev and so on seemed more appropriate (tho not reqd if switch_root itself auto doing that). Indeed Rob Langley suggested:

https://landley.net/writing/rootfs-programming.html

Code: Select all

  # Unmount everything else you've attached to rootfs.  (Moving the filesystems
  # into newroot is something useful to do with them.)

  mount --move /sys /newroot/sys
  mount --move /proc /newroot/proc
  mount --move /dev /newroot/dev

However, there was never enough time in the day to worry and worked to simply umount dev proc sys without issue apparently. Why... indeed. Personally I think shouldn't be done, so why no harm for aufs overlayfs scenario? Perhaps the umount simply fails in the background. For example /dev/pts is involved so maybe a 'target busy' fail occurs on trying to umount /dev? But I'm just guessing and per my usual habit I try things and if they work without apparent issue then I just accept it and move on (engineer rather than computer scientist approach)... though would be nice to know though answer is no doubt way down in the system C code implementations really and claimed know-why answers may well be just guesses too... I say skeptically.

[wiak]

I forgot to add this main post I came across that asks somewhat similar question and has some answers that don't answer it for me clearly though:

https://gitlab.com/postmarketOS/pmaports/-/issues/1410

which also refers to: https://git.busybox.net/busybox/tree/ut ... oot.c#n253

Not that I tried to understand it, but Langley ends up saying:

(Yes, this is all screwy and I had to email questions to Linus Torvalds to get
it straight myself. I keep meaning to write up a "how mount actually works"
document someday...)

[fredx181]

To clarify a bit (once mounted = stays mounted, unless unmounted). A *weird* example test (not recommended to do it, just to test )
Say you have a USB stick plugged in and it's sdb1, now just mount it and check if it's OK in e.g. file-manager.
Then go in /dev (as root) and delete sdb and sdb1.
Now, how clumsy .... . what did I do ? Probably now my USB sdb1 isn't mounted anymore as I deleted the block devices for sdb...
Not, still the sdb1 is mounted properly, but if you unmount it and try to mount it again later... oops.. not working.

[williams2]

MS Windows will not let you delete or move or rename a file or dir that is in use ... mounted or being edited etc.

If a file is deleted in Linux, it will remove the file name from the virtual file system, so you can not access that file by name, but the inode and permissions and the list of data blocks that the file is using is a still there, still being used by the open file's id.

When the file is no longer in use, for example, when it is unmounted, the file will no longer have an open id and the inode and all the data belonging to the inode will be released.

If the operating system shuts down before the inode data is removed, the inode and data will still be in the file system, but with no file name. This is called an orphan inode, and is very common. Fsck will find and fix orphaned inodes. A journalled file system like ext3 or ext4 has the information that fsck needs, so fsck can fix orphaned inodes in a fraction of a second. Ext2 does not have a journal, so fsck needs to search through all the inodes of the file system to find any orphaned inodes, which can take hours.

By default, ext3 and ext4 do not journal data, just the metadata, so the journal is just as fast as no journal, and does not write to the file system much more than no journal, if at all.

Why umounting /dev does not break the aufs stack?

Because the /dev file is still in use, and will not be completely deleted until after the file is unmounted.
Until it is unmounted, only the file name will be deleted.
Unlike MS Windows.

PS Deleting a file is a process. First, the file name is unlinked, Then the data blocks that the file was using are released. Then the inode and the metadata in the inode are released. Each step is written in the journal, so the system knows exactly what was done and what should have been done. Which is why a journal is a good thing.

PS Fatdog "deletes" the sfs files that it copied to tmpfs, then mounted. Which deletes the file names but does not delete the actual files. So the files are still using all of the space in ram that they were using before they were "deleted". Why they do this I do not know.

[miltonx]

Thank you for all the input.

The /dev/loop thing is a complicated thing. After reading Fred's post, I think it is too much beyond my depth.

But the SFS loading / deleting case provided by Fred is quite interesting. I was not sure whether it was because the sfs was already saved somewhere in RAM or, as williams2 said, the original file data is still being used after removing the file. So I made this experiment.

Experiment 1:
1. Load firefox.sfs on the fly. (Before loading it I ran losetup -f to know that the loop device is /dev/loop4).
2. Delete firefox.sfs, and delete /dev/loop4
3. Firefox runs ok.
Conclusion:
1. It's ok to remove the loop device after mounting SFS.
2. But we do not know whether firefox is working from a copy in ram or the original SFS file data.

So, Experiment 2:
1. Load firefox.sfs on the fly. The firefox.sfs file is on a usb drive.
2. Unplug the usb.
3. Firefox does not work.
Conclusion:
The SFS was NOT copied to RAM. Williams2 is probably correct that Linux was still trying to use the original SFS file data even after it was removed.

[wiak]

The SFS was NOT copied to RAM. Williams2 is probably correct that Linux was still trying to use the original SFS file data even after it was removed.

Ah well, yes, it is not copied to RAM unless that is actually arranged for. In weedog initrd, for example, that option is available; meaning there is an actual cp -a of the sfs files (optional) into /mnt/layers/RAM which is arranged to be tempfs - after that copy to RAM the mount sfs command is given. If not copying to RAM then mounting the sfs is from the disk media (rather than RAM). I don't know about Puppy Linux distro, however - it's 'normal/default' boot (well, depends on kernel line options used of course) - looks like it IS doing a copy of sfs files to RAM during boot (hence takes a while).

[fredx181]

So, Experiment 2:
1. Load firefox.sfs on the fly. The firefox.sfs file is on a usb drive.
2. Unplug the usb.
...

When I try to unmount the usb in such a case I get the the message something like 'target is busy" so cannot unmount it.
If you unplug the usb without unmounting first (not recommended btw, but that's beside the subject) it's very much "forced unmount".
Deleting just the firefox.sfs file may have different result I think, but not sure (and when running losetup -a it will still be listed but shows as "(deleted)").
(and then still , from what I tested, the files are reachable at the mountpoint).
EDIT: Don't know btw if sfs-load on the fly does copy to RAM.

[williams2]

Don't know btw if sfs-load on the fly does copy to RAM

Code: Select all

# before:

# losetup
/dev/loop1: [0016]:1826 /initrd/mnt/tmpfs/zdrv_bionicpup64_8.0.sfs
/dev/loop2: [0016]:1840 /initrd/mnt/tmpfs/adrv_bionicpup64_8.0.sfs
/dev/loop0: [0016]:641 /initrd/mnt/tmpfs/puppy_bionicpup64_8.0.sfs

# after:

# losetup
/dev/loop1: [0016]:1826 /initrd/mnt/tmpfs/zdrv_bionicpup64_8.0.sfs
/dev/loop2: [0016]:1840 /initrd/mnt/tmpfs/adrv_bionicpup64_8.0.sfs
/dev/loop0: [0016]:641 /initrd/mnt/tmpfs/puppy_bionicpup64_8.0.sfs
/dev/loop3: [2052]:311568 /mnt/home/devx_bionicpup64_8.0.sfs
#
# mount-FULL
/dev/sda4 on /mnt/home type fuseblk (rw,noatime,user_id=0,group_id=0,default_permissions,blksize=4096)
/mnt/home/devx_bionicpup64_8.0.sfs on /initrd/pup_ro3 type squashfs (ro,noatime)
#

Before, the sfs files that were copied to ram /initrd/mnt/tmpfs/ are linked as block devices /dev/loop...
The file systems in the block devices are mounted mount-FULL
and the 3 mounted file systems are used as layers by aufs.

After, I ran sfs_load to mount the sfs file /mnt/home/devx_bionicpup64_8.0.sfs
which is on /mnt/home/ which is my ntfs hard drive partition that MS Windows is installed to.

So /mnt/home/devx_bionicpup64_8.0.sfs which is on my hard drive,
was mounted on mount point /initrd/pup_ro3
which is added as a layer by aufs.

So the devx sfs file that is on my hard drive was mounted by sfs_load.

The sfs file was not copied to the tmpfs file system in ram, and then mounted.

charlie-brown.jpg (7.76 KiB) Viewed 1493 times

[wiak]

So /mnt/home/devx_bionicpup64_8.0.sfs which is on my hard drive,
was mounted on mount point /initrd/pup_ro3
which is added as a layer by aufs.

So the devx sfs file that is on my hard drive was mounted by sfs_load.

The sfs file was not copied to the tmpfs file system in ram, and then mounted.

I don't have a habit of using savefiles or frugal installations to ntfs filesystems (I habitually use Linux fs either with direct write back or with save folders); however, I suspect it is difficult to arrange holding sessions in RAM and then only saving back to savefile if that savefile is on ntfs partition. Is that mode what Puppy crowd call Pupmode 13?

Problem would be, I think, that the savefile image, when stored on an ntfs partition, would likely be mounted by initramfs in read only mode (since usually wouldn't have the likes of ntfs-3g on the initrd) and then, unless the actual sfs files were physically copied to RAM first then once you mount them from original ntfs boot directory for use with aufs (or overlayfs for that matter) the whole lot will stay read-only. It seems to me that to remount the savefile img as read-write for saving back a session to it, then it would first have to be unmounted, but even if that didn't give a 'target busy' failure (such as fredx181 referred to) you could still only mount it read only (even after switch_root to main filesystem where ntfs-3g is available) because underlying partition it is on remains mounted as read-only and in busy use by the layers in aufs (or overlayfs). Or am I wrong?

I made a quick ext4 formatted image file and did some quick tests, and what I say seems to be the case. The only way to get that savefile into read-write mount state (such that changes could be written back to it) was to umount all other sfs files that were mounted from that original ntfs boot from directory - but... couldn't actually do that, because after switch root the layering system held onto the read-only mounts (similar to what fredx181 suggested in other context) so the umount fails with target 'busy'. I was able to umount the ntfs partition (and thus arrange to make the savefile image read-write on further mount command, if and only if I first copied all the bits to RAM prior to mounting them (since then the ntfs partition isn't the source so is no longer 'target busy').

Drawback is that that copy-into-RAM-first method eats up a lot of RAM that stays eaten up (and a bit complex to set up). I tried saving back session changes thereafter (with a view to mounting them in read-only layer on next boot) - originally I considered tar.gz or similar like I think tinycorelinux does, but would need untarred or archivemount, and mksquashfs creates archives faster/more-efficiently from what I read - however, I 'think' in the end I would be able to now (with every layer sfs being mounted from their RAM copy) simply mount the savefile on the actual ntfs partition read-write (the original - not the copy of it which was loaded into RAM) and then directly rsync session changes back to it. I didn't spend long on this (despite some 'target busy' annoyances on first attempts) so I need to double-check (though all seemed to work - but, yes, at the cost of RAM). As I say, I normally don't use savefiles anyway (and certainly wouldn't normally use frugal installs on ntfs partitions anyway), but this laptop I am using has tons of space alongside Windows install on ntfs and I'm running out of Linux fs space, but don't yet want to shrink that useless-to-me Windows ntfs partition further (this is business machine - not really supposed to be for my 'experiments'...).

I'm not using Puppy anyway at the moment (and do not at all know the ins and outs of its mind-boggling initrd/init) - it was KLV-airedale I was using (WDL skeleton initrd), and experimenting with savefile ext4 image, and w_copy2ram everything, followed by w_changes in what is called RAM2 mode there (but mounting the savefile img from the RAM copy of it such that the on-disk savefile remains accessible and able to be mounted read-write for end of session rsync back to it).

Certainly you cannot simply do a mount -o remount,rw - that doesn't work; first you need to umount, and you can't umount if the partition remains in use by something else (and is a read-only filesystem since ntfs could only initially be mounted as such by the initrd - another way out would be to include ntfs-3g and all its dependencies in the initrd of course... possible). This post is not exactly what the original post in this thread was about, but strongly related to it.

[wiak]

So if my above post is correct it is also about the benefit of aufs over overlayfs. It is not just sfs-load-on-the-fly being impossible via overlayfs itself. Anything you might want to do to the layer stack after initramfs (initrd/init) has done its business becomes problematic with overlayfs, but possible with aufs. With overlayfs, it seems to me, you cannot delay creating the whole layer stack till after main root filesystem becomes available and with ntfs underlying partition: what is already mounted for the layer stack is read-only and cannot be remounted read-write (at least I can't find a way thus far). With aufs, you can wait to mount some parts of the layer stack till main filesystem becomes available and hence get read-write capability when you do mount layer (e.g. savefile) from ntfs. For the case of Puppy that probably means that the likes of Pupmode 12 and 13, when using a savefile, can be arranged to work on ntfs partition if using aufs but become difficult to achieve if using overlayfs.

[mistfire]

So if my above post is correct it is also about the benefit of aufs over overlayfs. It is not just sfs-load-on-the-fly being impossible via overlayfs itself. Anything you might want to do to the layer stack after initramfs (initrd/init) has done its business becomes problematic with overlayfs, but possible with aufs. With overlayfs, it seems to me, you cannot delay creating the whole layer stack till after main root filesystem becomes available and with ntfs underlying partition: what is already mounted for the layer stack is read-only and cannot be remounted read-write (at least I can't find a way thus far). With aufs, you can wait to mount some parts of the layer stack till main filesystem becomes available and hence get read-write capability when you do mount layer (e.g. savefile) from ntfs. For the case of Puppy that probably means that the likes of Pupmode 12 and 13, when using a savefile, can be arranged to work on ntfs partition if using aufs but become difficult to achieve if using overlayfs.

In case of NTFS that's ntfs3 kernel module steps in. It's already used on QuickPup64 using peebee's lxpup kernel. And use it as my daily driver. It performs fast. Right now, my latest experiment was adding ovelayfs support on my QuickPup64. And yes sfs-load-on-the-fly is the problem from me. I want that feature to be carry on overlayfs

[wiak]

@mistfire Yes, thought of that ntfs3 in kernel driver, but how to use it from initrd when only have busybox mount available? Also good nowadays if overlays driver included in kernel build rather than just as module.

[mistfire]

@mistfire Yes, thought of that ntfs3 in kernel driver, but how to use it from initrd when only have busybox mount available?

mount -t ntfs3 -o <options> <device> <mountpoint>

https://www.kernel.org/doc/html/latest/ ... ntfs3.html

The options where almost the same as ntfs-3g. but the locale must be set to unicode to otherwise some file/folder name using non-alphabet character will be hidden.

QuickPup64 initrd has ntfs3 detection. It will use ntfs3 by default if found as kernel builtin otherwise, it will fallback to ntfs-3g

[wiak]

Ah, didn't realize the -t ntfs3 option also worked with busybox mount - I thought I tried it but probably didn't...

[williams2]

Since no one seems to be answering these questions ....

Is that mode what Puppy crowd call Pupmode 13?

I am running BionicPup64, mode 5, because I booted pfix=ram, which does not mount save files or folders.
A tmpfs file system is created in ram.
The sfs files are copied to ram, then the file system in each sfs file is mounted on mount points in /initrd/
Then aufs creates a layered file system, with the rw top layer in ram.

Code: Select all

# aufs-layers 
/initrd/mnt/tmpfs/pup_rw=rw
/initrd/pup_a=rr
/initrd/pup_ro2=rr
/initrd/pup_z=rr
#

At this point, everything is in ram.
All of this is done by the script init which is in the initrd file.
There is a copy if the init file in /initrd.
But that copy is not the file that actually did the work.

I can run Puppy that way, all in ram, with an adrv.sfs instead of a save file.
But I usually mount the ntfs file system that is in /dev/sda4 on mountpoint /mnt/home/ using ntfd-3g.
For example, Firefox is not in this BionicPup at all, it is saved on /mnt/home/
and is what I am using to access this forum.
Most files I have saved are in /mnt/home.

I have 5 Bionic 3fs files and 1 Bionic 4fs in /mnt/home/
I can use them by not booting with pfix=ram
The init script in the initrd boot file will mount /dev/sda4 on /mnt/home/ read/write using ntfs-3g
then it will mount one of the 3fs save files in /mnt/home/ as the BionicPup64 save file.
A save file is never copied to ram.
The contents of a save file's file system is never copied to ram.
Writing anything to the Linux virtual file system will write directly to the top layer of the layered aufs file system.
In my case, it would write directly to the 3fs file that is on the ntfs in /dev/sda4 on the hard drive.
This is mode 12.

Problem would be, I think, that the savefile image, when stored on an ntfs partition, would likely be mounted by initramfs in read only mode (since usually wouldn't have the likes of ntfs-3g on the initrd)

No. The rw save file is on the rw ntfs file system that is on a hard drive partition, or on a usb drive.
The init script in the initrd file does this.

Code: Select all

# grep -i ntfs /initrd/init
17:L_WINDOWS_HIBERNATED="ERROR: Windows NTFS hibernated partition, cannot mount"
142:  ntfs)
143:   ntfs-3g $MNT_DEV $MNT_DIR -o umask=0,no_def_opts,noatime,rw,silent 2>/dev/null #default is rw. 130211 add silent.
144:   ntfsRETVAL=$?
145:   [ $ntfsRETVAL -eq 0 ] && return 0
146:   if [ $ntfsRETVAL -eq 14 ];then
150:    ntfs-3g $MNT_DEV $MNT_DIR -o umask=0,no_def_opts,noatime,rw,force,silent 2>/dev/null #130211 add silent.
# wc /initrd/init
 1463  6651 53859 /initrd/init
# 

Puppy never copies a save file into ram.
Puppy never copies the contents of the file system in a save file, into ram.

[wiak]

Code: Select all

# grep -i ntfs /initrd/init
17:L_WINDOWS_HIBERNATED="ERROR: Windows NTFS hibernated partition, cannot mount"
142:  ntfs)
143:   ntfs-3g $MNT_DEV $MNT_DIR -o umask=0,no_def_opts,noatime,rw,silent 2>/dev/null #default is rw. 130211 add silent.
144:   ntfsRETVAL=$?
145:   [ $ntfsRETVAL -eq 0 ] && return 0
146:   if [ $ntfsRETVAL -eq 14 ];then
150:    ntfs-3g $MNT_DEV $MNT_DIR -o umask=0,no_def_opts,noatime,rw,force,silent 2>/dev/null #130211 add silent.
# wc /initrd/init
 1463  6651 53859 /initrd/init
# 

Puppy never copies a save file into ram.
Puppy never copies the contents of the file system in a save file, into ram.

Okay, that tells me what I was curious about.

Problem would be, I think, that the savefile image, when stored on an ntfs partition, would likely be mounted by initramfs in read only mode (since usually wouldn't have the likes of ntfs-3g on the initrd)

No. The rw save file is on the rw ntfs file system that is on a hard drive partition, or on a usb drive.

As I said, I'm not myself using Puppy and do not have ntfs-3g (plus its dependencies) in my initrd, so what I said before stands with older kernels - i.e. without ntfs3 new kernels the only way to get rw would be to load savefile into RAM (when ntfs-3g not available in an initramfs). However, the above Puppy code informs that Puppy initrd includes ntfs-3g, which as I commented before would be one way of arranging for it all to work. In more recent kernels, as mistfire comments, you don't need it since ntfs3 driver is built into the kernel itself, so I'm using savefiles via that ntfs3 support the newish kernel I use provides and not of course then needing to load the savefile into RAM first. I am not using copy to ram for the sfs files, but works okay either way.

[williams2]

As I said, I'm not myself using Puppy and do not have ntfs-3g (plus its dependencies)

AFAIK, XenialPup and BionicPup and FossaPup all have ntfs-3g in the initrd file system.
The ntfs-3g executable is a static build.

Code: Select all

# cd /initrd/files/bin/
# ll ntfs-3g 
-rwxr-xr-x 1 367K Sep 25  2018 ntfs-3g
# file ntfs-3g 
ntfs-3g: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
# ldd ntfs-3g 
	not a dynamic executable
#

ntfs-3g is slow, but seems to be reliable.