[issue]: Instead of dm-patch, consider a more secure and upstreamable solution that does not do kernel taint

hgkamath commented 1 year ago

Official FAQ

[X] I have checked the official FAQ.

Ventoy Version

1.0.88

What about latest release

Yes. I have tried the latest release, but the bug still exist.

Try alternative boot mode

Yes. I have tried them, but the bug still exist.

BIOS Mode

UEFI Mode

Partition Style

GPT

Disk Capacity

2TB

Disk Manufacturer

Seagate

Image file checksum (if applicable)

None

Image file download link (if applicable)

No response

What happened?

This thought came while trying to get vtoyboot/VTOY_LINUX_REMOUNT to work

In a few years, there may be 3 looming trouble areas on the time horizon.

Many Linux distributions may start using unified kernels in which the binary kernel and the initramfs are bundled together and signed together ex: phoronix 20230110 Fedora-38 unified kernel . Though such feature will be optional at first, for security reasons there is a possibility that it may become the mainstream way, and if it does, its more work, to first setup the system to not use unified kernel, or dealing with self-signing initramfs and or unified kernel.
There will be multiple sub-microarchitecture of x86-64 : v1 v2 v3 and v4, phoronix 20230202 rpm x86-64 feature levels, that means patching kernels for each sub-microarchitecture level could become tricky. 20221209 phoronix the performance of cachyos linux . There will also architectures of other newer PC processor architectures aarch64, RISCV, MIPS64.
There will be disks of size 4Gb and larger, using larger block sizes, that will start becoming common place. There have been many bug reports in ventoy lately, like #2173, that 4tb drives are not yet supported as they use larger disk-level block size. The code will hence need to parametrized by block-size.

Even now, there is trouble

