search

puppylinux-woof-CE / woof-CE

woof - the Puppy builder
GNU General Public License v2.0
393 stars 282 forks source link

Support MOK's in Puppy with 'mokutil' - a helper utility for MOK Manager #1882

Closed gyrog closed 3 years ago

gyrog commented 3 years ago

Now that we can have uefi Puppies that use MOK's, it's probably a good idea if Puppy supports a utility that helps managing MOK's, i.e. 'mokutil'.

'mokutil' provides facilities to display, delete, clear, export and import keys on your machine. Although it doesn't change anything in real time, it makes requests to the actual MOK Manager to act on during the next boot. It's quite useful for cleaning out obselete MOK's.

'mokutil' depends on another utility called 'efivar'.

So how do we get 'mokutil' working on Puppy?

If it's a upup, no problem just install the 'efivar' and 'mokutil' packages via PPM. This would probably work for dpup's as well.

If it's an spup, there's a problem, the PPM doesn't know about these packages. I tried this in both ScPup64 and eslacko64. Fortunately for ScPup64, I found an 'efivar' package called 'efivar-20191015_ca85d51-x86_64-1.txz' on https://pkgs.org/download/efivar that works, but no 'mokutil' package. So I compiled one into 'mokutil-20201024-x86_64.pet' and this also works. Unfortunately I haven't been able to obtain a working 'efivar' for eslacko64.

The whole area is confused becaue there are 2 methods for Linux to access the efi-variables, the deprecated method activated by "CONFIG_EFI_VARS", and a new method using a pseudo-filesystem 'efivarfs', activated by "CONFIG_EFIVAR_FS". Apparently it is recommended that only 1 of these should be enabled in any kernel compile. So I compiled kernel 5.4.72 (64bit) with a go at minimal EFI configs being set, the kernel works in ScPup64 and so does 'mokutil'. Here are the only "EFI" configs I set : CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_EFI_ESRT=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_UEFI_CPER=y CONFIG_UEFI_CPER_X86=y CONFIG_EFI_DEV_PATH_PARSER=y CONFIG_EFI_PARTITION=y CONFIG_FB_EFI=y CONFIG_EFIVAR_FS=m (Sorry @peabee, you may need to consider more config changes for your next kernel compile.)

There is one more thing needed for the new 'efivar', it needs a particular mount command during boot: mount -t efivarfs none /sys/firmware/efi/efivars so I wrote a little script called 'efivarfs' that is suitable for inclusion in '/etc/init.d'.

I have uploaded 'efivar-20191015_ca85d51-x86_64-1.txz', 'mokutil-20201024-x86_64.pet' and 'efivarfs' files to http://www.mediafire.com/folder/00irfyzi4ghio/mokutil . Note on 'efivarfs': The 'executable' permission gets lost with the upload/download cycle.

Note: There is an 'efivar' package for "Slackware 14.2", 'efivar-31-x86_64-1_slonly.txz', but it doesn't work on eslacko64. (Neither does the 'efivar-20191015_ca85d51-x86_64-1.txz' package.)

gyrog commented 3 years ago

FYI, I changed kernels in fossapup64 to my new 5.4.72(64bit) kernel, and 'efivar' and 'mokutil' both work fine. ('efivar' and 'mokutil' installed via PPM.)

peabee commented 3 years ago

Is this just for 64bit systems?

gyrog commented 3 years ago

I haven't tried any 32bit systems, yet. Although I suspect that the kernel config only doing 1 'efivar' method would still make sense, and the 'efivarfs' method is preferred.

I've started with 64bit systems because:

  1. Some times I've seen the assumption that "uefi" implies 64bit.
  2. 32bit sysems may be a vanishing breed.
  3. And I wanted to get to a point where we had at least some "normal" Puppies that could run 'mokutil', since it's easy to have multiple Puppy frugal installs. So if you had to choose 1 Puppy from a subset, to manage your MOK's, that's better than having to say "install a major Live CD, e.g. Fedora or Debian, or Ubuntu."
CollaboratorGCM commented 3 years ago

There isn't enough hours in the day to continue to build for 32bit systems. 64bit systems have been mainstream from manufacturers for about 15 years with a "blip" only occurring when there was a shortage and manufacturers fill with the brief intro of Netbooks. Since then, NO x86 Manufacturer has bothered to repeat that mistake.

Developers time is precious, IMHO!

gyrog commented 3 years ago

I've had no luck with bionicpup32, after a number of kernel compiles with varying configs, no go. So no more.

ScPup64: With my 5.4.72-gyro-64 kernel, '/etc/init.d/efivarfs' works 'efivar' from PPM, works 'mokutil' from my 'mokutil-20201024-x86_64.pet', works. BUt another efi utility 'efibootmgr' from PPM, does not work, and compiing the source fails. So ScPup64 is ok for playing with MOK's, but not for changing the efi boot preference order.

