How to boot from a "virtual usb stick" instead of a read only ISO file ?

[shodan]

Hi,

I often have a similar problem to this.

I need to modify my boot ISO before installing it.

I have an ISO file that I would upload into proxmox.

But on a baremetal computer, I would use rufus to write it to a usb stick.

On this usb stick, I believe in "hybrid" mode ? ?

I can then add/remove/modify files on this usb stick.

However it is very difficult to do this with an ISO file.

I have done it, but figuring how to unpack and rebuild a working ISO has always been a big chore.

So I am curious, what kind of file, other than an ISO, I could easily mount and modify, could I use in place of an ISO in proxmox ?



What I'm imagining now is to burn a usb stick using rufus, then create a lvm block device of the same size, dd that usb stick to the lvm block device and then add this as a scsi hdd to the VM ?

This is still very cumbersome !

Would it even work ?

Is there a better way ?

 

[mkoeppl]

Hi!

What exactly do you want to modify? Depending on what you want to do, you might be able to use the autoinstall assistant to achieve that. Through the answer file, you can pre-configure parts of PVE and then use proxmox-auto-install-assistant prepare-iso to receive a modified ISO file.
Hope I'm not misinterpreting your intent.

 

[leesteken]

Maybe this thread can help: https://forum.proxmox.com/threads/virtual-pendrive-on-vm.114143/

 

[LnxBil]

On this usb stick, I believe in "hybrid" mode ? ?

This does normally only apply to the bootloader, which is then a hybrid of iso9660-compliant boot loader and a normal BIOS-based bootloader. UEFI is independent of this, it just uses oridnary files.

Tools like Rufus either copy the iso file 1:1 to the disk, which will result in an read only boot stick (filesystem is still iso9660) or copying the files to the already present non-iso9660 filesystem, which works for UEFI-based systems. In the later case, you can add/change/remove files, but not in the former.

Depending on the changes you want to do, (re)mastering iso images is one way to go. We do this regularly but it's heavily scripted and integrated in CI. In other setups we use just a "response" file that sits on the network. This works great for Linux-based systems, haven't done this with Windows for a while. Back in the days there was the winnt.sif ...

 

[shodan]

Ok, so I gave this a try

First in rufus, I made this a EFI boot usb



Then I tried like this

root@proxmox:~# dd if=/dev/sdb of=/mnt/winiso/winusb.img bs=4M status=progress
15100+0 records in
15100+0 records out
63333990400 bytes (63 GB, 59 GiB) copied, 539.049 s, 117 MB/s
root@proxmox:~# cd /mnt/winiso/
root@proxmox:/mnt/winiso# ls
lost+found  template  winusb.img
root@proxmox:/mnt/winiso# losetup -fP /mnt/winiso/winusb.img
root@proxmox:/mnt/winiso# mkdir winusb
root@proxmox:/mnt/winiso# mount /dev/loop
loop-control  loop0         loop0p1       loop0p2       loop1         loop2         loop3         loop4         loop5         loop6         loop7
root@proxmox:/mnt/winiso# mount /dev/loop0p1 winusb
root@proxmox:/mnt/winiso# ls winusb
'$WinPeDriver$'  'System Volume Information'   autorun.inf   autounattend.xml   boot   bootmgr   bootmgr.efi   efi   info.txt   setup.exe   sources   support
root@proxmox:/mnt/winiso# ls winusb/sources/*.wim
winusb/sources/boot.wim  winusb/sources/install.wim
root@proxmox:/mnt/winiso# mkdir winsource
root@proxmox:/mnt/winiso# mount //shodan.lan/guest winsource -t cifs -o username=guest
root@proxmox:/mnt/winiso# ls winsource/*.wim
winsource/windows.backup.wim
root@proxmox:/mnt/winiso# cp winsource/windows.backup.wim winusb/sources/install.wim
root@proxmox:/mnt/winiso# umount winusb
root@proxmox:/mnt/winiso# umount winsource
root@proxmox:/mnt/winiso# losetup -d /dev/loop0
root@proxmox:/mnt/winiso# qemu-img convert -f raw -O qcow2 winusb.img winusb.qcow2
root@proxmox:/mnt/winiso# ls
images  lost+found  template  winsource  winusb  winusb.img  winusb.qcow2
root@proxmox:/mnt/winiso# qm importdisk 108 /mnt/winiso/winusb.qcow2 local-lvm
importing disk '/mnt/winiso/winusb.qcow2' to VM 108 ...
  WARNING: You have not turned on protection against thin pools running out of space.
  WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
  Logical volume "vm-108-disk-0" created.
  WARNING: Sum of all thin volume sizes (1.09 TiB) exceeds the size of thin pool pve/data and the size of whole volume group (<446.13 GiB).
transferred 0.0 B of 59.0 GiB (0.00%)
transferred 604.0 MiB of 59.0 GiB (1.00%)
transferred 59.0 GiB of 59.0 GiB (100.00%)
unused0: successfully imported disk 'local-lvm:vm-108-disk-0'

then I attached the drive in the web interface



And that works, as far as I can tell




Things I have remarked

1. converting to qcow2, did not recover all the empty space, it still uses the full 64GB as far as I can tell



2. The usb stick, even loaded as an "unused" image, is attached to a particular VM and I don't know how I can let VM 109 use it
3. I'm not sure there is a way to use this virtual usb stick in read only mode
4. I'm not sure more than one VM can install from it at the same time
5. qm import was very slow
6. There is nowhere in the interface, when creating a VM, to attach the virtual usb drive




I will try this method again, this time I will try to run qm import against /dev/sdb directly, skipping the "dd" / qcow2 convert parts entirely, I will then mount the new disk as a regular LVM volume, make the modification, and then try the installation again

 

[guruevi]

A USB drive is just a regular hard drive, so theoretically you can attach a virtual disk to one VM, disconnect and reattach to another VM and that will have the same ‘result’ as a USB drive. Booting is done with a boot loader, totally irrelevant to the media you use. Other variants people use is PXE booting or Ventoy, which gives you great control over what you want to boot without having to do all the ISO making. Linux and Windows do have other methods of distribution that give you great flexibility.