with dm-patch application due to kernel updates/changes/incompatibility (vtoyboot-#62 kernel 6.1 dm_patch not loading, also dm_patch: module verification failed: signature and/or required key missing - tainting kernel),
with secureboot/taint (ventoy-#135 Ventoy should only allow the execution of Secure Boot signed executables when Secure Boot is enabled).
with multiple linux distribution methods. As I read the vtoyboot scripts, it seems like duplicated work to figure out how to get dm_patch to patch dm-mod and work, on 3 different booting and module systems initramfs, dracut, mkcpinitio, to patch the dm, load the modules and prepare the rootfs pivot.

If it were part of kernel, then at-least patching the dm would go away and it will be by default already be secureboot signed at distribution.

If the dm-patch were upstreamed as a feature of dm into the linux-kernel, then separate maintenance will get replaced with committed maintenance. One has to keep up with the kernel anyway, whether it be via patching or in-tree. The level of code quality as well as responsiveness to new-kernel readiness will need to meet kernel-code-standards, and kernel stewards will need a committed maintenance keeping up playing nicely with with new kernel features.

In order to upstream, kernel stewards would need convincing that multibooting iso-s and nativebooting vdisks is a common usecase, and that the code for the feature will be maintained.

A kernel parameter could then enable the feature in DM on kernel-boot-cmdline, for only those who use ventoy, thereby keeping those who don't use the feature safe from misuse.

Presently the way dm_patch is inserted into kernel, as an external non-tree module, it is considered as a kernel-taint. even though ventoy is an open-source GPL project. The module patch is being distributed in binary form. This not only taints the kernel, but can also create incompatibilities as it the kernel dm module itself changes through the kernel versions. so it will work with a narrow version-range of linux kernels.

Presently, if dm_mod patch fails, then the host partition on which the vdisk lies, cannot be mounted read-write and used like a normal partition.

[root@fedora dev]# cat /proc/modules | grep dm_patch
[root@fedora dev]# 

[root@fedora tmp]# mount -t ntfs3 /dev/sdc1 /mnt/c1
mount: /mnt/c1: /dev/sdc1 already mounted or mount point busy.
       dmesg(1) may have more information after failed mount system call.

The feature that dm_patch provides (its purpose) is to make the vtoy-vdisk hosting partition to re-appear to the OS as unused/not-busy, so that it allows the hosting-partition to again be mountable as read-write despite the fact that devmapper mapped blocks within the partition are being used. the boot kernel cmdline parameter, VTOY_LINUX_REMOUNT, renamed in accordance with kernel parameter conventions, can be used for that purpose.

Filing this issue, so that there is something to think over, plan for and set a milestone. Feel free to close this issue if it is in-actionable.

log

The below are executed from inside a vtoy linux boot (m01_lnx.raw.img.vtoy on an ExFAT partition sda16)

[root@fedora gana]# uname -a
Linux fedora 6.1.11-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb  9 19:20:24 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

[root@fedora gana]# cat /etc/os-release | grep ^VERSION=
VERSION="37 (Workstation Edition)"

[root@fedora gana]# dmsetup info /dev/mapper/ventoy
Name:              ventoy
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        4
Event number:      0
Major, minor:      253, 0
Number of targets: 1

[root@fedora gana]# dmsetup ls
ventoy  (253:0)
ventoy1 (253:1)
ventoy2 (253:2)
ventoy3 (253:3)
ventoy4 (253:4)

[root@fedora gana]# dmsetup status /dev/mapper/ventoy
0 97386496 linear 

[root@fedora gana]# dmsetup table /dev/mapper/ventoy
0 97386496 linear 259:0 4470272

[root@fedora dev]# ls -l /dev/sda1
brw-rw----. 1 root disk 8, 1 Feb 14 15:59 /dev/sda1

[root@fedora dev]# ls -l | grep 253
brw-rw----.  1 root disk    253,   0 Feb 14 15:59 dm-0
brw-rw----.  1 root disk    253,   1 Feb 14 15:59 dm-1
brw-rw----.  1 root disk    253,   2 Feb 14 15:59 dm-2
brw-rw----.  1 root disk    253,   3 Feb 14 15:59 dm-3
brw-rw----.  1 root disk    253,   4 Feb 14 15:59 dm-4

[root@fedora dev]# ls -l | grep sda
brw-rw----.  1 root disk      8,   0 Feb 14 15:59 sda
brw-rw----.  1 root disk      8,   1 Feb 14 15:59 sda1
brw-rw----.  1 root disk      8,  10 Feb 14 15:59 sda10
brw-rw----.  1 root disk      8,  11 Feb 14 15:59 sda11
brw-rw----.  1 root disk      8,  12 Feb 14 15:59 sda12
brw-rw----.  1 root disk      8,  13 Feb 14 15:59 sda13
brw-rw----.  1 root disk      8,  14 Feb 14 15:59 sda14
brw-rw----.  1 root disk      8,  15 Feb 14 15:59 sda15
brw-rw----.  1 root disk    259,   0 Feb 14 15:59 sda16
brw-rw----.  1 root disk    259,   1 Feb 14 15:59 sda17
brw-rw----.  1 root disk      8,   2 Feb 14 15:59 sda2
brw-rw----.  1 root disk      8,   3 Feb 14 15:59 sda3
brw-rw----.  1 root disk      8,   4 Feb 14 15:59 sda4
brw-rw----.  1 root disk      8,   5 Feb 14 15:59 sda5
brw-rw----.  1 root disk      8,   6 Feb 14 15:59 sda6
brw-rw----.  1 root disk      8,   7 Feb 14 15:59 sda7
brw-rw----.  1 root disk      8,   8 Feb 14 15:59 sda8
brw-rw----.  1 root disk      8,   9 Feb 14 15:59 sda9

[root@fedora dev]# sgdisk /dev/sda -p
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Model: SAMSUNG MZ7LN512
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 62F383DC-26C0-4DC8-9CFC-7228DB11A8E9
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 116361837 sectors (55.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          534527   260.0 MiB   EF00  EFI System Partition
   2          534528          538623   2.0 MiB     EF02  BIOS boot partition
   3          538624          800767   128.0 MiB   0C01  Microsoft reserved
   4          800768       122124287   57.9 GiB    0700  Microsoft basic data
   5       122189824       124100607   933.0 MiB   2700  
   6       124100608       157786111   16.1 GiB    0700  WINPAGE
   7       206020608       207044607   500.0 MiB   8300  Linux filesystem
   8       207044608       290930687   40.0 GiB    8300  Linux filesystem
   9       290930688       303513599   6.0 GiB     8300  Linux filesystem
  10       303513600       307707903   2.0 GiB     8300  Linux filesystem
  11       307707904       341262335   16.0 GiB    8200  Linux swap
  12       341262336       349650943   4.0 GiB     8300  
  13       417708032       494917631   36.8 GiB    8300  Linux filesystem
  14       494917632       499111935   2.0 GiB     0700  Microsoft basic data
  15       499111936       500117503   491.0 MiB   8300  
  16       500117504       805179391   145.5 GiB   0700  CPERF0
  17       805179392      1000212479   93.0 GiB    0700  Basic data partition

The below are executed from different linux boot

[root@fedora gana]# hdparm --fibmap /mnt/a16/m01_lnx.raw.img.vtoy 
/mnt/a16/m01_lnx.raw.img.vtoy:
 filesystem blocksize 512, begins at LBA 500117504; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0  504587776  601974271   97386496

[root@fedora gana]# ls -l /mnt/a16/m01_lnx.raw.img.vtoy 
-rwxrwxr-x. 1 gana gana 49861885952 Feb 12 19:18 /mnt/a16/m01_lnx.raw.img.vtoy

[root@sirius gana]# hdparm --fibmap /vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy
/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy:
 filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0 1973078936 2070465431   97386496

Ref

ventoy/DMPATCH/dmpatch.c
dm_patch_64.ko vtoyboot.sh, and various shell scripts that run during initramfs creation and during initramfs bootup are distributed inside vtoyboot-1.0.25.iso (why iso? maybe to prevent newbies from running accidentally on working systems. The iso needs to be loop-mounted, and the file vtoyboot-1.0.25.tar.xz needs to be copied-off and extracted)
Documentation of linux vdisk boot plugin https://www.ventoy.net/en/plugin_vtoyboot.html

hgkamath commented 1 year ago

Below log comes from a boot of a fedora workstation 37 live-iso Fedora-Workstation-Live-x86_64-Rawhide-20230213.n.0.iso breaked in initramfs at pre-mount using rd.break=pre-mount.
The following is a file-listing of ventoy files in the initramfs during the initramfs-boot-stage before pivot

[root@localhost-live liveuser]# # find / | grep toy | grep -v a12 > cat /mnt/a12/gana/tmp/vtoy2_fed38_initramfsls.log
[root@localhost-live liveuser]# cat /mnt/a12/gana/tmp/vtoy2_fed38_initramfsls.log 
/usr/lib/dracut/hooks/pre-udev/99-ventoy-inotifyd-start.sh
/usr/lib/dracut/hooks/initqueue/timeout/99-ventoy-timeout.sh
/usr/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fventoy.sh
/usr/lib/dracut/hooks/emergency/80-\x2fdev\x2fventoy.sh
/sys/firmware/efi/efivars/VentoyOsParam-77772020-2e77-6576-6e74-6f792e6e6574
/run/udev/links/disk\x2fby-partlabel\x2f15KJ_Ventoy
/run/udev/links/disk\x2fby-partlabel\x2f15KJ_Ventoy/b8:33
/etc/systemd/system/dev-ventoy.device.d
/etc/systemd/system/dev-ventoy.device.d/timeout.conf
/etc/systemd/system/initrd.target.wants/dev-ventoy.device
/dev/disk/by-partlabel/15KJ_Ventoy
/dev/ventoy
/dev/mapper/ventoy
/ventoy
/ventoy/hook_finish
/ventoy/zonefs.ko.xz
/ventoy/kallsyms
/ventoy/ventoy_dm_table
/ventoy/distmagic
/ventoy/inotifyd-hook-script.txt
/ventoy/xzlog
/ventoy/loop
/ventoy/loop/easyos
/ventoy/loop/easyos/ventoy-disk.sh
/ventoy/loop/easyos/ventoy-resize.sh
/ventoy/loop/easyos/ventoy-hook.sh
/ventoy/loop/fwts
/ventoy/loop/fwts/ventoy-disk.sh
/ventoy/loop/fwts/ventoy-hook.sh
/ventoy/loop/volumio
/ventoy/loop/volumio/ventoy-disk.sh
/ventoy/loop/volumio/ventoy-hook.sh
/ventoy/loop/ubos
/ventoy/loop/ubos/ventoy-disk.sh
/ventoy/loop/ubos/newroot-hook.sh
/ventoy/loop/ubos/ventoy-hook.sh
/ventoy/loop/LibreELEC
/ventoy/loop/LibreELEC/ventoy-disk.sh
/ventoy/loop/LibreELEC/ventoy-hook.sh
/ventoy/loop/recalbox
/ventoy/loop/recalbox/ventoy-disk.sh
/ventoy/loop/recalbox/ventoy-create-part.sh
/ventoy/loop/recalbox/ventoy-hook.sh
/ventoy/loop/recalbox/ventoy-share.sh
/ventoy/loop/batocera
/ventoy/loop/batocera/ventoy-disk.sh
/ventoy/loop/batocera/ventoy-hook.sh
/ventoy/loop/cloudready
/ventoy/loop/cloudready/ventoy-hook.sh
/ventoy/loop/freedombox
/ventoy/loop/freedombox/ventoy-disk.sh
/ventoy/loop/freedombox/ventoy-hook.sh
/ventoy/loop/esysrescue
/ventoy/loop/esysrescue/ventoy-disk.sh
/ventoy/loop/esysrescue/ventoy-hook.sh
/ventoy/loop/paldo
/ventoy/loop/paldo/ventoy-disk.sh
/ventoy/loop/paldo/ventoy-hook.sh
/ventoy/loop/openwrt
/ventoy/loop/openwrt/ventoy-disk.sh
/ventoy/loop/openwrt/ventoy-hook.sh
/ventoy/loop/tails
/ventoy/loop/tails/ventoy-disk.sh
/ventoy/loop/tails/ventoy-hook.sh
/ventoy/loop/lakka
/ventoy/loop/lakka/ventoy-disk.sh
/ventoy/loop/lakka/ventoy-hook.sh
/ventoy/loop/endless
/ventoy/loop/endless/ventoy-inotifyd-hook.sh
/ventoy/loop/endless/ventoy-inotifyd-start.sh
/ventoy/loop/endless/ventoy-hook.sh
/ventoy/loop/fydeos
/ventoy/loop/fydeos/ventoy-hook.sh
/ventoy/tool
/ventoy/tool/veritysetup
/ventoy/tool/vtoy_unsquashfs
/ventoy/tool/vtoy_fuse_iso
/ventoy/tool/vtoyexpand
/ventoy/tool/vtoykmod
/ventoy/tool/vtoyksym
/ventoy/tool/hald
/ventoy/tool/loader
/ventoy/tool/vtoydm
/ventoy/tool/vtoydump
/ventoy/tool/vine_patch_loader
/ventoy/tool/zstdcat
/ventoy/tool/lz4cat
/ventoy/tool/lunzip
/ventoy/tool/dmsetup
/ventoy/tool/lz4cat64
/ventoy/tool/vtoytool
/ventoy/tool/vtoytool/00
/ventoy/tool/vtoytool/00/vtoytool_32
/ventoy/tool/vtoytool/00/vtoytool_64
/ventoy/tool/vtoytool/02
/ventoy/tool/vtoytool/02/vtoytool_64
/ventoy/tool/vtoytool/01
/ventoy/tool/vtoytool/01/vtoytool_64
/ventoy/tool/vblade_32
/ventoy/tool/dmsetup32
/ventoy/tool/lunzip32
/ventoy/tool/veritysetup32
/ventoy/tool/ar
/ventoy/tool/vtoy_fuse_iso_32
/ventoy/tool/vtoy_fuse_iso_64
/ventoy/tool/vtoytool_install.sh
/ventoy/tool/dmsetup64
/ventoy/tool/inotifyd
/ventoy/tool/dm_patch_32.ko
/ventoy/tool/lunzip64
/ventoy/tool/unsquashfs_64
/ventoy/tool/veritysetup64
/ventoy/tool/ventoy_loader.sh
/ventoy/tool/vblade_64
/ventoy/tool/zstdcat64
/ventoy/tool/unsquashfs_32
/ventoy/tool/dm_patch_64.ko
/ventoy/hook
/ventoy/hook/nixos
/ventoy/hook/nixos/ventoy-hook.sh
/ventoy/hook/nixos/udev_disk_hook.sh
/ventoy/hook/ventoy-hook-lib.sh
/ventoy/hook/nutyx
/ventoy/hook/nutyx/ventoy-disk.sh
/ventoy/hook/nutyx/ventoy-hook.sh
/ventoy/hook/slackware
/ventoy/hook/slackware/disk_hook.sh
/ventoy/hook/slackware/ventoy-hook.sh
/ventoy/hook/slackware/udev_disk_hook.sh
/ventoy/hook/suse
/ventoy/hook/suse/disk_hook.sh
/ventoy/hook/suse/udev_setup_hook.sh
/ventoy/hook/suse/ventoy-hook.sh
/ventoy/hook/suse/udev_disk_hook.sh
/ventoy/hook/rhel5
/ventoy/hook/rhel5/ventoy-hook.sh
/ventoy/hook/rhel5/ventoy-loader.sh
/ventoy/hook/kwort
/ventoy/hook/kwort/disk-hook.sh
/ventoy/hook/kwort/ventoy-hook.sh
/ventoy/hook/debian
/ventoy/hook/debian/slax-hook.sh
/ventoy/hook/debian/bliss-hook.sh
/ventoy/hook/debian/linuxconsole-hook.sh
/ventoy/hook/debian/pyabr-disk.sh
/ventoy/hook/debian/puppy-hook.sh
/ventoy/hook/debian/list-devices
/ventoy/hook/debian/porteus-disk.sh
/ventoy/hook/debian/veket-hook.sh
/ventoy/hook/debian/knoppix-disk.sh
/ventoy/hook/debian/porteus-path.sh
/ventoy/hook/debian/stratodesk-hook.sh
/ventoy/hook/debian/disk_mount_hook.sh
/ventoy/hook/debian/ventoy-cloud-init.sh
/ventoy/hook/debian/ventoy-inotifyd-hook.sh
/ventoy/hook/debian/pve-disk.sh
/ventoy/hook/debian/mocaccino-hook.sh
/ventoy/hook/debian/veket-disk.sh
/ventoy/hook/debian/kerio-disk.sh
/ventoy/hook/debian/antix-hook.sh
/ventoy/hook/debian/pyabr-hook.sh
/ventoy/hook/debian/pve-hook.sh
/ventoy/hook/debian/vyos-hook.sh
/ventoy/hook/debian/mocaccino-disk.sh
/ventoy/hook/debian/kylin-disk.sh
/ventoy/hook/debian/minios-disk.sh
/ventoy/hook/debian/mll-disk.sh
/ventoy/hook/debian/stratodesk-disk.sh
/ventoy/hook/debian/antix-disk.sh
/ventoy/hook/debian/porteus-hook.sh
/ventoy/hook/debian/vyos-disk.sh
/ventoy/hook/debian/kerio-hook.sh
/ventoy/hook/debian/puppy-disk.sh
/ventoy/hook/debian/tails-hook.sh
/ventoy/hook/debian/default-hook.sh
/ventoy/hook/debian/knoppix-hook.sh
/ventoy/hook/debian/ventoy-hook.sh
/ventoy/hook/debian/minios-hook.sh
/ventoy/hook/debian/bliss-disk.sh
/ventoy/hook/debian/slax-disk.sh
/ventoy/hook/debian/udev_disk_hook.sh
/ventoy/hook/debian/mll-hook.sh
/ventoy/hook/debian/ventoy_env2debconf.sh
/ventoy/hook/debian/kylin-hook.sh
/ventoy/hook/debian/linuxconsole-disk.sh
/ventoy/hook/tinycore
/ventoy/hook/tinycore/ventoy-disk.sh
/ventoy/hook/tinycore/ventoy-hook.sh
/ventoy/hook/rancher
/ventoy/hook/rancher/disk_hook.sh
/ventoy/hook/rancher/ventoy-hook.sh
/ventoy/hook/easystartup
/ventoy/hook/easystartup/disk_hook.sh
/ventoy/hook/easystartup/ventoy-hook.sh
/ventoy/hook/easystartup/ventoy-initqueue.sh
/ventoy/hook/hyperbola
/ventoy/hook/hyperbola/ventoy-disk.sh
/ventoy/hook/hyperbola/ventoy-timeout.sh
/ventoy/hook/hyperbola/ventoy-hook.sh
/ventoy/hook/xen
/ventoy/hook/xen/ventoy-hook.sh
/ventoy/hook/xen/udev_disk_hook.sh
/ventoy/hook/smoothwall
/ventoy/hook/smoothwall/disk_hook.sh
/ventoy/hook/smoothwall/cd_list.sh
/ventoy/hook/smoothwall/ventoy-hook.sh
/ventoy/hook/rhel6
/ventoy/hook/rhel6/anaconda-repo-listen.sh
/ventoy/hook/rhel6/ventoy-hook.sh
/ventoy/hook/rhel6/udev_disk_hook.sh
/ventoy/hook/rhel6/ventoy-varexp.sh
/ventoy/hook/vine
/ventoy/hook/vine/dev-listen.sh
/ventoy/hook/vine/ventoy-hook.sh
/ventoy/hook/vine/udev_disk_hook.sh
/ventoy/hook/kaos
/ventoy/hook/kaos/ventoy-disk.sh
/ventoy/hook/kaos/ventoy-hook.sh
/ventoy/hook/adelie
/ventoy/hook/adelie/disk-hook.sh
/ventoy/hook/adelie/ventoy-hook.sh
/ventoy/hook/t2
/ventoy/hook/t2/disk_hook.sh
/ventoy/hook/t2/ventoy-hook.sh
/ventoy/hook/crux
/ventoy/hook/crux/disk_hook.sh
/ventoy/hook/crux/ventoy-hook.sh
/ventoy/hook/alt
/ventoy/hook/alt/ventoy-hook.sh
/ventoy/hook/alt/udev_disk_hook.sh
/ventoy/hook/blackPanther
/ventoy/hook/blackPanther/ventoy-inotifyd-hook.sh
/ventoy/hook/blackPanther/ventoy-inotifyd-start.sh
/ventoy/hook/blackPanther/ventoy-hook.sh
/ventoy/hook/guix
/ventoy/hook/guix/ventoy-disk.sh
/ventoy/hook/guix/ventoy-hook.sh
/ventoy/hook/guix/ventoy-before-init.sh
/ventoy/hook/manjaro
/ventoy/hook/manjaro/ventoy-disk.sh
/ventoy/hook/manjaro/ventoy-inotifyd-hook.sh
/ventoy/hook/manjaro/ventoy-hook.sh
/ventoy/hook/lunar
/ventoy/hook/lunar/ventoy-inotifyd-hook.sh
/ventoy/hook/lunar/ventoy-inotifyd-start.sh
/ventoy/hook/lunar/ventoy-hook.sh
/ventoy/hook/austrumi
/ventoy/hook/austrumi/disk_hook.sh
/ventoy/hook/austrumi/ventoy-hook.sh
/ventoy/hook/berry
/ventoy/hook/berry/ventoy-disk.sh
/ventoy/hook/berry/ventoy-hook.sh
/ventoy/hook/parabola
/ventoy/hook/parabola/ventoy-disk.sh
/ventoy/hook/parabola/ventoy-timeout.sh
/ventoy/hook/parabola/ventoy-hook.sh
/ventoy/hook/fatdog
/ventoy/hook/fatdog/disk-hook.sh
/ventoy/hook/fatdog/ventoy-hook.sh
/ventoy/hook/zeroshell
/ventoy/hook/zeroshell/disk_hook.sh
/ventoy/hook/zeroshell/ventoy-hook.sh
/ventoy/hook/daphile
/ventoy/hook/daphile/disk_hook.sh
/ventoy/hook/daphile/ventoy-hook.sh
/ventoy/hook/cdlinux
/ventoy/hook/cdlinux/disk-hook.sh
/ventoy/hook/cdlinux/ventoy-hook.sh
/ventoy/hook/rhel7
/ventoy/hook/rhel7/ventoy-timeout.sh
/ventoy/hook/rhel7/ventoy-inotifyd-hook.sh
/ventoy/hook/rhel7/ventoy-make-link.sh
/ventoy/hook/rhel7/ventoy-overlay.sh
/ventoy/hook/rhel7/ventoy-autoexp.sh
/ventoy/hook/rhel7/ventoy-inotifyd-start.sh
/ventoy/hook/rhel7/ventoy-hook.sh
/ventoy/hook/rhel7/ventoy-repo.sh
/ventoy/hook/alpine
/ventoy/hook/alpine/insert.sh
/ventoy/hook/alpine/ventoy-hook.sh
/ventoy/hook/alpine/udev_disk_hook.sh
/ventoy/hook/primeos
/ventoy/hook/primeos/ventoy-disk.sh
/ventoy/hook/primeos/ventoy-hook.sh
/ventoy/hook/ploplinux
/ventoy/hook/ploplinux/disk_hook.sh
/ventoy/hook/ploplinux/ventoy-hook.sh
/ventoy/hook/cucumber
/ventoy/hook/cucumber/disk-hook.sh
/ventoy/hook/cucumber/ventoy-hook.sh
/ventoy/hook/android
/ventoy/hook/android/ventoy-disk.sh
/ventoy/hook/android/ventoy-hook.sh
/ventoy/hook/photon
/ventoy/hook/photon/ventoy-inotifyd-hook.sh
/ventoy/hook/photon/ventoy-inotifyd-start.sh
/ventoy/hook/photon/ventoy-hook.sh
/ventoy/hook/kiosk
/ventoy/hook/kiosk/ventoy-disk.sh
/ventoy/hook/kiosk/ventoy-hook.sh
/ventoy/hook/arch
/ventoy/hook/arch/ventoy-disk.sh
/ventoy/hook/arch/ventoy-timeout.sh
/ventoy/hook/arch/ventoy-hook.sh
/ventoy/hook/arch/ovios-disk.sh
/ventoy/hook/pmagic
/ventoy/hook/pmagic/disk-hook.sh
/ventoy/hook/pmagic/ventoy-hook.sh
/ventoy/hook/pmagic/udev_disk_hook.sh
/ventoy/hook/mageia
/ventoy/hook/mageia/ventoy-inotifyd-hook.sh
/ventoy/hook/mageia/ventoy-inotifyd-start.sh
/ventoy/hook/mageia/ventoy-hook.sh
/ventoy/hook/gobo
/ventoy/hook/gobo/ventoy-inotifyd-hook.sh
/ventoy/hook/gobo/ventoy-inotifyd-start.sh
/ventoy/hook/gobo/ventoy-hook.sh
/ventoy/hook/pisilinux
/ventoy/hook/pisilinux/ventoy-disk.sh
/ventoy/hook/pisilinux/ventoy-hook.sh
/ventoy/hook/aryalinux
/ventoy/hook/aryalinux/disk_hook.sh
/ventoy/hook/aryalinux/ventoy-hook.sh
/ventoy/hook/dragora
/ventoy/hook/dragora/disk_hook.sh
/ventoy/hook/dragora/ventoy-hook.sh
/ventoy/hook/smgl
/ventoy/hook/smgl/disk_hook.sh
/ventoy/hook/smgl/ventoy-hook.sh
/ventoy/hook/gentoo
/ventoy/hook/gentoo/disk_hook.sh
/ventoy/hook/gentoo/ventoy-hook.sh
/ventoy/hook/openEuler
/ventoy/hook/openEuler/ventoy-timeout.sh
/ventoy/hook/openEuler/ventoy-inotifyd-hook.sh
/ventoy/hook/openEuler/ventoy-make-link.sh
/ventoy/hook/openEuler/ventoy-overlay.sh
/ventoy/hook/openEuler/ventoy-autoexp.sh
/ventoy/hook/openEuler/ventoy-inotifyd-start.sh
/ventoy/hook/openEuler/ventoy-hook.sh
/ventoy/hook/openEuler/ventoy-repo.sh
/ventoy/hook/wifislax
/ventoy/hook/wifislax/disk_hook.sh
/ventoy/hook/wifislax/ventoy-hook.sh
/ventoy/hook/clear
/ventoy/hook/clear/udevadm
/ventoy/hook/clear/hidden-hook.sh
/ventoy/hook/clear/disk-hook.sh
/ventoy/hook/clear/ventoy-hook.sh
/ventoy/hook/phoenixos
/ventoy/hook/phoenixos/disk_hook.sh
/ventoy/hook/phoenixos/ventoy-hook.sh
/ventoy/hook/default
/ventoy/hook/default/ventoy-inotifyd-start.sh
/ventoy/hook/default/13-dm-disk.rules
/ventoy/hook/default/ventoy-hook.sh
/ventoy/hook/default/udev_disk_hook.sh
/ventoy/hook/default/10-dm.rules
/ventoy/hook/default/export.list
/ventoy/hook/default/auto_install_varexp.sh
/ventoy/hook/ventoy-os-lib.sh
/ventoy/hook/pclos
/ventoy/hook/pclos/disk_hook.sh
/ventoy/hook/pclos/ventoy-hook.sh
/ventoy/ventoy_loop.sh
/ventoy/ventoy_chain.sh
/ventoy/log
/ventoy/ventoy_arch
/ventoy/ventoy_os_param
/ventoy/ventoy_image_map
/ventoy/busybox
/ventoy/busybox/inotifyd
/ventoy/busybox/ar
/ventoy/busybox/xzminidec
/ventoy/busybox/xzcat_musl
/ventoy/busybox/zcip
/ventoy/busybox/zcat
/ventoy/busybox/yes
/ventoy/busybox/xzcat
/ventoy/busybox/xz
/ventoy/busybox/xxd
/ventoy/busybox/xargs
/ventoy/busybox/whois
/ventoy/busybox/whoami
/ventoy/busybox/who
/ventoy/busybox/which
/ventoy/busybox/wget
/ventoy/busybox/wc
/ventoy/busybox/watchdog
/ventoy/busybox/watch
/ventoy/busybox/wall
/ventoy/busybox/w
/ventoy/busybox/volname
/ventoy/busybox/vlock
/ventoy/busybox/vi
/ventoy/busybox/vconfig
/ventoy/busybox/uuencode
/ventoy/busybox/uudecode
/ventoy/busybox/usleep
/ventoy/busybox/users
/ventoy/busybox/uptime
/ventoy/busybox/unzip
/ventoy/busybox/unxz
/ventoy/busybox/unshare
/ventoy/busybox/unlzma
/ventoy/busybox/unlink
/ventoy/busybox/unix2dos
/ventoy/busybox/uniq
/ventoy/busybox/unexpand
/ventoy/busybox/uname
/ventoy/busybox/umount
/ventoy/busybox/uevent
/ventoy/busybox/udpsvd
/ventoy/busybox/udhcpd
/ventoy/busybox/udhcpc6
/ventoy/busybox/udhcpc
/ventoy/busybox/ubiupdatevol
/ventoy/busybox/ubirsvol
/ventoy/busybox/ubirmvol
/ventoy/busybox/ubirename
/ventoy/busybox/ubimkvol
/ventoy/busybox/ubidetach
/ventoy/busybox/ubiattach
/ventoy/busybox/tunctl
/ventoy/busybox/ttysize
/ventoy/busybox/tty
/ventoy/busybox/ts
/ventoy/busybox/truncate
/ventoy/busybox/true
/ventoy/busybox/traceroute6
/ventoy/busybox/traceroute
/ventoy/busybox/tr
/ventoy/busybox/touch
/ventoy/busybox/top
/ventoy/busybox/timeout
/ventoy/busybox/time
/ventoy/busybox/tftpd
/ventoy/busybox/tftp
/ventoy/busybox/test
/ventoy/busybox/telnetd
/ventoy/busybox/telnet
/ventoy/busybox/tee
/ventoy/busybox/tcpsvd
/ventoy/busybox/tc
/ventoy/busybox/taskset
/ventoy/busybox/tar
/ventoy/busybox/tail
/ventoy/busybox/tac
/ventoy/busybox/syslogd
/ventoy/busybox/sysctl
/ventoy/busybox/sync
/ventoy/busybox/switch_root
/ventoy/busybox/swapon
/ventoy/busybox/swapoff
/ventoy/busybox/svok
/ventoy/busybox/svlogd
/ventoy/busybox/svc
/ventoy/busybox/sv
/ventoy/busybox/sum
/ventoy/busybox/sulogin
/ventoy/busybox/su
/ventoy/busybox/stty
/ventoy/busybox/strings
/ventoy/busybox/stat
/ventoy/busybox/start-stop-daemon
/ventoy/busybox/ssl_client
/ventoy/busybox/split
/ventoy/busybox/sort
/ventoy/busybox/softlimit
/ventoy/busybox/smemcap
/ventoy/busybox/sleep
/ventoy/busybox/slattach
/ventoy/busybox/shuf
/ventoy/busybox/shred
/ventoy/busybox/showkey
/ventoy/busybox/sha512sum
/ventoy/busybox/sha3sum
/ventoy/busybox/sha256sum
/ventoy/busybox/sha1sum
/ventoy/busybox/sh
/ventoy/busybox/setuidgid
/ventoy/busybox/setsid
/ventoy/busybox/setserial
/ventoy/busybox/setpriv
/ventoy/busybox/setlogcons
/ventoy/busybox/setkeycodes
/ventoy/busybox/setfont
/ventoy/busybox/setfattr
/ventoy/busybox/setconsole
/ventoy/busybox/setarch
/ventoy/busybox/seq
/ventoy/busybox/sendmail
/ventoy/busybox/sed
/ventoy/busybox/scriptreplay
/ventoy/busybox/script
/ventoy/busybox/rx
/ventoy/busybox/runsvdir
/ventoy/busybox/runsv
/ventoy/busybox/runlevel
/ventoy/busybox/run-parts
/ventoy/busybox/run-init
/ventoy/busybox/rtcwake
/ventoy/busybox/rpm2cpio
/ventoy/busybox/rpm
/ventoy/busybox/route
/ventoy/busybox/rmmod
/ventoy/busybox/rmdir
/ventoy/busybox/rm
/ventoy/busybox/rev
/ventoy/busybox/resume
/ventoy/busybox/resize
/ventoy/busybox/reset
/ventoy/busybox/renice
/ventoy/busybox/remove-shell
/ventoy/busybox/reformime
/ventoy/busybox/reboot
/ventoy/busybox/realpath
/ventoy/busybox/readprofile
/ventoy/busybox/readlink
/ventoy/busybox/readahead
/ventoy/busybox/rdev
/ventoy/busybox/rdate
/ventoy/busybox/raidautorun
/ventoy/busybox/pwdx
/ventoy/busybox/pwd
/ventoy/busybox/pstree
/ventoy/busybox/pscan
/ventoy/busybox/ps
/ventoy/busybox/printf
/ventoy/busybox/printenv
/ventoy/busybox/powertop
/ventoy/busybox/poweroff
/ventoy/busybox/popmaildir
/ventoy/busybox/pmap
/ventoy/busybox/pkill
/ventoy/busybox/pivot_root
/ventoy/busybox/pipe_progress
/ventoy/busybox/ping6
/ventoy/busybox/ping
/ventoy/busybox/pidof
/ventoy/busybox/pgrep
/ventoy/busybox/patch
/ventoy/busybox/paste
/ventoy/busybox/passwd
/ventoy/busybox/partprobe
/ventoy/busybox/openvt
/ventoy/busybox/od
/ventoy/busybox/nuke
/ventoy/busybox/ntpd
/ventoy/busybox/nslookup
/ventoy/busybox/nsenter
/ventoy/busybox/nproc
/ventoy/busybox/nologin
/ventoy/busybox/nohup
/ventoy/busybox/nmeter
/ventoy/busybox/nl
/ventoy/busybox/nice
/ventoy/busybox/netstat
/ventoy/busybox/nc
/ventoy/busybox/nbd-client
/ventoy/busybox/nandwrite
/ventoy/busybox/nanddump
/ventoy/busybox/nameif
/ventoy/busybox/mv
/ventoy/busybox/mt
/ventoy/busybox/mpstat
/ventoy/busybox/mountpoint
/ventoy/busybox/mount
/ventoy/busybox/more
/ventoy/busybox/modprobe
/ventoy/busybox/modinfo
/ventoy/busybox/mktemp
/ventoy/busybox/mkswap
/ventoy/busybox/mkpasswd
/ventoy/busybox/mknod
/ventoy/busybox/mkfs.vfat
/ventoy/busybox/mkfs.minix
/ventoy/busybox/mkfs.ext2
/ventoy/busybox/mkfifo
/ventoy/busybox/mke2fs
/ventoy/busybox/mkdosfs
/ventoy/busybox/mkdir
/ventoy/busybox/microcom
/ventoy/busybox/mesg
/ventoy/busybox/mdev
/ventoy/busybox/md5sum
/ventoy/busybox/man
/ventoy/busybox/makemime
/ventoy/busybox/makedevs
/ventoy/busybox/lzop
/ventoy/busybox/lzma
/ventoy/busybox/lzcat
/ventoy/busybox/lsusb
/ventoy/busybox/lsscsi
/ventoy/busybox/lspci
/ventoy/busybox/lsof
/ventoy/busybox/lsmod
/ventoy/busybox/lsattr
/ventoy/busybox/ls
/ventoy/busybox/lpr
/ventoy/busybox/lpq
/ventoy/busybox/lpd
/ventoy/busybox/losetup
/ventoy/busybox/logread
/ventoy/busybox/logname
/ventoy/busybox/login
/ventoy/busybox/logger
/ventoy/busybox/loadkmap
/ventoy/busybox/loadfont
/ventoy/busybox/ln
/ventoy/busybox/linuxrc
/ventoy/busybox/linux64
/ventoy/busybox/linux32
/ventoy/busybox/link
/ventoy/busybox/less
/ventoy/busybox/last
/ventoy/busybox/klogd
/ventoy/busybox/killall5
/ventoy/busybox/killall
/ventoy/busybox/kill
/ventoy/busybox/kbd_mode
/ventoy/busybox/iptunnel
/ventoy/busybox/iprule
/ventoy/busybox/iproute
/ventoy/busybox/ipneigh
/ventoy/busybox/iplink
/ventoy/busybox/ipcs
/ventoy/busybox/ipcrm
/ventoy/busybox/ipcalc
/ventoy/busybox/ipaddr
/ventoy/busybox/ip
/ventoy/busybox/iostat
/ventoy/busybox/ionice
/ventoy/busybox/install
/ventoy/busybox/insmod
/ventoy/busybox/init
/ventoy/busybox/inetd
/ventoy/busybox/ifup
/ventoy/busybox/ifplugd
/ventoy/busybox/ifenslave
/ventoy/busybox/ifdown
/ventoy/busybox/ifconfig
/ventoy/busybox/id
/ventoy/busybox/i2ctransfer
/ventoy/busybox/i2cset
/ventoy/busybox/i2cget
/ventoy/busybox/i2cdump
/ventoy/busybox/i2cdetect
/ventoy/busybox/hwclock
/ventoy/busybox/hush
/ventoy/busybox/httpd
/ventoy/busybox/hostname
/ventoy/busybox/hostid
/ventoy/busybox/hexedit
/ventoy/busybox/hexdump
/ventoy/busybox/head
/ventoy/busybox/hdparm
/ventoy/busybox/hd
/ventoy/busybox/halt
/ventoy/busybox/gzip
/ventoy/busybox/gunzip
/ventoy/busybox/groups
/ventoy/busybox/grep
/ventoy/busybox/getty
/ventoy/busybox/getopt
/ventoy/busybox/fuser
/ventoy/busybox/ftpput
/ventoy/busybox/ftpget
/ventoy/busybox/ftpd
/ventoy/busybox/fsync
/ventoy/busybox/fstrim
/ventoy/busybox/fsfreeze
/ventoy/busybox/fsck.minix
/ventoy/busybox/fsck
/ventoy/busybox/freeramdisk
/ventoy/busybox/free
/ventoy/busybox/fold
/ventoy/busybox/flock
/ventoy/busybox/findfs
/ventoy/busybox/find
/ventoy/busybox/fgrep
/ventoy/busybox/fgconsole
/ventoy/busybox/fdisk
/ventoy/busybox/fdformat
/ventoy/busybox/fdflush
/ventoy/busybox/fbsplash
/ventoy/busybox/fbset
/ventoy/busybox/fatattr
/ventoy/busybox/false
/ventoy/busybox/fallocate
/ventoy/busybox/fakeidentd
/ventoy/busybox/factor
/ventoy/busybox/expr
/ventoy/busybox/expand
/ventoy/busybox/ether-wake
/ventoy/busybox/envuidgid
/ventoy/busybox/envdir
/ventoy/busybox/env
/ventoy/busybox/eject
/ventoy/busybox/egrep
/ventoy/busybox/ed
/ventoy/busybox/echo
/ventoy/busybox/dumpleases
/ventoy/busybox/dumpkmap
/ventoy/busybox/du
/ventoy/busybox/dpkg-deb
/ventoy/busybox/dpkg
/ventoy/busybox/dos2unix
/ventoy/busybox/dnsdomainname
/ventoy/busybox/dnsd
/ventoy/busybox/dmesg
/ventoy/busybox/dirname
/ventoy/busybox/diff
/ventoy/busybox/dhcprelay
/ventoy/busybox/df
/ventoy/busybox/devmem
/ventoy/busybox/depmod
/ventoy/busybox/deluser
/ventoy/busybox/delgroup
/ventoy/busybox/deallocvt
/ventoy/busybox/dd
/ventoy/busybox/dc
/ventoy/busybox/date
/ventoy/busybox/cut
/ventoy/busybox/cttyhack
/ventoy/busybox/cryptpw
/ventoy/busybox/crontab
/ventoy/busybox/crond
/ventoy/busybox/cpio
/ventoy/busybox/cp
/ventoy/busybox/conspy
/ventoy/busybox/comm
/ventoy/busybox/cmp
/ventoy/busybox/clear
/ventoy/busybox/cksum
/ventoy/busybox/chvt
/ventoy/busybox/chrt
/ventoy/busybox/chroot
/ventoy/busybox/chpst
/ventoy/busybox/chpasswd
/ventoy/busybox/chown
/ventoy/busybox/chmod
/ventoy/busybox/chgrp
/ventoy/busybox/chattr
/ventoy/busybox/chat
/ventoy/busybox/cat
/ventoy/busybox/cal
/ventoy/busybox/bzip2
/ventoy/busybox/bzcat
/ventoy/busybox/bunzip2
/ventoy/busybox/brctl
/ventoy/busybox/bootchartd
/ventoy/busybox/blockdev
/ventoy/busybox/blkid
/ventoy/busybox/blkdiscard
/ventoy/busybox/beep
/ventoy/busybox/bc
/ventoy/busybox/basename
/ventoy/busybox/base64
/ventoy/busybox/awk
/ventoy/busybox/arping
/ventoy/busybox/arp
/ventoy/busybox/arch
/ventoy/busybox/adjtimex
/ventoy/busybox/adduser
/ventoy/busybox/addgroup
/ventoy/busybox/add-shell
/ventoy/busybox/acpid
/ventoy/busybox/[[
/ventoy/busybox/[
/ventoy/busybox/busybox
/ventoy/busybox/busybox32.xz
/ventoy/busybox/xzcat32_musl.xz
/ventoy/busybox/xzminidec64_musl
/ventoy/busybox/64h
/ventoy/busybox/xzminidec32
/ventoy/busybox/ash
/ventoy/busybox/xzcat64_musl.xz
/ventoy/busybox/xzminidec64
/ventoy/busybox/busybox64.xz
/ventoy/busybox/vtchmod32
/ventoy/busybox/vtchmod64
/ventoy/busybox/vtchmod64_musl
/ventoy/init_loop
/ventoy/init
/ventoy/init_chain

They don't come from the fedora iso.

[root@localhost-live ~]# lsinitrd /run/initramfs/live/images/pxeboot/initrd.img | grep toy 
[root@localhost-live ~]# 
[root@localhost-live ~]# dmsetup status
live-base: 0 15876096 linear 
live-rw: 0 15876096 snapshot 308368/67108864 1208
ventoy: 0 36384 linear 
ventoy: 36384 260152 linear 
ventoy: 296536 263536 linear 
ventoy: 560072 343264 linear 
ventoy: 903336 419880 linear 
ventoy: 1323216 458360 linear 
ventoy: 1781576 512384 linear 
ventoy: 2293960 542768 linear 
ventoy: 2836728 1263936 linear

hgkamath commented 1 year ago

The below logs come from a vdisk ventoy-boot of Fedora-37. In order to know what the status is in the initramfs, breaked at pre-mount

[root@fedora ~]$ uname -a
Linux sirius 6.1.11-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb  9 19:20:24 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

# rd.break=pre-mount was added to linux cmd line in the grub menu
# the below logs were collected from the initramfs of the vdisk fedora-37 m02_lnx.raw.img.vtoy 
[root@sirius tmp]# cat vtoy3_m02.log
# cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=4096k,nr_inodes=1048576,mode=755,inode64 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,size=3261448k,nr_inodes=819200,mode=755,inode64 0 0
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-sysusers.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
#
# cat /etc/mtab
rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=4096k,nr_inodes=1048576,mode=755,inode64 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,size=3261448k,nr_inodes=819200,mode=755,inode64 0 0
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-sysusers.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
#
# ls -l /etc/mtab
lrwxrwxrwx 1 root root 17 Feb 16 14:59 /etc/mtab -> /proc/self/mounts
#
# ls -l /proc/mounts
lrwxrwxrwx 1 root root 11 Feb 16 14:59 /proc/mounts -> self/mounts
#
# dmsetup status
ventoy: 0 97386496 linear
ventoy1: 0 520192 linear
ventoy2: 0 4096 linear
ventoy3: 0 1572864 linear
ventoy4: 0 95285248 linear
#
# dmsetup ls
ventoy  (253:0)
ventoy1 (253:1)
ventoy2 (253:2)
ventoy3 (253:3)
ventoy4 (253:4)
#
# dmsetup info ventoy
Name:              ventoy
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        4
Event number:      0
Major, minor:      253, 0
Number of targets: 1

#
# dmsetup status -v
Name:              ventoy
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        4
Event number:      0
Major, minor:      253, 0
Number of targets: 1

0 97386496 linear

Name:              ventoy1
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1

0 520192 linear

Name:              ventoy2
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 2
Number of targets: 1

0 4096 linear

Name:              ventoy3
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 3
Number of targets: 1

0 1572864 linear

Name:              ventoy4
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 4
Number of targets: 1

0 95285248 linear

#
# dmsetup table
ventoy: 0 97386496 linear 8:33 1973076888
ventoy1: 0 520192 linear 253:0 2048
ventoy2: 0 4096 linear 253:0 522240
ventoy3: 0 1572864 linear 253:0 526336
ventoy4: 0 95285248 linear 253:0 2099200
#
# dmsetup table -v
Name:              ventoy
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        4
Event number:      0
Major, minor:      253, 0
Number of targets: 1

0 97386496 linear 8:33 1973076888

Name:              ventoy1
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1

0 520192 linear 253:0 2048

Name:              ventoy2
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 2
Number of targets: 1

0 4096 linear 253:0 522240

Name:              ventoy3
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 3
Number of targets: 1

0 1572864 linear 253:0 526336

Name:              ventoy4
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 4
Number of targets: 1

0 95285248 linear 253:0 2099200

#
# ls -l /dev/sdc1
brw-rw---- 1 root disk 8, 33 Feb 16 14:59 /dev/sdc1
#
# ls -l /dev/mapper/ventoy
lrwxrwxrwx 1 root root 7 Feb 16 14:59 /dev/mapper/ventoy -> ../dm-0
#
# ls -l /dev/dm-0
brw-rw---- 1 root disk 253, 0 Feb 16 14:59 /dev/dm-0
#
# cat /proc/cmdline
BOOT_IMAGE=(hd3,gpt3)/vmlinuz-6.1.11-200.fc37.x86_64 root=UUID=27857c40-0518-4c8e-872a-a55bc80c9847 ro rootflags=subvol=root_01 rhgb quiet rd.break=pre-mount
#
# ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 Feb 16 14:59 /dev/sda
#
# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 Feb 16 14:59 /dev/sdb
#
# ls -l /dev/sdc
brw-rw---- 1 root disk 8, 32 Feb 16 14:59 /dev/sdc
#
# cat /proc/devices
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 21 sg
 29 fb
128 ptm
136 pts
180 usb
188 ttyUSB
189 usb_device
202 cpu/msr
203 cpu/cpuid
226 drm
234 megaraid_sas_ioctl
235 megadev_legacy
236 pmcsas
237 nvme-generic
238 nvme
239 uio
240 binder
241 hidraw
242 ttyDBC
243 usbmon
244 wwan_port
245 bsg
246 watchdog
247 ptp
248 pps
249 lirc
250 rtc
251 dma_heap
252 dax
253 tpm
254 gpiochip
509 aux
510 cec
511 aac

Block devices:
  8 sd
  9 md
 11 sr
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
253 device-mapper
254 mdp
259 blkext
#
# mount /dev/sda12 /tmp/a12
#
# cat /proc/mounts | grep a12 -B 3
bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-sysusers.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
/dev/sda12 /tmp/a12 btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
#
# cp /tmp/vtoy3_m02,log /tmp/a12/gana/vtoy3_m02.log
#
# cat /tmp/vtoy.log
ventoy_do_dm_patch
get_addr=0xffffffff92a9f7a0 get_size=496
put_addr=0xffffffff92a9f990 put_size=224
kprobe_reg_addr=ffffffff921ed630 kprobe_unreg_addr=ffffffff921ecc20
ro_addr=ffffffff92089430 rw_addr=ffffffff92089460 printk_addr=0
template module is /lib/modules/6.1.11-200.fc37.x86_64/kernel/fs/zonefs/zonefs.ko.xz zonefs.ko.xz
insmod: ERROR: could not insert module /tmp/dm_patch.ko: Invalid parameters
#
# /usr/bin/vtoydump
=== ventoy runtime data ===
disk name : /dev/sdc
disk size : 2000398934016
disk part : 1
filesystem: ntfs
image size: 49861885952
image path: /transcend/m02_lnx.raw.img.vtoy
#
# dmesg | grep dm
[    0.197961] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
[    1.441071] device-mapper: ioctl: 4.47.0-ioctl (2022-07-28) initialised: dm-devel@redhat.com
[    6.094644] dm_patch: module verification failed: signature and/or required key missing - tainting kernel
[    7.071137] BTRFS: device fsid 27857c40-0518-4c8e-872a-a55bc80c9847 devid 1 transid 7440 /dev/dm-4 scanned by systemd-udevd (656)
#
# dmesg | grep sd
[    1.744888] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    1.745132] sd 0:0:0:0: [sda] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
[    1.745148] sd 0:0:0:0: [sda] Write Protect is off
[    1.745151] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.745184] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.745218] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[    1.753036]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15 sda16 sda17
[    1.753900] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.149445] sd 2:0:0:0: Attached scsi generic sg1 type 0
[    2.149646] sd 2:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[    2.149656] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[    2.149734] sd 2:0:0:0: [sdb] Write Protect is off
[    2.149741] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    2.149844] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.149927] sd 2:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
[    2.150312] sd 4:0:0:0: Attached scsi generic sg2 type 0
[    2.150511] sd 4:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[    2.150542] sd 4:0:0:0: [sdc] 4096-byte physical blocks
[    2.150588] sd 4:0:0:0: [sdc] Write Protect is off
[    2.150596] sd 4:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    2.150652] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.150717] sd 4:0:0:0: [sdc] Preferred minimum I/O size 4096 bytes
[    2.238833]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7
[    2.239285] sd 2:0:0:0: [sdb] Attached SCSI disk
[    2.298831]  sdc: sdc1 sdc2 sdc3 sdc4 sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11
[    2.299987] sd 4:0:0:0: [sdc] Attached SCSI disk
[    3.975488] BTRFS: device fsid 487f55dc-4a7c-4424-9941-352386ecc749 devid 1 transid 230715 /dev/sda9 scanned by systemd-udevd (651)
[    3.979333] BTRFS: device fsid 38d6229a-c049-45df-b6eb-dc254746fb6b devid 1 transid 538 /dev/sda10 scanned by systemd-udevd (641)
[    3.982654] BTRFS: device fsid 3562d3c6-ea67-4e3b-8231-ce6756f4d3bf devid 1 transid 31788 /dev/sda8 scanned by systemd-udevd (640)
[    3.992185] BTRFS: device fsid aaa67901-4412-47cd-b93f-49e758bfc50c devid 1 transid 1060161 /dev/sda12 scanned by systemd-udevd (657)
[    4.707518] BTRFS: device fsid 96fe0ea4-ea54-4a58-925c-c978a9b36e09 devid 1 transid 1147 /dev/sdc7 scanned by systemd-udevd (658)
[    4.769927] BTRFS: device fsid 5c4cc4a0-55a2-4cc7-ae39-e0aada6ba74b devid 1 transid 2493 /dev/sdb4 scanned by systemd-udevd (637)
[ 1230.681698] BTRFS info (device sda12): using crc32c (crc32c-intel) checksum algorithm
[ 1230.681706] BTRFS info (device sda12): disk space caching is enabled
[ 1230.686197] BTRFS info (device sda12): enabling ssd optimizations
[ 1305.232037] BTRFS info (device sda12): using crc32c (crc32c-intel) checksum algorithm
[ 1305.232045] BTRFS info (device sda12): disk space caching is enabled
[ 1305.236469] BTRFS info (device sda12): enabling ssd optimizations
#
# ls -l /sys/firmware/efi/efivars | grep toy
-rw-r--r-- 1 root root  516 Feb 16 14:59 VentoyOsParam-77772020-2e77-6576-6e74-6f792e6e6574
#