Fossapup64: With both the release kernel, and my 5.4.72-gyro-64 kernel, '/etc/init.d/efivarfs' works 'efivar' from PPM, works 'mokutil' from PPM, works and 'efibootmgr' from PPM, works. So Fossapup64 provides the most complete support for efi utilities.

Note: Looking at 'efibootmgr' we may be able to have FrugalPup install to the windows ESP and then use 'efibootmgr' to modify the efi boot order so that grub2 runs in preference to windows, with grub2 configured to also boot windows. (The current FrugalPup, clobbers files, not directories, so there is a good chance that it would add to the windows ESP, without clobbering any Windows stuff, because they are in different directories. But I've never tried it. The current warnings in FrugalPup are there because it's completely unknown territory. I need to sortout a test efi machine, with an efi windows install, to try some of this stuff.)

FYI, I've uploaded a slightly improved /etc/init.d/efivarfs script, although it still does exactly the same thing.

gyrog commented 3 years ago

My wonderful working fossapup64, didn't work at all on my "nasty" Lenevo Ideapad 100s. It's "nasty" because it is a 64bit cpu but it boots 32bit Windows via 32bit uefi, and it has the most limited "uefi/bios" I've ever seen, on it's motherboard. So I recompiled kernel 5.4.72-gyro-64, with the extra config "CONFIG_EFI_MIXED=y" and it worked, at last a Puppy that can run the efi utilities, on a "range of hardware". I've uploaded this kernel 5.4.72-gyro-64.

01micko commented 3 years ago

There is an efivar slackbuild. Only need to install 'pkgtools' from PPM to build it. https://slackbuilds.org/repository/14.2/libraries/efivar/

Ok, so it works but I've no idea what to do with it! I can list MOKs anyway. (stock slacko64 atm with slightly different kernel to what I put in eslacko - 5.4.77 --- I had the CONFIG_EFIVARS AND EFIVARFS so disabled the former )

BTW: latest mokutil wouldn't build. I've an old source that does so should do the job for slacko based on 14.2. I'll post that source to ibiblio/sources/m/ later

gyrog commented 3 years ago

Eventually you will need it to clean-out old MOK's, key's usually have a "used by" date. You need 'mokutil' for that, but it depends on 'efivar'.

My intention is to make available Puppies that can do this, if stock-standard ones don't. I'm happy to have 1 now, but it would be nice to have more than 1. (Before this i had to use a "Live Fedora" or "Live Debian" stick.)

I'm currently in the "shutdownconfig" rabbit-hole, but I'll get back to this, hopefully soon.

CollaboratorGCM commented 3 years ago

I recognized the importance of this effort.

I would like those who are following this, to ALSO consider WoofCE PUPs generated without GRUB2 utilities built in. And, those new PUPs should have Menu reflecting the presence of GRUB2. Right now, that is NOT present.

I think WoofCE recognizes the need for this update.

01micko commented 3 years ago

mokutil will be in the next iteration of eslacko64

As will sbsigntools > devx

Kernels are updated. 5.4.80 is built with very similar options to @gyrog 's config a few posts up - including CONFIG_EFI_MIXED=y

Now, is there any point mounting efivarsfs if secure boot is turned off?

# mokutil --sb-state
SecureBoot enabled

I want to refine the init.d script in the pet posted earlier.

BTW - the source I used for mokutil - https://distro.ibiblio.org/puppylinux/sources/m/mokutil-0.4.0.tar.xz

gyrog commented 3 years ago

Now, is there any point mounting efivarsfs if secure boot is turned off?

# mokutil --sb-state
SecureBoot enabled

Yes. I think it's a catch22 situation, it efivarfs is not mounted then mokutil can't tell you anything.

01micko commented 3 years ago

Hmmm efivarfs is causing a kernel crash for me on my ryzen box at shutdown. I can't figure out how to umount the mountpoint cleanly either - busybox mount nor mount-FULL, both segfault and crash the system.

Haven't seen anything on my dell laptop. Works ok I think on that.

gyrog commented 3 years ago

I have not seen this problem in any of my testing, so I have no suggestions. My testing was all done on an "Intel i3". I have never tried to "umount" efivarfs.

Hmm.., could this be a "Slackware" issue, could you push this upstream??

I do remember putting "Slacko" into my "too-hard" basket for this stuff.

01micko commented 3 years ago

Hmm.., could this be a "Slackware" issue, could you push this upstream??

Possibly but I only have a -current install (not 14.2)

I'll try Linux 5.9.11 first.

EDIT: 5.9.11 exhibits the same issue... but I can't blame slackware just yet, or the kernel. There is a god awful bug (few of them actually) in /etc/rc.d/rc.shutdown. I don't know how any machine can shutdown cleanly using a save folder. A save file on NTFS doesn't dismount cleanly either but that is a different bug. I have known about this bug for a little while but it has only been exhibited on my fast machine so I thought it was a quirk of that, and only in slacko (most recent builds) and fossa - not bionic or previous. Take a look at this log I captured (but shouldn't have if the mount -t aufs did it's thing correctly - well if the syntax in the code was correct and the code mounted the thing ro - can't blame aufs)

 debug
