189 replies to this topic

[ventoy]

What commands do I need to use to install that package so that /boot/grub/i386-pc/  modules appear ?

 

What I did so far is not sufficient

 

KALI_grub-pc_2021-01-25_071408.jpg

 

dpkg -i is enough.  /boot/grub/i386-pc is not needed, vtoyboot.sh will copy them.

You have installed the package, so now you just need to re-run the vtoyboot.sh. 

This time there will not be a warning message.

Edited by ventoy, 25 January 2021 - 08:06 AM.

[wimb]

dpkg -i is enough.  /boot/grub/i386-pc is not needed, vtoyboot.sh will copy them.

You have installed the package, so now you just need to re-run the vtoyboot.sh. 

This time there will not be a warning message.

 

Succes !!  Thank you for your help 

 

KALI.vdi.vtoy is booting in MBR BIOS mode from USB SSD using vdiskchain

 

[wimb]

I useSuper-UEFIinSecureBoot-Disk_minimal_v3.zip , download it and dd the diskimg to a USB drive and boot to its embedded grub with secure boot. And then chainloader vdiskchain and it boot fine. (I only test it on VMware with secure boot. My laptop is old and doesn't support secure boot)

 

In real life booting from USB SSD in UEFI Secure mode using Super UEFI grubx64.efi and Super UEFI grub2 system in \EFI\grub\x86_64-efi does not work for me.

 

I am still getting Secure Boot conflict with KALI internal /boot/grub/x86_64-efi/normal.mod

 

Anyway for KAL Linux I can always make use in UEFI Secure mode booting from RAMDISK with kali-linux-2020.3-live-amd64.iso

 

renamed to kali-linux.iso in folder images and using Mint UEFI Secure booting is working OK .....

 

a1ive Grub2 2020-08-26 of UEFI_MULTI-50 supports booting \iso\kali-linux-2020.3-live-amd64.iso from RAMDISK using Linux GLIM menu

a1ive Grub2 2021-01-04 of UEFI_MULTI-55 does NOT support booting \iso\kali-linux-2020.3-live-amd64.iso from RAMDISK using Linux GLIM menu  - systemd-udevd unsigned problem

[ventoy]

In real life booting from USB SSD in UEFI Secure mode using Super UEFI grubx64.efi and Super UEFI grub2 system in \EFI\grub\x86_64-efi does not work for me.

 

I am still getting Secure Boot conflict with KALI internal /boot/grub/x86_64-efi/normal.mod

 

I think it's because Kali doesn't support Secure Boot itself. If your secure boot is enabled, you can boot Kali iso.

Kali doesn't contain a shim but Ubuntu does.

[wimb]

I think it's because Kali doesn't support Secure Boot itself. If your secure boot is enabled, you can boot Kali iso.

Kali doesn't contain a shim but Ubuntu does.

 

Yes I think that is the real reason.

Kali doesn't contain shim and does Not support Secure Boot.

[ventoy]

Yes I think that is the real reason.

Kali doesn't contain shim and does Not support Secure Boot.

 

I test it in VMware. If secure boot is enabled, Kali.vdi.vtoy will not boot, if secure boot is disabled, then Kali.vdi.vtoy will boot fine.

I will add a secureboot=off option for vdiskchain in the next release. If you want or just want to make a try, you can add this option like follows:

chainloader /grub/vdiskchain vdisk=/KALI.vdi.vtoy secureboot=off

[ventoy]

In real life booting from USB SSD in UEFI Secure mode using Super UEFI grubx64.efi and Super UEFI grub2 system in \EFI\grub\x86_64-efi does not work for me.

 

I am still getting Secure Boot conflict with KALI internal /boot/grub/x86_64-efi/normal.mod

 

Anyway for KAL Linux I can always make use in UEFI Secure mode booting from RAMDISK with kali-linux-2020.3-live-amd64.iso

 

renamed to kali-linux.iso in folder images and using Mint UEFI Secure booting is working OK .....

 

a1ive Grub2 2020-08-26 of UEFI_MULTI-50 supports booting \iso\kali-linux-2020.3-live-amd64.iso from RAMDISK using Linux GLIM menu

a1ive Grub2 2021-01-04 of UEFI_MULTI-55 does NOT support booting \iso\kali-linux-2020.3-live-amd64.iso from RAMDISK using Linux GLIM menu  - systemd-udevd unsigned problem

 

The bootx64.efi and the kernel in kali-linux-2020.3-live-amd64.iso are both unsigned.

So if you can boot into its grub menu with secure boot. That means the secure boot policy has been hooked to load and run the unsigned bootx64.efi file. But that is not enough, there is a SecureBoot uefi variable in the firmware. If the grub detects that this variable exist and the value is 1, then it will check the kernel's signature when boot. So it will report that the vmlinuz is not signed and failed to boot.

 

So if you can boot fine for kali-linux-2020.3-live-amd64.iso with secure boot enabled. That means the secure boot policy has been hooked, and at the same time the SecureBoot uefi variable has been hooked too.

 

You can chainloader vdiskchain (at least it print something) that means the secure boot policy has been hooked because vdiskchain is not signed.

secureboot=off option is just to hook the SecureBoot uefi variable.

[wimb]

Thank you for interesting description.

 

Can we also learn something from the fact that some versions of a1ive Grub2 can be used in the Super UEFI > a1ive Grub2 > kali-linux iso chain,

whereas latest version of a1ive Grub2 fails in such boot chain.

 

More info on UEFI Secure booting with UEFI_MULTI using

 

Super UEFI > shim > a1ive Grub2 > Grub2 Menu > GLIM Menu > kali-linux-2020.3-live-amd64.iso in iso folder on FAT32 USB SSD Boot Drive

 

BOOTX64.EFI > grubx64.efi > grubx64_real.efi > /grub/grub.cfg  > GRUB Live ISO Multiboot

 

========================================================================================

 

With the very special BOOTx64.EFI and grubx64.efi of Linux Mint 15-05-2018 I can haver UEFI Secure boot support for kali-linux.iso in a very simple way

In this case there is no shim and no Mok Manager needed and still the UEFI Secure boot chain is not broken.

But there is use of a limited number of modules allowed. We cannot use regexp.mod as being used in GLIM main.cfg

 

Linux Mint > Linux Mint Grub2 > Grub2 Menu

 

BOOTx64.EFI > grubx64.efi > /Boot/grub/grub.cfg Menu > kali-linux.iso in images folder on FAT32 USB SSD Boot Drive

[wimb]

 

I test it in VMware. If secure boot is enabled, Kali.vdi.vtoy will not boot, if secure boot is disabled, then Kali.vdi.vtoy will boot fine.

I will add a secureboot=off option for vdiskchain in the next release. If you want or just want to make a try, you can add this option like follows:

chainloader /grub/vdiskchain vdisk=/KALI.vdi.vtoy secureboot=off

 

Such option secureboot=off in viskchain will be quite useful   May be a1ive Grub2 can have similar option ?    

 

As I understand it allows UEFI Secure boot without the need to modify UEFI BIOS Settings.

 

It will make things a lot easier in booting from USB SSD in UEFI Secure mode on Unknown computer,

 

which is the condition of real life, where you don't want to make changes in UEFI BIOS Settings of foreign computer.

[ventoy]

Such option secureboot=off in viskchain will be quite useful   May be a1ive Grub2 can have similar option ?    

 

As I understand it allows UEFI Secure boot without the need to modify UEFI BIOS Settings.

 

It will make things a lot easier in booting from USB SSD in UEFI Secure mode on Unknown computer,

 

which is the condition of real life, where you don't want to make changes in UEFI BIOS Settings of foreign computer.

 

There is a sbpolicy module in a1ive grub2.  Make this module embedded by default when you make grubx64.efi.

fucksb -i
fucksb -n

This will do the samething with  secureboot=off option.

Edited by ventoy, 26 January 2021 - 10:32 AM.

[wimb]

There is a sbpolicy module in a1ive grub2.  Make this module embedded by default when you make grubx64.efi.

fucksb -i
fucksb -n

This will do the samething with  secureboot=off option.

 

That is very good news.    Will test and report about it.

[wimb]

There is a sbpolicy module in a1ive grub2.  Make this module embedded by default when you make grubx64.efi.

fucksb -i
fucksb -n

This will do the samething with  secureboot=off option.

 

 

Great Succes        Thanks to ventoy and a1ive   

 

Using these fucksb commands in grub.cfg solves the issue. 

 

Now both UEFI Secure and MBR BIOS mode booting of KALI.vdi.vtoy using vdiskchain are working OK 

 

if [ "${grub_platform}" == "efi" ]; then
  if [ -e (hd0,msdos2)/KALI.vdi.vtoy ]; then
    menuentry "(hd0,msdos2)/KALI.vdi.vtoy - /grub/vdiskchain" {
      chainloader /grub/vdiskchain vdisk=/KALI.vdi.vtoy
    }
  fi
else
  if [ -e (hd0,msdos2)/KALI.vdi.vtoy ]; then
    menuentry "(hd0,msdos2)/KALI.vdi.vtoy - /grub/vdiskchain" {
      linux16  /grub/ipxe.krn vdisk=/KALI.vdi.vtoy
      initrd16 /grub/vdiskchain
    }
  fi
fi

[ventoy]

 

Screenshot_2021-01-26_13-09-20.png

 

Great Succes        Thanks to ventoy and a1ive   

 

Using these fucksb commands in grub.cfg solves the issue. 

 

Now both UEFI Secure and MBR BIOS mode booting of KALI.vdi.vtoy using vdiskchain are working OK 

 

if [ "${grub_platform}" == "efi" ]; then
  if [ -e (hd0,msdos2)/KALI.vdi.vtoy ]; then
    menuentry "(hd0,msdos2)/KALI.vdi.vtoy - /grub/vdiskchain" {
      chainloader /grub/vdiskchain vdisk=/KALI.vdi.vtoy
    }
  fi
else
  if [ -e (hd0,msdos2)/KALI.vdi.vtoy ]; then
    menuentry "(hd0,msdos2)/KALI.vdi.vtoy - /grub/vdiskchain" {
      linux16  /grub/ipxe.krn vdisk=/KALI.vdi.vtoy
      initrd16 /grub/vdiskchain
    }
  fi
fi

 

 

I have released vdiskchain 1.2  https://github.com/v...leases/tag/v1.2

You can try the secureboot=off option

[wimb]

I have released vdiskchain 1.2  https://github.com/v...leases/tag/v1.2

You can try the secureboot=off option

 

Thank you for new version vdiskchain 1.2 

 

secureboot=off option is working OK and allows booting KALI.vdi.vtoy using vdiskchain    

 

[alacran]

JFYI

 

This is the first time I boot my Linux-Mint.vhd.vtoy (20 GB), and I'm writting this post from it, It was made from: linuxmint-20.1-cinnamon-64bit.iso

 

Booted as MBR from first HD, using MBR grub4dos and following entry on menu.lst located on the root of first primary partition of first HD, or (hd0,0) according to MBR grub4dos:

 

title Linux-Mint.vhd.vtoy - /grub/vdiskchain
kernel /grub/ipxe.krn vdisk=/Linux-Mint.vhd.vtoy
initrd /grub/vdiskchain

Linux-Mint.vhd.vtoy is located on the root of first logical partition of first HD, or (hd0,4) according to MBR grub4dos.

 

Next I will try to boot it as UEFI, and also will copy it to a USB device and try it on another PC, to see if it boots also fine on it.

 

Unfortunately a 20GB VHD is not something we can really call Portable.

 

@ ventoy

 

Thanks for your vdiskchain 1.2, it's working very fine.

 

Also I have a question: Is Porteus capable to boot as Porteus.vhd.vtoy? I know it is not on your list on: https://www.ventoy.n...n_vtoyboot.html, but I better ask as maybe you haven't tested it.

 

In fact I'm looking for a distro that could be installed on a let's say 5 GB VHD (or less), any suggestion?

Or even better how we can know if a distro uses dracut/initramfstool/mkinitcpio to build initramfs?

 

alacran

[ventoy]

JFYI

 

This is the first time I boot my Linux-Mint.vhd.vtoy (20 GB), and I'm writting this post from it, It was made from: linuxmint-20.1-cinnamon-64bit.iso

 

Booted as MBR from first HD, using MBR grub4dos and following entry on menu.lst located on the root of first primary partition of first HD, or (hd0,0) according to MBR grub4dos:

 

title Linux-Mint.vhd.vtoy - /grub/vdiskchain
kernel /grub/ipxe.krn vdisk=/Linux-Mint.vhd.vtoy
initrd /grub/vdiskchain

Linux-Mint.vhd.vtoy is located on the root of first logical partition of first HD, or (hd0,4) according to MBR grub4dos.

 

Next I will try to boot it as UEFI, and also will copy it to a USB device and try it on another PC, to see if it boots also fine on it.

 

Unfortunately a 20GB VHD is not something we can really call Portable.

 

@ ventoy

 

Thanks for your vdiskchain 1.2, it's working very fine.

 

Also I have a question: Is Porteus capable to boot as Porteus.vhd.vtoy? I know it is not on your list on: https://www.ventoy.n...n_vtoyboot.html, but I better ask as maybe you haven't tested it.

 

In fact I'm looking for a distro that could be installed on a let's say 5 GB VHD (or less), any suggestion?

Or even better how we can know if a distro uses dracut/initramfstool/mkinitcpio to build initramfs?

 

alacran

 

Yes. Porteus is not tested, but high possibility not supported.

 

dracut will be a valid command if the system use it as initramfstool. So as update-initramfs  and mkinitcpio

 

vtoyboot.sh use these script to check whether the system :

vtoyboot/distros/dracut/check.sh
vtoyboot/distros/initramfstool/check.sh
vtoyboot/distros/mkinitcpio/check.sh

In my thought, Linux VHD/VDI is put in the local disk.  For portable, ISO+persistence is better.

[alacran]

JFYI

 

My Linux-Mint.vhd.vtoy (20 GB) booted very fine as UEFI on same PC.

 

It also booted very fine as MBR on another PC, it recognized all the different hardware without any issue.

 

As said its size is not really portable, but after using 7-zip it was compressed to Linux-Mint.vhd.7z (1.79 GB) for easy transport it on a USB stick, and latter expanded on its new location.

 

In fact I'm writing this post from it on this new location.

 

alacran

[antonino61]

no linux lz4 or gz equivalents or algo por el estilo?

[wimb]

As said its size is not really portable, but after using 7-zip it was compressed to Linux-Mint.vhd.7z (1.9 GB) for easy transport it on a USB stick, and latter expanded on its new location.

 

 

Interesting to reduce storage size of Linux-Mint.vhd.vtoy by using 7-zip compression.

 

What 7-zip Settings do you use ?

[antonino61]

well, semi-interesting, as it wants uncompacting (or uncompressing, for that matter) back again in its operational target location.

[alacran]

no linux lz4 or gz equivalents or algo por el estilo?

 

No, so far the VHD.vtoy needs to be decompressed on the new location, and I also checked it was contiguous using Wincontig, just in case.

 

Interesting to reduce storage size of Linux-Mint.vhd.vtoy by using 7-zip compression.

 

What 7-zip Settings do you use ?

 

I used Max compression, 1.79 GB compressed size is 9 % of original size, but this is useful only for easy transport it on a USB stick, from one PC to another.

 

alacran

[alacran]

As it is a little complicated for non advanced users of Linux (as myself) to have access to shared folders under VirtualBox, I made vtoyboot-1.0.8.iso (1.25 MB), which is easier to attach as a virtual CD/DVD.

 

To make things easier for future readers I'm going to share it here as vtoyboot-1.0.8.7z, just decompress it and attach the ISO to the VM, boot the Linux.vhd, on VirtualBox, copy vtoyboot-1.0.8 folder to your Documents folder on the running VHD, and run it from that location.

 

Into vtoyboot-1.0.8 folder you will find a Readme.txt file with instructions to run vtoyboot.sh as root from the running VHD.

Hope this can be of some use for some of you.

 

alacran

Attached Files

•  vtoyboot-1.0.8.7z   407.58KB   258 downloads

[alacran]

JFYI

 

Hi, I'm writing this from my Linux-Lite.vhd.vtoy, made from linux-lite-5.0-64bit.iso (1.3 GB), it fits on a 10 GB VHD and still has 2.3 GB free.  As another derivative of Ubuntu like Linux-Mint, it is also able to be loaded by grub4dos (as MBR) and by Ventoy or a1ive's grub2 (as MBR or UEFI), by means of vtoyboot-1.0.8 + vdiskchain 1.2, just booted it now as MBR, haven't tested to boot as UEFI yet, but it was installed and booting fine as UEFI on VirtualBox.

 

I could not say we can compare this size with the size of my Mini-10x64.vhd (2.3 GB), but at least it is easier to handle than my Linux-Mint.vhd.vtoy (20 GB).

 

If compressed with 7-zip (Max.) for easy transport it, the final size is about 1.63 GB. Of course to boot it is required to decompress it on the final location.

 

alacran

[alacran]

For those as my good friend antonino61 that are looking for a smaller and/or portable Linux distro easy to install and capable to boot from a USB device as MBR/CSM and/or UEFI, the best option is PuppyLinux slacko64-7.0.iso (343 MB), just released on Jan/2021, the official page is: http://slacko7.eezy.xyz/

 

As all the good old Puppy Linux versions easier way to install is create a FAT-32 partition on our USB device or internal HD and just extact the ISO content on it, or at least the following files:

 

fdrv_slacko64_7.0.sfs
initrd.gz
puppy_slacko64_7.0.sfs
vmlinuz
zdrv_slacko64_7.0.sfs

 

And boot it as MBR/CSM by means of MBR grub4dos using the following entry on menu.lst:

 

title Boot slacko64-7.0\nRuns Puppy Linux Slacko64-7.0 from a partition on USB device
find --set-root /puppy_slacko64_7.0.sfs
kernel /vmlinuz pmedia=usbflash
initrd /initrd.gz

title Boot slacko64-7.0\nRuns Puppy Linux Slacko64-7.0 from a partition on internal HD
find --set-root /puppy_slacko64_7.0.sfs
kernel /vmlinuz pmedia=ataflash
initrd /initrd.gz

 

The first time we boot from it, when we turn off the OS it lets us create a persistence file to save there all changes we have done.

 

It can also be installed/extracted into a folder located on a partition of our USB device or internal HD, for more info see the included README.txt located into the ISO and just edit previous menu.lst entries as required.

 

Also the PuppyLinux slacko64-7.0.iso can be booted from Ventoy, see: https://www.ventoy.n...tro_iso/33.html    

Haven't tested this yet, so I don't know if booting the ISO file with Ventoy we are able to create a persistence file.

 

This new version which is also capable to run on UEFI environment has integrated several frugal installers too, see: http://www.fishprogs...lpup/index.html

 

And better read the linked page carefully to avoid overwrite your EFI (FAT-32) partition on the internal HD:

 

Warning:
When using FrugalPup or DiskPup to install Puppy on a uefi computer with Windows already installed, it is not recommended to install Grub2 on the fat32 partition that contains the Windows boot. Grub2 should be installed on the first partition of some other bootable device, even if that is a small USB stick.

 

alacran

[antonino61]

thank u ever so much alacrán, I will delve into it as soon as possible and let you know. this "sounds" like some achievement in the linux terrain.