# the efivar file that was copied out and this is its hexdump 
# ventoy-grub perhaps uses this to send info to ventoy scripts 
[root@sirius tmp]# cat VentoyOsParam-77772020-2e77-6576-6e74-6f792e6e6574 | od -A x -t x1z -v
000000 06 00 00 00 20 20 77 77 77 2e 76 65 6e 74 6f 79  >....  www.ventoy<
000010 2e 6e 65 74 38 a9 77 92 6c 88 80 4e 3a a0 29 77  >.net8.w.l..N:.)w<
000020 b8 3e 63 06 35 00 60 11 c1 d1 01 00 00 01 00 01  >.>c.5.`.........<
000030 00 2f 74 72 61 6e 73 63 65 6e 64 2f 6d 30 32 5f  >./transcend/m02_<
000040 6c 6e 78 2e 72 61 77 2e 69 6d 67 2e 76 74 6f 79  >lnx.raw.img.vtoy<
000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0001b0 00 00 00 00 9c 0b 00 00 00 00 70 92 9c 00 00 00  >..........p.....<
0001c0 00 2c 00 00 00 00 00 00 00 00 01 00 f3 d9 b6 2d  >.,.............-<
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
0001e0 00 00 00 00 00 f3 d9 b6 2d 00 00 00 00 00 00 00  >........-.......<
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000200 00 00 00 00                                      >....<
000204

hgkamath commented 1 year ago

In this comment, I document

What is native booting
The usefulness of live iso/vdisk multibooting solutions. The reasons for using ventoy
Why being able to mount the outside partition from inside the nativebooted OS is useful
The self-contract to be followed while nativebooted into a vdisk and mounting the outside partition
Windows also does nativeboot and allows write access to outside partition
keeping interoperability with windows

Native booting

In normal OS booting, the OS is directly installed to a partition, and the UEFI transfers control to a bootloader that loads the OS directly from files laid out in a filesystem of a partition. A vdisk is a disk-image format recognized by VMs, such as a raw.img/vhdx/etc. If the OS is inside a vdisk, then when the UEFI transfers control to the bootloader, both the bootloader and OS booting up, should additionally know how read filesystems inside a disk image that itself is on a outer filesystem. Booting an OS in a vdisk image-file on a filesystem this way is termed nativeboot. The vdisks have the advantage of being able to be moved about more easily than partitions.
The disk images themselves are useful to be used with a VM, when not being presently native-booted from..

The usefulness of live iso/vdisk multibooting solutions. The reasons for using ventoy

Dualboot or multiboot is having multiple operating systems on a machine, and being able to boot into them so that booted operating system has full control of the machine. Ventoy's has a base of users who need multibooting solutions. The use case is really important
1a). to those users who dualboot windows/linux, multi boot other OS-es and juggle between them for want of SSD space, 1b). to multiboot alternate OS-es. but have limited on-machine disk-space 2). to mounting different live isos often, like of various linux distributions, which are often re-downloaded due to updates. 3). to those keeping a host of recovery isos-s at hand for emergency like WINRE, WIN-installer, linux-installer, HBCD-PE, gparted, clonezilla, rescuezilla, seabios, samsung-wizard at hand,

Why not a VM?:

VM-s are nice but a bit slower than nativeboot. Many real hardware requiring tasks cannot be done inside a VM. Such as, get full native experience of a live iso, GPU support etc. Some system level recovery and repair tools must be booted as native.

How one arrives at a multiboot solution like ventoy

In the old days Harddisks, USB drives, iso files were small. vdisks were inexistent. One had to burn live-isos to cd/dvd. Disks have grown larger. Burning DVDs is such a waste now.

At one point I considered having a small number of 8GB microsd cards to function just like tiny dvds/floppies. But managing them is also a hassle, as they are stored external.

Disadvantages of flashing USB drive

flashing a USB drive, which say is 32gb, with a tiny <3gb ISO file. can result in it wasting space as it creates a small partition, limiting the drive's usefulness.
One doesn't want too many usb drives lying around to boot different iso-s
In my experience, flashing seems to have a higher frequency of bricking the USB key.

With multiboot solutions, Its much easier to copy in and out liveisos between large filesytems ExFAT, NTFS, ext4 . Linux (as of 6.1) has mature fs driver for ExFAT(5.4) and NTFS (5.15)

I've have tried creating my own grub2 configurations to loop mount isos. but then its too much work to maintain. One has to update grub2 config files everytime one downloads and deletes ISOs. Its preferable, that this is auto-detected or dynamically done.

Then I considered other multiboot solutions like YUMI, Unetbootin, MultiBootUSB, supergrub2

Ventoy seems to best them, by

automatic detection of isos with grub2 menu
also being able to nativeboot vdisks.

Ventoy seems to be fork of grub2 with some additional code to handle the above, and a lot of both grub-scripting and initramfs scripting.

How vdisk based system can be better than partitioning or large single volume systems

Large single volumes, have huge filesystems and can take a long time to repair if there is a disk corruption. In contrast, a vdisk based solution will have one large partition/volume per disk, which in turn contains many reasonably sized vdisks that can be moved about. The vdisks may be of the type that contain a bootble OS ot the type that contain ordinary data. Different-OSes have different space requirements which can be solved more easily by creating a suitably sized vdisk. On the other hand, repartitioning and transferring partitions is problematic.

Another problem with over-partitioned systems for multi-OS machines is free space fragmentation. The limited disk space of a 512gb SSD drive gets broken and underutilized between partitions. This leaves less usable space in a home partition. Filesystems like btrfs allow having one big volume, installing an OS to subvolumes and allow booting from subvolumes. Thereby sharing unused space. One can then backup-up, offload and restoring subvolumes on need. But, this isn't cross platform. Unlike vdisk-files, subvolumes require more mental cognitive involvement. LVM and Proxmox type virtual hosting solutions also do something similar, space management and logistics. Except, only for cloud based virtual machines.

Consider having a windows and linux dual boot sytem and a data partition. One might give 64 gb to each OS. That means when booted into any one OS, the space occupied by the other OS is a waste. Before you know it, there is very little space on the SSD due to all the OS partitions.

Ventoy allows one to just keep only as much as needed 40gb vdisk files in the 512 gb partition, and keep the rest offloaded. The user can easily move all unused vdisk-file images between local disks and to external storage for later use.

Why being able to mount the outside partition from inside the nativebooted OS is useful

The outside partition is large, because it has to contain images.
It may also contain user data, other other virtual disks, and may also have a lot of unused space.
Its best nowadays to have one large volume instead of many small partitions in order to consolidate free space and prevent free space fragmentation.
It is necessary to mount this partition read-write to make good use of the available disk space in it.

There is danger in mounting the outside partition because of the potential to touch/modify the vdisk file in which the nativeboot-ed is running. This danger is mitigated by a self contract.

The self-contract to be followed while nativebooted into a vdisk and mounting the outside partition

Booting into an OS in a vdisk is called nativeboot. If the nativebooted-os wants to mount the outside partition containing the vdisk, there is a little danger that must be mitigated, which is that the fs-entry, file-fragment-locations, filesize of the vdisk file should not be modified. Three safe guards are to be followed by self contract: 1) The virtual-disk-file must be fully-allocated non-sparse and fixed size. It cannot be allowed to grow or shrink. 2) The virtual-disk-file must not be manipulated/touched/read from the host-partition.
3) The filesystem driver shouldn't defrag, scrub or relocate the virtual-disk-file.

This is so that the the file entry in the outside fs remains untouched. This is usually done by an administrative privilege user (root), who knows what the implications are and can set access controls to prevent inadvertent access. So it is not so much of a problem. If one adheres to the above self-contract, the filesystem code for partitions inside the dm-device does not interfere with the filesystem code for the outside partition.

Windows also does nativeboot and allows write access to outside partition

Here, I'm not giving a 'because windows does, linux should do so too', justification. But, windows does do nativeboot of vhdx now since Win10-1903. Only, to mention, that nativebooting vdisks is a useful enough thing, that Microsoft also allows for it. When nativebooted into a VHDX, it is possible to edit files in the outside partition. As is the case for ventoy, the same self contract is to be followed. The vhdx should be fixed-size and not be touched in the hosting drive. They note their common scenarios and benefits. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/deploy-windows-on-a-vhd--native-boot?view=windows-11 I configured a BCDBOOT/BCDEDIT entry to boot a HBCD-PE vhdx this way.

Keeping interoperability with windows

Vdisks also lend themselves to be mounted inside vitual machines. iso9660(.iso) standard read-only file-format meant to be burned onto optical-disks. rawimg, vdi, vdi, vhd, vhdx are common virtual disk file-formats used in VMs. Ventoy can mount iso-s and vhdx. These file-formats can be mounted and not just inside virtual machines but can be mounted directly to the host-OS Linux and Windows using nbd/storport. Vdisk files containing full operating systems are relatively huge (~40GB) compared to DVD/optical-disk isos (<4.7GB). These vdisk formats are stored on large capacity filesystems like ExFAT and NTFS. Both ExFAT and NTFS filesystems now supported by both Linux 6.1 and Windows-10-1903. Both OS can be manged to comply with this system management technique of using vdisk based nativeboot and vdisk based storage. It also allows for easier portability and migration to other machines. If one completely abandoned windows and the need to work with windows machines, there could be other solutions foregoing VM-attachable/host-mountable mountable vdisks. One such example is using btrfs subvolumes, which requires all bootable OS-es to use btrfs. grub2 can boot each individual OS on a btrfs subvolume. But most home users laptops, come with windows, have limited space and getting rid of windows and windows compatible technology completely may not be an option.

hgkamath commented 1 year ago

THE ANTI-VENTOY IDEA

Here-in, I document an idea that just came to me. An alternate way to achieve the same effect of mounting host partition without needing to patch the kernel.

I called it anti-ventoy because a second dm-device is made from all the remaining partition blocks that the dm-device ventoy is not (gravity anti-gravity, proton anti-proton). It's just to give it a name to refer it by in this page. You can call it whatever.

The reason why the host partition can't be mounted is because the dm-mapper has allocated the blocks in it to the dm-device /dev/mapper/ventoy, and can't allocate the entirety of the partition to the filesystem driver. This contention is what prevent mounting the outside partition.

The idea is : What if, in addition to /dev/mapper/ventoy, a second dm-device /dev/mapper/antiventoy of the same size of the host partition /dev/sdc1 is created by stitching together the other remaining blocks of the host partition /dev/sdc1, with the vdisk sectors swapped for with zero blocks. Then the two dm created disks: /dev/mapper/ventoy and /dev/mapper/antiventoy can be mounted independently, without overlap of disk sectors, separating their caching. The self-contract (described in prev comment) will still be needed, to not alter the location/size of fs-entry.

The below logs are collected after the fedora vdisk boots up.

[root@sirius tmp]# cat vtoy4_m02_fedora_postboot.txt
https://www.kernel.org/doc/Documentation/device-mapper/linear.txt
https://www.kernel.org/doc/Documentation/device-mapper/zero.txt

[root@fedora gana]# sgdisk /dev/sdc  -p | grep -i toy
   1            2048      2566852607   1.2 TiB     0700  15KJ_Ventoy
   2      2566852608      2566918143   32.0 MiB    0700  15KJ_VTOYEFI

[root@fedora gana]# dmsetup table
ventoy: 0 97386496 linear 8:33 1973076888
ventoy1: 0 520192 linear 253:0 2048
ventoy2: 0 4096 linear 253:0 522240
ventoy3: 0 1572864 linear 253:0 526336
ventoy4: 0 95285248 linear 253:0 2099200

size of partition
[root@fedora notes]# echo $((2566852607-2048+1))
2566850560
end of vdisk
[root@fedora notes]# echo $((1973076888+97386496))
2070463384
blocks after vdisk
[root@fedora notes]# echo $((2566850560-2070463384))
496387176

[root@fedora ~]# cat  tmp/dmtab_antiventoy
0 1973076888 linear 8:33 0
1973076888  97386496 zero
2070463384 496387176 linear 8:33 2070463384

[root@fedora ~]# cat tmp/dmtab_antiventoy | dmsetup create antiventoy
[root@fedora ~]# dmsetup table
antiventoy: 0 1973076888 linear 8:33 0
antiventoy: 1973076888 97386496 zero
antiventoy: 2070463384 496387176 linear 8:33 2070463384
ventoy: 0 97386496 linear 8:33 1973076888
ventoy1: 0 520192 linear 253:0 2048
ventoy2: 0 4096 linear 253:0 522240
ventoy3: 0 1572864 linear 253:0 526336
ventoy4: 0 95285248 linear 253:0 2099200

[root@fedora ~]# mount -t ntfs3 /dev/mapper/antiventoy /mnt/t1 -o ro
[root@fedora ~]#

[gana@fedora ~]$ ls /mnt/t1
'$RECYCLE.BIN'       HQ                           tmpq        win10inst
 clonezilla          Recovery                     transcend
 DumpStack.log.tmp  'System Volume Information'   ventoy
 freshwin            test                         vstorage

[gana@fedora ~]$ df | grep t1
/dev/mapper/antiventoy 1283425276 1047620704 235804572  82% /mnt/t1

[gana@fedora ~]$ find /mnt/t1 | wc
  23941   24019 1617981

[root@fedora ~]# umount /dev/mapper/antiventoy
[root@fedora ~]#

By side stepping the blocks that were allocated /dev/mapper/ventoy, the contention for was removed, and the new device /dev/mapper/antiventoy was created.

Long ago, I had defragmented the ntfs partition in win10. so the vdisk file is a single contiguous unfragmented sequence of blocks. It would have been more work if it were fragmented but still do-able. ventoy does not require the file to be contiguous. However, I think, contiguous dm-maps are more performant.

Advantages of this method:

The biggest advantage is that that no dm-patching is required. Hence, no kernel taint. /dev/mapper/ventoy gives access to filesystems inside designated-blocks (the location of the file on disk). /dev/mapper/antiventoy gives access to the outside-filesystem.
If inadvertently the vdisk file is read, one will read zero blocks. Additionally, it won't cause suspected problems with disk sector caching by either of the 2 dm-s or by either of the 2 fs-s.
If inadvertently the vdisk file is written, as in case of self-contract violation, it provides a one sided protection to the vdisk file blocks from being written to from the outside filesystem. Whatever data was written is lost into the zero-sectors, and additionally the outside filesystem loses track of vdisk file. Hence, the self-contract should be heeded at all times. Though the situation is bad, it still allows for recovery of vdisk file by dd-ing the blocks out to another filesystem. However, the location of the vdisk blocks do need to be saved beforehand to a 3rd partition, or else one will need to resort to disk-forensics to find the blocks of the vdisk file.
There is no compulsory need for this dm-creation and mounting to happen in the initramfs. After the nativebooted-linux finishes booting up, a logged in user can run a provided script as root, and can create the antiventoy dm and optionally mount the partition at a user-specified mount location.

Disadvantages of this method:

Some would think that making a zero-filled hole in a block device and mounting the filesystem as strange. However, the end effect, the block device as seen by filesystem, is same as a direct filesystem force mount. Same self-contract to be followed. So it is better than dm-patched force mounting of partition.
It introduces a small block translation layer between partition-block-device and filesystem, which can incur a performance hit on throughput. However, this performance loss in my testing is very small and negligible. The purpose of the ventoy partition is to store boot images, common but rarely done operations include downloading, deleting, moving etc of large image files. rather than edit-changes of numerous small-user-files. Hence, the marginal performance reduction is acceptable.

These block boundary calculations need to be perfect, in order to present a filesystem as perfect as the original. The job of the antiventoy dm-map is to just substitute the vdisk file-blocks with zero-blocks, in order to avoid the contention that prevents mount. Some testing will help with assurance of safety. I mounted the fs "ro" to be safe. Don't know what tool I can use to check the sanity of the ntfs filesystem under Linux ntfsck from ntfsprogs was not helpful. It is an incomplete implementation, which, for the moment does nothing.

ventoy commented 1 year ago

The idea is just how Ventoy did to support persistence. https://www.ventoy.net/en/plugin_persistence.html

The ISO file corresponds to /dev/mapper/ventoy ro The persistence data file corresponds to /dev/mapper/vtoy_persistent rw

hgkamath commented 1 year ago

The idea is just how Ventoy did to support persistence.

possibly yes, except that this is the blocks of the whole remaining partition stitched together with zero-block-sections that take the place of the vdisk-blocks.

One needs to get the calculations 100% right. One can't be off by a mistake of even 1 block, or there can be filesystem corruption.
If the vdisk-file is made of 10 fragments, there could be upto 1+10+9+1=21 lines in the antiventoy dm-table.
Its possible in a filesystem for two file fragments to be separated by 0 blocks. If for a file, 2 entries in the fs-tree (MFT$), point to fragments that are side by side, that's apparent contiguous-ness. If the dm-table input can manage a line that specified 0 length, then no problem, otherwise such lines will have to be pruned.
I don't know for sure, but I don't think a file fragment can lie flush-with the edge of the partition boundary as there is bound to be filesystem-metadata, but it won't hurt to watch out for the two edge cases also.
The vdisk file should not be sparse. This applies in general as it should be a fully allocated fixed-vdisk file.
The vdisk file-frags list should be reliable and complete. No blocks belonging to the vdisk file should be left out. No extraneous blocks should be claimed.
The block table will need to be dynamically generated as one can't count on the vdisk-file residing in the same place in the filesystem on each boot, as it could have been moved or modified outside through another OS.
Any block from the partition should be necessarily mapped to be part of either /dev/mapper/ventoy or /dev/mapper/antiventoy, and never of both.
Is there a limit to how many file-fragments there can be? For the table-format of dmsetup, no limit is mentioned in man -s 8 dmsetup

Basic pseudocode algorithm to generate dmtable for antiventoy

# inputs: fragnum, fragstart[], fraglength[], partsize
# local_variable p_offset is always same as s_startblk , so redundant
- s_startblk = 0 ; p_offset = 0 ; fragindex = 0
- loop until fragindex >= fragnum
  - # partition upto next fragment
  - s_length = fragstart[fragindex] - s_startblk
  - dmtabline = "<s_startblk> <s_length> linear <part_identifier> <p_offset>"
  - output dmtabline
  - s_startblk += s_length ; p_offset += s_length    
  - # zero blocks to replace fragment of the vdisk file
  - s_length = fraglength[fragindex]
  - dmtabline = "<s_startblk> <s_length> zero"
  - output dmtabline
  - s_startblk += s_length ; p_offset += s_length   
  - fragindex++ 
- # remainder of partition after last fragment
- s_length = partsize - s_startblk
- dmtabline="<s_startblk> <s_length> linear <part_identifier> <p_offset>"
- output dmtabline

Testing

Much testing will needed just to make sure that a filesystem made this way is safe.
I did run a sha256sum check on all files in the filesystem. Expectedly, the only file that fails is the vdisk-file as it has been replaced by zero sectors. The disk is 1.2 TiB 82% full.

On Linux regular boot

[root@sirius 15KJ_Images]# (IFS="
" ; find . -type f '!' -path ./find.CHECKSUM | xargs -d '\n' -L 100 sha256sum ) | sort -t " " -k 3 > ./find.CHECKSUM

Inside Linux vdisk nativeboot

[root@fedora tmp]# wc -l /mnt/t1/find.CHECKSUM 
23077 /mnt/t1/find.CHECKSUM
[root@fedora tmp]# df | grep t1
/dev/mapper/antiventoy 1283425276 1047623596 235801680  82% /mnt/t1
[root@fedora tmp]# ( date ; cd /mnt/t1 ; sha256sum -c ./find.CHECKSUM --quiet ; date ) | tee /root/tmp/avtest.txt
Sat Feb 18 02:47:04 PM IST 2023  
./transcend/m02_lnx.raw.img.vtoy: FAILED
Sat Feb 18 05:25:48 PM IST 2023
[root@fedora tmp]# 

[root@fedora ~]# ls -l /mnt/t1/transcend/m02_lnx.raw.img.vtoy 
-rwxrwxr-x. 1 gana gana 49861885952 Feb 12 19:18 /mnt/t1/transcend/m02_lnx.raw.img.vtoy
[root@fedora tmp]# #  97386496 is the number of sectors in the zero dmtable section
[root@fedora tmp]# echo $((49861885952/512)) $(((49861885952/512)*512))
97386496 49861885952  
[root@fedora tmp]# # A simple C-program checks if all bytes are null 
[root@fedora tmp]# date ;  ./a.out /mnt/t1/transcend/m02_lnx.raw.img.vtoy ; date
Sat Feb 18 07:15:17 PM IST 2023
All zeros: length:49861885952
Sat Feb 18 07:18:41 PM IST 2023
[root@fedora tmp]# 

[root@fedora tmp]# filefrag -v /mnt/t1/transcend/m02_lnx.raw.img.vtoy
Filesystem type is: 7366746e
File size of /mnt/t1/transcend/m02_lnx.raw.img.vtoy is 49861885952 (12173312 blocks of 4096 bytes)
ext:     logical_offset:        physical_offset: length:   expected: flags:
 0:        0..12173311:  246634611.. 258807922: 12173312:             last,merged,eof
/mnt/t1/transcend/m02_lnx.raw.img.vtoy: 1 extent found
[root@fedora tmp]# echo $((12173312*8)) # 8 * 512 = 4096 there are eight blocks per ntfs block
97386496
[root@fedora tmp]# filefrag -v /mnt/t1/transcend/m02_lnx.raw.img.vtoy -b512
Filesystem type is: 7366746e
File size of /mnt/t1/transcend/m02_lnx.raw.img.vtoy is 49861885952 (97386496 blocks of 512 bytes)
ext:     logical_offset:        physical_offset: length:   expected: flags:
 0:        0..97386495: 1973076888..2070463383: 97386496:             last,merged,eof
/mnt/t1/transcend/m02_lnx.raw.img.vtoy: 1 extent found
[root@fedora tmp]#

I also wanted to mount the filesystem as read-write, but before that I wanted to be sure that my calculations are correct.

In test like these, there is the possibility that the mount might will succeed, just because most of the filesystem metadata is near the start of the partition, away from the vdisk-file. So its necessary to check that the blocks zeroed are precisely only those that correspond to the vdisk-file.

I don't know if there is way to do this in Linux. but if the vdisk file can be exclusively locked after mount, and be made to remain exclusively locked until shutdown, so that no entity can attempt to move/modify the vdisk-file, after mounting /dev/mapper/antiventoy, it would improve safety. Creating the antiventoy dmmap, mounting and file-locking can all be command options of a script.

ventoy commented 1 year ago

Try the latest CI release: https://github.com/ventoy/Ventoy/actions/runs/4219907971 https://www.ventoy.net/en/doc_github_ci.html

ventoy / Ventoy