killall: X: no process killed
killall: X: no process killed
1
command: busybox fuser -m /initrd/mnt/dev_save 2>>~/debug.log | tr -d 'm'
f*ck
1 /pup_rw
mount-FULL: wrong fs type, bad option, bad superblock on /,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
mount: mounting / on / failed: Resource busy
3
umount-FULL: /initrd/mnt/dev_save: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
4
umount-FULL: /: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
umount-FULL: /initrd/mnt/tmpfs: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
umount-FULL: /initrd/mnt/dev_save: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
/dev/sda5 on /initrd/mnt/dev_save type ext4 (rw,noatime)
tmpfs on /initrd/mnt/tmpfs type tmpfs (rw,relatime)
unionfs on / type aufs (rw,relatime,si=cdb83b6169b74637)
/dev/loop0 on /initrd/pup_ro2 type squashfs (ro,noatime)
/dev/loop1 on /initrd/pup_f type squashfs (ro,noatime)
/dev/loop2 on /initrd/pup_z type squashfs (ro,noatime)
devtmpfs on /dev type devtmpfs (ro,relatime,size=8160004k,nr_inodes=2040001,mode=755)
none on /proc type proc (rw,relatime)
none on /dev/pts type devpts (rw,relatime,gid=2,mode=620,ptmxmode=000)
none on /sys type sysfs (rw,relatime)
/dev/loop3 on /initrd/pup_ro3 type squashfs (ro,noatime)
/dev/loop4 on /initrd/pup_ro4 type squashfs (ro,noatime)
/dev/loop5 on /initrd/pup_ro5 type squashfs (ro,noatime)
/dev/loop6 on /initrd/pup_ro6 type squashfs (ro,noatime)
/dev/loop7 on /initrd/pup_ro7 type squashfs (ro,noatime)
/dev/loop8 on /initrd/pup_ro8 type squashfs (ro,noatime)

.. and yes the wildcard is letter u

gyrog commented 3 years ago

I've been distracted from Puppy for a while now, but I'm sortof getting back to it now.

I hope to re-visit this whole "efi" utilities area before too long.

gyrog commented 3 years ago

I now have a test machine that runs fully uefi, "CSM" disabled, "Secure Boot" enabled, and using only GPT partitioned disks. Using Fossapup64, confirmed my previous testing, no problems using the utilities from PPM. I then tried 'dpupbuster64-8.0.0-uefi-RC-3-09082020.iso', again utilities from PPM worked fine. Though in both cases I used one of my "gyro" kernels from last year, that have the "mmc" and "efi" support I worked out then.

One interesting thing, was that dpupbuster64 had no efi utilities built-in, unlike Fossapup64, (efivar and efibootmgr), but installing only "mokutil" and "efibootmgr" packages from PPM worked, though each installed a "lib" as well. I did not have to install the 'efivar' package. So maybe we need to include only those 2 packages (and dependencies) in future puppies.

We definately need "mokutil" since Puppy sometimes enrolls MOK's.

"efibootmgr" might be interesting, if I can get a 'uefi' install of Windows on an internal drive of this test machine. and then see what happens when I use FrugalPup to install a Puppy grub2 on the same ESP (EFI System Partition).

Note: I'm still focusing on only 64bit Puppies that have both "mokutil" and "efibootmgr" available as packages in PPM.

CollaboratorGCM commented 3 years ago

A gamechanger improvement to 2021 PUPs, going forward. Thx.

01micko commented 3 years ago

I'll just leave the Slackware - current eliloconfig script here for ideas - note that elilo and lilo work totally differently to grub2

#!/bin/sh
# Copyright 2013, 2016, 2017  Patrick Volkerding, Sebeka, Minnesota, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#

# This script installs the elilo boot loader, the kernel, and optionally
# an initrd into the EFI System Partition.  A boot menu entry can also be
# installed using efibootmgr.  The kernel used will be whatever the symlink
# /boot/vmlinuz points to, and if /boot/initrd.gz exists, that will be 
# installed as the initrd.
#
# The EFI System Partition is expected to be mounted on /boot/efi before
# running this script.

TMP=/var/log/setup/tmp

# Set the OS root directory (called T_PX for some unknown reason).
# If an argument is given to this script and it is a directory, it
# is taken to be the root directory.  First though, we check for a
# directory named $T_PX, and that gets the first priority.
if [ ! -d "$T_PX" ]; then
  if [ ! "$1" = "" ]; then
    if [ -d "$1" ]; then
      T_PX="$1"
    fi
  else
    # Are we on the installer image?
    if [ -r /usr/lib/setup/SeTpartitions ]; then
      T_PX=/mnt
    # Or, are we on a running system?
    elif [ -r /etc/slackware-version ]; then
      T_PX=/
    # One more installer-likely thing:
    elif [ -r /usr/lib/setup/setup ]; then
      T_PX=/mnt
    else
      # We will have to assume we're on an installed and running system.
      T_PX=/
    fi
  fi
fi

# Determine the root partition (such as /dev/sda1)
ROOT_DEVICE=$2
if [ "$ROOT_DEVICE" = "" ]; then
 if [ -r $TMP/SeTrootdev ]; then
  ROOT_DEVICE="$(cat $TMP/SeTrootdev)"
 else
  ROOT_DEVICE="$(mount | grep ' / ' | cut -f 1 -d ' ' | head -n 1)"
 fi
fi

# If the system is not running under EFI, skip running this script:
if [ ! -d /sys/firmware/efi ]; then
  if [ "$T_PX" = "/" ]; then
    echo "ERROR:  System is not running under UEFI."
  fi
  exit
fi

# If there's no vfat mounted on /boot/efi or $T_PX/boot/efi, forget it:
if ! mount | grep vfat | grep -wq /boot/efi ; then
  if ! mount | grep vfat | grep -wq $T_PX/boot/efi ; then
    if [ "$T_PX" = "/" ]; then
      echo "ERROR:  No EFI System Partition mounted on /boot/efi."
    fi
    exit
  fi
fi

# Figure out the device and partition number of the ESP:
DEVLEN=8
PARTLEN=9
if mount | grep vfat | grep -wq /boot/efi ; then
  mount | grep vfat | grep -w /boot/efi | grep -q -e nvme -e mmcblk && DEVLEN=12 && PARTLEN=14
  EFI_DEVICE=$(mount | grep vfat | grep -w /boot/efi | cut -b 1-${DEVLEN})
  EFI_PARTITION=$(mount | grep vfat | grep -w /boot/efi | cut -f 1 -d ' ' | cut -b ${PARTLEN}- | sed 's/[^0-9]*//g')
else
  mount | grep vfat | grep -w $T_PX/boot/efi | grep -q -e nvme -e mmcblk && DEVLEN=12 && PARTLEN=14
  EFI_DEVICE=$(mount | grep vfat | grep -w $T_PX/boot/efi | cut -b 1-${DEVLEN})
  EFI_PARTITION=$(mount | grep vfat | grep -w $T_PX/boot/efi | cut -f 1 -d ' ' | cut -b ${PARTLEN}- | sed 's/[^0-9]*//g')
fi

# There better be a kernel:
if [ ! -r $T_PX/boot/vmlinuz ]; then
  if [ "$T_PX" = "/" ]; then
    echo "ERROR:  No kernel found at /boot/vmlinuz."
  fi
  exit
fi

dialog --title "INSTALL ELILO" \
--backtitle "ELILO (EFI Linux Loader) installation" \
--menu "ELILO is a Linux boot loader for \
EFI based systems.  Installing ELILO will allow you to boot your Linux \
system from the hard drive after selecting it from the UEFI boot menu.  \
Since an EFI System Partition was detected on this machine, it is \
recommended that you install ELILO now.  Please select an option:" \
13 70 2 \
"install" "Install ELILO on the EFI System Partition" \
"skip" "Do not install ELILO" 2> $TMP/reply
if [ $? = 1 -o $? = 255 ]; then
  exit
fi
REPLY="`cat $TMP/reply`"
rm -f $TMP/reply
if [ "$REPLY" = "skip" ]; then
  exit
fi

mkdir -p $T_PX/boot/efi/EFI/Slackware 1> /dev/null 2> /dev/null
cat << EOF > $T_PX/boot/efi/EFI/Slackware/elilo.conf
chooser=simple
delay=1
timeout=1
#
EOF
cp -a $T_PX/boot/elilo-x86_64.efi $T_PX/boot/efi/EFI/Slackware/elilo.efi 1> /dev/null 2> /dev/null
if [ -r $T_PX/boot/initrd.gz ]; then
  cp $T_PX/boot/vmlinuz-generic $T_PX/boot/efi/EFI/Slackware/vmlinuz 1> /dev/null 2> /dev/null
  touch -r $T_PX/boot/vmlinuz-generic $T_PX/boot/efi/EFI/Slackware/vmlinuz
  cp $T_PX/boot/initrd.gz $T_PX/boot/efi/EFI/Slackware 1> /dev/null 2> /dev/null
  touch -r $T_PX/boot/initrd.gz $T_PX/boot/efi/EFI/Slackware/initrd.gz
  cat << EOF >> $T_PX/boot/efi/EFI/Slackware/elilo.conf
image=vmlinuz
        label=vmlinuz
        initrd=initrd.gz
EOF
else
  cp $T_PX/boot/vmlinuz-huge $T_PX/boot/efi/EFI/Slackware/vmlinuz 1> /dev/null 2> /dev/null
  touch -r $T_PX/boot/vmlinuz-huge $T_PX/boot/efi/EFI/Slackware/vmlinuz
  cat << EOF >> $T_PX/boot/efi/EFI/Slackware/elilo.conf
image=vmlinuz
        label=vmlinuz
EOF
fi
cat << EOF >> $T_PX/boot/efi/EFI/Slackware/elilo.conf
        read-only
        append="root=$ROOT_DEVICE vga=normal ro"
EOF

dialog --title "INSTALL BOOT MENU ENTRY?" \
--backtitle "ELILO (EFI Linux Loader) installation" \
--menu "Would you like to install \
a boot menu entry so that you can easily select Slackware when you boot your \
machine?  WARNING:  DO NOT install a boot menu entry on Apple hardware.  \
Apple computers use a different type of EFI firmware, and efibootmgr has \
been known to damage them.  On all other computers, it is recommended to add \
a boot menu entry.  Please select an option:" \
14 70 2 \
"install" "Install a boot menu entry" \
"skip" "Do not install a boot menu entry" 2> $TMP/reply
if [ $? = 1 -o $? = 255 ]; then
  exit
fi
REPLY="`cat $TMP/reply`"
rm -f $TMP/reply
if [ "$REPLY" = "skip" ]; then
  exit
fi

if [ ! -d /sys/firmware/efi/vars ]; then
  modprobe efivars 1> /dev/null 2> /dev/null
  sleep 1 # Probably not needed, but playing it safe
fi
# If it's still gone, we fail silently:
if [ ! -d /sys/firmware/efi/vars ]; then
  exit
fi

efibootmgr -v | rev | cut -f 2- | rev | grep Boot0 | grep Slackware | while read line ; do
  # Reject entries that don't exactly match as not our business
  if [ ! "$(echo $line | cut -f 2- -d ' ')" = "Slackware" ]; then
    continue
  fi
  ENTRY="$(efibootmgr -v | grep "^$(echo $line | cut -b1-8)")"
  dialog --title "REMOVE OLD \"Slackware\" EFI BOOT ENTRY?" \
  --backtitle "ELILO (EFI Linux Loader) installation" \
  --yesno "An old Slackware boot entry has been found in your EFI boot menu. \
Would you like to remove this before installing the new Slackware boot \
entry?  This is recommended.\n\nOld EFI boot menu entry:\n$ENTRY" 13 70
  if [ ! $? = 0 ]; then
    continue
  fi
  # Remove the boot entry:
  efibootmgr -q -B -b $(echo $line | cut -b5-8)
  sleep 1
done

efibootmgr -q -c -d $EFI_DEVICE -p $EFI_PARTITION -l "\\EFI\\Slackware\\elilo.efi" -L "Slackware"
sleep 1

efibootmgr -v | rev | cut -f 2- | rev | grep Boot0 | grep Slackware | while read line ; do
  # Reject entries that don't exactly match as not our business
  if [ ! "$(echo $line | cut -f 2- -d ' ')" = "Slackware" ]; then
    continue
  fi
  ENTRY="$(efibootmgr -v | grep "^$(echo $line | cut -b1-8)")"
  if echo $ENTRY | grep -q -F "\EFI\Slackware\elilo.efi" ; then
  dialog --title "EFI BOOT ENTRY INSTALLED" \
  --backtitle "ELILO (EFI Linux Loader) installation" \
  --msgbox "A Slackware boot entry has been installed to your EFI boot
menu.\n\nEFI boot menu entry:\n$ENTRY" 11 70
  fi
done

# Done.
gyrog commented 3 years ago

The critical line is: efibootmgr -q -c -d $EFI_DEVICE -p $EFI_PARTITION -l "\EFI\Slackware\elilo.efi" -L "Slackware" which adds an entry called "Slackware" into the uefi/BIOS boot order, (I think). And there would have to be an '/EFI/Slackware/elilo.efi' file in a "fat32" partition which this entry causes to be executed at boot time.

With "efibootmgr" we have access to something which is sort of like the old BIOS boot order. But now we can modify this boot order with a program in the running system. So, we endup with a multi-boot facility "within" the uefi/BIOS. i.e. you see these entries by activating the "Boot Menu" of the uefi/BIOS.

Theoretically we could do a similar thing by moving all our '/EFI/boot/*' files to '/EFI/PuppyLinux/' and using 'efibootmgr' to add a boot entry ("\EFI\PuppyLinux\bootx64.efi") called "PuppyLinux" to the boot order. (Actually to be more exact about what's going on we could call it "Grub2", except for the signed "shim" whose public key is in 'puppy.cer'). (Also might have to do either 32bit or 64bit, not both). Hmm... an interesting thing to try some time.

I'm not sure this method makes it very convenient, since you often have to do "odd" things to activate the "Boot Menu". But it may be that would be different if we atually added a "named" ('/EFI/name/') boot entry like the eliloconfig script, instead of using the "default" '/EFI/boot/' directory.

I wouldn't want to install a separate "entry" for each Puppy I install, I think I would prefer to keep my large Grub2 menu.

The other problem is that this ties the install directly to the particular machine, not very helpful for a USB stick you can plug into any machine.

Although it would mean there is almost no chance that we could do any large overwrite destruction by using FrugalPup to install to even a Windows ESP partition.

O, I finally had a chance to see what pappens when you use FrugalPup to install Grub2 to a Windows ESP. And the result is, not much. The only file overwritten was '/EFI/boot/bootx64.efi' which did not stop Windows from starting to boot. The down side was that by default it continued to boot Windows.

01micko commented 3 years ago

The critical line is: efibootmgr -q -c -d $EFI_DEVICE -p $EFI_PARTITION -l "\EFI\Slackware\elilo.efi" -L "Slackware" which adds an entry called "Slackware" into the uefi/BIOS boot order, (I think). And there would have to be an '/EFI/Slackware/elilo.efi' file in a "fat32" partition which this entry causes to be executed at boot time.

Yes. I have slackware64 -current installed on my dell laptop.

With "efibootmgr" we have access to something which is sort of like the old BIOS boot order. But now we can modify this boot order with a program in the running system. So, we endup with a multi-boot facility "within" the uefi/BIOS. i.e. you see these entries by activating the "Boot Menu" of the uefi/BIOS.

Yes

Theoretically we could do a similar thing by moving all our '/EFI/boot/*' files to '/EFI/PuppyLinux/' and using 'efibootmgr' to add a boot entry ("\EFI\PuppyLinux\bootx64.efi") called "PuppyLinux" to the boot order. (Actually to be more exact about what's going on we could call it "Grub2", except for the signed "shim" whose public key is in 'puppy.cer'). (Also might have to do either 32bit or 64bit, not both). Hmm... an interesting thing to try some time.

I think 64 would be preferable. 32 is mostly for legacy machines and if a user must run it on modern kit nearly all processors support KVM so virtualbox/qemu/vmware would be an acceptable option.

I'm not sure this method makes it very convenient, since you often have to do "odd" things to activate the "Boot Menu". But it may be that would be different if we atually added a "named" ('/EFI/name/') boot entry like the eliloconfig script, instead of using the "default" '/EFI/boot/' directory.

I wouldn't want to install a separate "entry" for each Puppy I install, I think I would prefer to keep my large Grub2 menu.

Absolutely, let grub handle multiple pups

The other problem is that this ties the install directly to the particular machine, not very helpful for a USB stick you can plug into any machine.

Non-issue I think. As long as the MOK is registered most machines allow booting off external media by pressing a 'hot' key, either ESC, DEL, F10, F12 or something as you know. No need.

Although it would mean there is almost no chance that we could do any large overwrite destruction by using FrugalPup to install to even a Windows ESP partition.

O, I finally had a chance to see what pappens when you use FrugalPup to install Grub2 to a Windows ESP. And the result is, not much. The only file overwritten was '/EFI/boot/bootx64.efi' which did not stop Windows from starting to boot. The down side was that by default it continued to boot Windows.

That's a start.

gyrog commented 3 years ago

The problem with 'efibootmgr' "installing" a "PuppyLinux" boot to the uefiBIOS, is not that you can't activate the "BootMenu" for this device, the problem is that no other machine will recognise the 'EFI/PuppyLinux' directory as a boot option until 'efibootmgr' is run to "install" it on this machine.

The current method works because the 'EFI/boot' directory is supposed to be recognised as a "default boot", by every uefi/BIOS. But with my proposed method, the '/EFI/boot' directory remains untouched, by FrugalPup.

gyrog commented 3 years ago

I have setup an f2StickPup style Puppy install modified to uses 'EFI/PuppyLinux' instead of '/EFI/boot'. Simply booting it doesn't work because the uefi/BIOS in the motherboard, doesn't find the 'bootx64.efi' file. But after installing 'EFI/Puppy/bootx64.efi' to the uefi/BIOS using 'efibootmgr', it boots.

All I need now is a working uefi Windows install, and I might be able to dual boot Windows and Puppy (well Windows and Grub2) using uefi, via the Windows ESP, (and a working 'efibootmgr'). Which means we could have a FrugalPup->Boot facility that can install Grub2 to the Windows ESP and achieve something that might be useful.

I've found that efi boot stuff has a "timeout", which is normally 0. I can change this using 'efibootmgr', and I hope that if I can get to a situation with 2 "installed" efi boots, setting the 'timeout' to a non-zero value will cause a menu to he shown.

gyrog commented 3 years ago

Well, it works. In a Windows ESP, I've stored the uefi stuff that FrugalPup usually installs in '/EFI/boot' in '/EFI/Puppy'. Then ran a 'config-efiboot' script (I wrote) that uses 'efibootmgr' to add a boot called "Puppy" to the ueif/BIOS boot list. (The scrip borrows the 'efibootmgr' usage from the Slackware script.) And even after a shutdown, you can boot either grub or Windows.

Unfortunately setting the "timeout=5" did not automatically produce a menu on boot. I still have to do an "activate Boot Menu" trick, to get a boot menu to displayed to choose the other boot, i.e. Windows. Although this behaviour could vary with the uefi/BIOS implementation.

I'll continue playing with it, I need to try calling the label of the boot, "Puppy Linux" instead of just "Puppy", it would look better in the menu.

So, now we need to work out what we want to do with this technology. My first option is to get FrugalPup to use it when it discovers that the user is trying to install grub to a Windows ESP. Of course one of the challanges is, to make full use of it we need a working 'efibootmgr' in every Puppy.

gyrog commented 3 years ago

I now have a boot label of "Puppy Linux - Grub2", and it still works fine.

gyrog commented 3 years ago

FYI, the output from a "efibootmgr" on my test machine.

BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000,0001 Boot0000 Puppy Linux - Grub2 Boot0001 Windows Boot Manager

gyrog commented 3 years ago

I've uploaded my 'config-efiboot' utility to mediafire.

01micko commented 3 years ago

Something interesting...

The slackware install on my linux box died recently. I was booting it from frugalpup's grub2 menu (hacked it in) and it was fine for months. Anyway, I deleted it and downloaded a fresh slackware64 current iso and am now installing it.

When I ran 'setup' it insisted that I had an efi system but didn't have an EFI boot partition of type EF00. Indeed grub2 is installed on a normal FAT partition. So I nuked that and am continuing to install Slackware.. I'll deal with the fallout later.

gyrog commented 3 years ago

I haven't found a uefi/BIOS yet that insists on an EFI boot partition being of type EF00. They have all been quite happy with a fat32 partition with an 'EFI' directory in it's root. And on at least 1 of them, it seemed to take longer to find the EFI boot partition on a "gpt" disk than on an ordinary old "msdos" disk, (although the mchine is a few years old). On my current main machine, a usb stick doesn't even need any flags set either. We're at the mercy of the mother-board manufacturers.

01micko commented 3 years ago

Well well well.. the fallout wasn't so bad :smiley: (bear in mind there is no trace of Windows on this box)

So the upshot of this report is that it works without windows and just have to use the UEFI-BIOS boot menu in lieu of presence of windows

gyrog commented 3 years ago

@01micko, Excellent news.

On my copy of 'config-efiboot' lines 19 and 20 are supposed to be a bit of insurance against 'efibootmgr' executing but producing only error messges.

I assume that Slackware has a '/EFI/slackware' directory, (or something like that). Correct?? The code I'm working on for 'FrugalPup' is triggered by the existence of anything other than '/EFI/boot', so it will co-operate with the major Linux distributions as well as Windows.

Thanks for reminding me that the major Linux distributions also use their own efi boot directory, so I don't need to have a fresh uefi install of Windows to test FrugalPup against, a uefi install of a major Linux will do.

So, which is the major Linux distribution that generates a '/EFI/mylinux' directory in the boot partition with a uefi install, is quickest to install and smallest to download? If I choose Slackware, what file should I download?

gyrog commented 3 years ago

I've uploaded a new version of 'config-efiboot' to http://www.mediafire.com/folder/00irfyzi4ghio/mokutil The testing for 'efibootmgr' is more straight forward.

01micko commented 3 years ago

Slackware is huge.

Maybe something like mx-linux? peppermint-os? Something CD sized.

Yes there is /EFI/Slackware

gyrog commented 3 years ago

Yes, I thought there would be an '/EFI/Slackware'.

Actually I'm going to try Devuan Beowulf "desktop-live", even though it's 1.2GiB. I've only played with it "live" and already I'm sick of "sudo", but it looks to have 'efibootmgr' and 'mokutil', so I'm hoping a uefi install to a HD will produce the uefi boot partition I need. Then I can test that the new FrugalPup will automatically do what you have done manually.

01micko commented 3 years ago

sudo is annoying. Slackware has su - (where the dash ensures you are in root environment`). Shame Salix (slackware spin off) isn't up to date yet.

I have another Dell dev box (has win10, various puppies, MBR boot but capable of UEFI) that I might wipe for testing and enable EFI after backing up what I need. I've not booted win10 on it since I bought it (over 2 years ago). I could install ubuntu or fedora or even debian. Debian is probably a good choice because you can grab a very small install image and add a window manager and all dependencies are downloaded (did that with raspbian on pi4).

Then I can test whatever you come up with.

I also have an HP ElitePad 1000 G2 tablet that boots off sd/mmc but is read only so not really usable (BIOS bug for Linux - there's a fix but I can't be bothered). However I did add frugalpup to the sdcard to boot and made a 10GB partition to install slacko64-7.0 on the emmc drive. That setup works satisfactorily. It would be better if I could install Grub2 to the EFI partion and not bother with the sdcard. So there is a windows capable test bed too.

gyrog commented 3 years ago

Great, then you might be able to give this thing a reasonable test.

I did manage to get 'devuan' installed and it has a '/EFI/devuan', so I can use it for my initial testing, (later today). I've only got FrugalPup to the "copy files to an appropriate place" stage, it doesn't have any 'efibootmgr' stuff in it yet. Doing the 'efibootmgr' call is still only in 'config-efiboot'. My aim is for the "FrugalPup->Boot" facility to do it all, once it finds some "other" in '/EFI'.

But thinking of the 'efibootmgr' stuff that I should integrate into FrugalPup, I'm thinking we should probably check if there is already a "Puppy" entry there, and remove it (like the slackwarescript does)?

gyrog commented 3 years ago

I've uploaded a new version of 'config-efiboot' to http://www.mediafire.com/folder/00irfyzi4ghio/mokutil. It now contains code to delete any existing "Puppy Linux" boot entry, (untested).

My test using "Devuan" worked fine. After installing Puppy with my current test FrugalPup and then running 'config-efiboot', the machine rebooted into Puppy as the top of the boot order, but "Devuan" still booted when selected via the uefi/BIOS "Boot Menu".

So I'll integrate the 'efibootmgr' code from 'config-efiboot' and then make FrugalPup v27 available.

gyrog commented 3 years ago

I've uploaded 'frugalpup_27.sfs' and 'frugalpup-27.pet' to http://www.mediafire.com/folder/rdyc5lgzpeij1/frugalpup (2.9 MiB).

Consider this a beta release, I expect there will be a bug-fix v28 release to follow.

This FrugalPup's "Boot" facility now stores the ".efi" files to '/EFI/Puppy' instead of '/EFI/boot', if it detects the presence of another installation. It also does the 'efibootmgr' thing to delete any old Puppy boot, and then register the new 'Puppy Linux - Grub2' boot.

I tested against an install of Devuan, both installing when only the 'devuan' entry was present, and replacing the 'Puppy Linux - Grub2' when both boots were registered. They both worked, fine. First reboot got me into the Puppy grub2 menu. Although it is slightly possible that the "replace" case did absolutely nothing because the "before" and "after" situations are identical. Oh, and Devuan was still bootable via the uefi/BIOS "Boot Menu".

I like the way 'efibootmgr' places the new boot at the front of the boot order, so on reboot yo come right back to what you are doing.

I used a Fossapup64 patched to be up-to-date with the current 'init-experiment' branch, and my kernel "5.4.72-gyro-64", as a Puppy with a known working 'efibootmgr'.

peabee commented 3 years ago

Consider this a beta release, I expect there will be a bug-fix v28 release to follow.

Will await v28 before uploading to noarch ............... ??

gyrog commented 3 years ago

@peabee, yes.

01micko commented 3 years ago

Haven't had time to test frugalpup-27 yet. Was an all day slog wrestling with databases to get the puppy wiki back online. Everything is version sensitive and nothing backward compatible!

On Sun, Mar 28, 2021 at 9:58 PM gyrog @.***> wrote:

@peabee https://github.com/peabee, yes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/1882#issuecomment-808886728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYZ33QH6M4QN4DWE6XCFTTF4KWNANCNFSM4S6OAVQQ .

01micko commented 3 years ago

Finally got round to installing a late slacko build on my HP tablet. Frugal pup install and boot went well. (frugalpup-28)

Just didn't register with the windows boot loader. Doesn't matter. I just hold volume button down and press power switch to get into the setup boot menu which is touch screen capable. The only way I could run any pup on this thing before is with either LICK (@noryb009 ) or booting off a READ ONLY micro sd-card with a hacked together grub2 installation.

gyrog commented 3 years ago

So, if you did manage to get your late slacko running on this machine, does 'efibootmgr -v' show anything interesting?

01micko commented 3 years ago

So, if you did manage to get your late slacko running on this machine, does 'efibootmgr -v' show anything interesting?

Yes. But more later. On screen keyboard

Screenshot

gyrog commented 3 years ago

Very interesting. So the "Puppy Linux - Grub2" boot looks like it is properly registered, so I wonder why it didn't boot? Did it show in the "Boot Menu"?

I'm assuming that the FrugalPup ".efi" files were actually written to '/EFI/Puppy' as this boot entry sugggests.

01micko commented 3 years ago

I think this issue is pretty much solved. Feel free to reopen if necessary.