Toshiba WT8-A netbook does not detect any bootable linux USB

bodge99 · 01-22-2023, 02:38 PM

Alternative Multiboot Tablet Installation.
Part 1. Preparing VirtualBox on the host system.

Multiboot the tablet using an external 120GB SSD in a USB caddy.

Overview:
As I'm going to be working with Mint 21.1 (for 32GB tablets) and Antix 22 (for 16GB tablets), I've decided to allocate a spare 120GB SSD for this purpose.
Both Linux systems are installed to this external SSD which I'll use in a modified multiboot environment. I use this particular method for every machine or external device that I multiboot with.

The external drive is prepared and installed from a desktop or laptop computer using VirtualBox. Any computer that can run 64-bit VirtualBox can be used for this purpose. i.e. Linux, Windows or MacOS (I assume Intel Macs.. I don't have any Apple kit, so I don't know..). This is both faster and more reliable (due to potential tablet USB resets when booting externally) than using the tablet directly.
The use of VirtualBox eliminates any chance that an errant installer (looking at certain Debian derived scripts here!) can cause any problems whatsoever on the host system.

The 120GB drive is partitioned as follows:

200 MiB ESP/EFI Fat32.
14.64 GiB Antix 22 system. Ext4.
29.59 GiB Mint 21.1 system. Ext4.
67.36 GiB Backup Ext4.

System partition sizes are chosen so that they are similar in size (very slightly less) to the tablets local storage.

Procedure:
Note: For terminal use, comments are within braces. These are not to be entered.

Install VirtualBox to the host system. Either use the version available from your distro repos or see:
https://www.virtualbox.org/

At the time of writing, I recommend the version 6.1 builds (supported until Dec. 2023).
https://www.virtualbox.org/wiki/Download_Old_Builds_6_1
Also download the 'Extension Pack'.
You will probably need to make the downloaded file executable. Assuming that this file is in your Downloads directory.
Using 'VirtualBox-6.1.42-155177-Linux_amd64.run' as an example.
In a terminal:

Code:

cd Downloads {Move to your Downloads directory}
chmod a+x VirtualBox-6.1.42-155177-Linux_amd64.run {Make the installation file executable for all users.}
sudo ./VirtualBox-6.1.42-155177-Linux_amd64.run {Install Virtualbox}

If the installation fails with the following:
(The example here shows output from OpenSuse and Ubuntu/Mint.)

Quote:

This system is currently not set up to build kernel modules.
Please install the gcc make perl packages from your distribution. ## Required missing software.
Please install the Linux kernel "header" files matching the current kernel for adding new hardware support to the system.
The distribution packages containing the headers are probably:
kernel-default-devel kernel-default-devel-6.1.6-1 ## This example is returned from OpenSuse.
linux-headers-generic linux-headers-5.19.0-29-generic ## This example is from Ubuntu/Mint.

There were problems setting up VirtualBox. To re-start the set-up process, run /sbin/vboxconfig as root. If your system is using EFI Secure Boot you may need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them.
Please see your Linux system's documentation for more information.

Install any missing software and/or kernel headers, then:

Code:

sudo /sbin/vboxconfig {Build the VirtualBox kernel modules.}

Now add yourself to the 'vboxusers' group. I'll use a user named 'fred' as an example. Replace 'fred' with your username.

Code:

sudo usermod -a -G vboxusers fred  {Add 'fred' to the 'vboxusers' group.}
groups {This will return a list of groups that you are a member of. Ensure that 'vboxusers' is in this list.}

Once the kernel headers (etc) have been installed and you are a member of the 'vboxusers' group:
Run Virtualbox from your system menu or from a terminal:

Code:

virtualbox

In 'File', 'Preferences', 'Extensions'. Click on the green plus symbol (towards the top right hand side) and browse to the downloaded (example name here.) 'Oracle_VM_VirtualBox_Extension_Pack-6.1.42.vbox-extpack'
'Install' the extension pack. Scroll down the license agreement and click on 'I Agree'
Close and restart VirtualBox.

Before proceeding, ensure that your Mint 21.1 and AntiX 22 iso's are in your 'Downloads' directory.

Set up an installation environment using VirtualBox:

'Machine', 'New'.
Name the Virtual Machine something like 'External install'. Change 'Type' to 'Linux' and 'Version' to 'Other Linux (64-bit)'.
Click 'Next'. Adjust the 'Memory Size' to 1-GB or larger, depending on your total amount of system Ram. (e.g. 4-GB Ram, use 1 or 2-GB. 8-GB or more, use 4-GB.) Click 'Next'.

In 'Hard Disk', select 'Do not add a virtual hard disk'. Click on 'Create'. Click on 'Continue' to confirm that you don't want a virtual hard disk created.

Adjust Virtual Machine Settings:
Your new Virtual Machine will appear in the left hand column as 'External install' and as 'Powered Off'. Right click on this and select 'Settings'.
In 'System', under the 'Motherboard' tab, click to enable 'Enable EFI (special OSes only)'.

Click on the 'Processor' tab. Move the 'Processor(s)' slider as required (e.g. If you have 4 - cores, set this slider to '2'. 16 or more cores, set it to '4' - '8'.
In 'Storage', in the 'Storage Devices' pane, click on the 'Empty' CD icon. In the 'Attributes' pane, click onto the blue CD icon.
In the drop down list, select 'Choose a disk file...'. Now browse to your Linux Mint Iso file (in 'Downloads'). You will now see this Iso showing in the 'Storage Devices' pane.

Nearly there!!, in 'USB', select which type of USB connectivity you have.
Plug in your external USB drive. Pause a few seconds so that the device is recognised by the host system.
At the far right hand side of the 'USB' window, you'll see a vertical column of USB icons. The top two will be coloured. Click on the second (the one with the green '+') and select your external USB drive. This means that every time the Virtual Machine is started, the external drive will automatically be connected. Any unmounting required in the host system is handled automatically.

VirtualBox is now configured to boot a Virtual Machine with Mint 21.1 Live.

Part 2 (onwards): Preparing the external drive, installing Mint and AntiX.
Also to follow:
Initial modifications to allow both installations to boot from 32-bit UEFI tablets.
Modifying the multiboot environment.
Working backup procedures. Transferring a Linux system to the tablet.

More soon.

B.

bodge99 · 01-23-2023, 04:20 PM

Part 2: Preparing the external drive, installing Mint, adding the 32-bit Uefi Grub Bootloader.

Recap: At this stage, the Virtual Machine is set up to boot the Mint 21.1 Live Iso. The use of this particular Iso is transient. By this I mean when the Virtual Machine is restarted, the Iso is disconnected. If you want to boot the Mint Iso again, you would need to manually add the Iso to the system. It is possible to make any Iso connection persistant (i.e it remains connected until manually removed) but I don't want this here.
This Virtual Machine will be used to boot other Iso's as well as any Linux's that are installed onto the external drive.

Quote:

Adjust Virtual Machine Settings: (Slightly reworded).
Your Virtual Machine will appear in the left hand column as 'External install' and as 'Powered Off'. Right click on this and select 'Settings'.

In 'Storage', in the 'Storage Devices' pane, click on the 'Empty' CD icon. In the 'Attributes' pane, click onto the blue CD icon.
In the drop down list, select 'Choose a disk file...'. Now browse to your required Iso file (in 'Downloads'). You will now see this Iso showing in the 'Storage Devices' pane. An Iso that has been used before will appear in the recently used list.

Prepare the external drive:

You can, of course, use any Linux system to prepare the external drive. As I'm going to be installing Mint onto the external drive, I'll do everything from Mint.

Plug in the external drive and double click on your Virtual Machine, 'External install'.
This will boot the Mint 21.1 live Iso.

I want the target partitions to be slightly smaller than the storage capacity of each tablet (less the size of the ESP/EFI partition).
This allows for the easy transfer of the relevant system partition to the tablet when required.

In a terminal:

Code:

sudo gparted

Unmount any automounted partitions by right clicking on them (one at a time) and selecting 'Unmount'.
'Device', 'Create Partition Table', choose 'gpt' and click on 'Apply'.

Create the ESP/EFI partition:
'Partition', 'New'. Enter '200' in the 'New size (MiB)' box. Change 'File system' to 'fat32'. Ensure that the new partition is at the beginning of the drive (i.e. at the far left hand side). If you need to, press 'Cancel' and repeat this part.

Create the AntiX system partition:
14.84 GiB = 15196 MiB. 'Partition', 'New'. Enter '15196' in the 'New size (MiB)' box. Ensure 'File system' is 'ext4'. Enter 'antix' into the 'Label' field. Click on 'Add'. Ensure that the new partition is adjacent to the ESP/EFI partition.

Create the Mint system partition:
29.79 GiB = 30504 MiB. 'Partition', 'New'. Enter '30504' in the 'New size (MiB)' box. Ensure 'File system' is 'ext4'. Enter 'mint' into the 'Label' field. Click on 'Add'. Ensure that the new partition is adjacent to the AntiX partition.

Create the Backup partition:
Use the remainder of the space for backup. 'Partition', 'New'. Ensure 'File system' is 'ext4'. Enter 'backup' into the 'Label' field. Click on 'Add'.

Apply all pending tasks:
'Edit', 'Apply All Operations', 'Apply'.

Close Gparted.

Install Mint and add 32-bit EFI Grub:

Double click on the 'Install Linux Mint' icon on the Mint desktop.
Follow the install prompts, making your selections until you reach the 'Installation type' window. Here, select 'Something else'.
Click on 'Continue'.

ESP/EFI:
Double click on '/dev/sda1 fat32' and change the 'Use as' entry to 'EFI System Partition'. Click on 'OK'.

Mint System Partition:
Double click on '/dev/sda3 ext4' and change the 'Use as' entry to 'Ext4 journaling file system'. Set the 'Mount point' to '/'. Click on 'OK'.

Click on 'Install Now'. Click on 'Continue' in both windows to confirm.

Now complete the installation as per normal.
When the installation has completed, shutdown and restart Mint.

Add 32-bit EFI Grub.
In a terminal:

Code:

sudo apt install grub-efi-ia32-bin  {Install 32-bit binaries to Mint.}
sudo grub-install --target=i386-efi   {Install the 32-bit EFI grub bootloader.}
sudo grub-install  {Reinstall the 64-bit Grub bootloader. This forces a 64-bit boot as primary.}

Now update Mint as per normal. Shutdown when this has completed.

Next: Install Antix, Modify both installations and the multiboot environment.

More soon.

B.

LassClueless · 01-24-2023, 06:09 AM

Hi, Bodge,

I'm really sorry. I was prepping to tackle my tablet again but my brother died last night, completely unexpectedly and so absolutely out-of-the-blue, so I'm not sure when I'll have the time, let alone the headspace to wrangle Linux. Although that said, if I can get my head sorted enough to be sure I won't mess up badly enough to trash the tablet, having to concentrate on Linux for a while might actually be helpful and take my mind off things. However, it may be a while before I feel up to picking up the tablet again, but I promise I will, whenever, and I'll post an update back here.
Clueless

bodge99 · 01-24-2023, 07:54 AM

Part 3. Install Antix, add a swapfile and the 32-bit EFI Grub Bootloader.

Install AntiX:
In VirtualBox, add the AntiX Iso to 'External install' Virtual Machine.

Quote:

(Reworded slightly.)
Right click on 'External install' and select 'Settings'.

In 'Storage', in the 'Storage Devices' pane, click on the 'Empty' CD icon. In the 'Attributes' pane, click onto the blue CD icon.
In the drop down list, select 'Choose a disk file...'. Now browse to your AntiX Iso file (in 'Downloads'). You will now see this Iso showing in the 'Storage Devices' pane. Click on 'OK'.

Normal Iso boot:
Now run the VM. Mint will boot by default, so as the boot begins (at the equivalent of the POST (Power On Self Test) stage), repeadly press the keyboard escape key. This will enter the VM equivalent of a Bios. Cursor to the 'Boot Manager' entry and press 'Enter'.
Cursor down to 'UEFI VBOX CD-ROM ....' entry and press 'Enter'. This will start the Antix installation program.

If you wish (or need to), you can start the installation (i.e. boot the Antix Iso) from the EFI shell.

EFI shell Iso boot:
Here, 'Esc' the default Mint boot and select 'Boot Manager' as above. Select 'EFI Internal Shell' and press 'Enter'.
In the 'Mapping Table', you'll see 'FS1: Alias(s):HDxxx...' and 'FS0: Alias(s):CDxxx....'

The 'FS1:' entry shows 'HDxxx'. This is the Mint ESP/EFI fat32 filesystem. The 'HD' implies 'HardDrive'.
The 'FS0:' entry shows 'CDxxx'. This is the filesystem on the mounted Antix Iso. We want this one. The 'CD' implies 'Compact Disc'.
Don't forget, an iso was originally an image of a CD-Rom.

Comments are shown in braces and are not to be entered.
Note: The shell command interpreter here is **NOT** case sensitive.
General directory navigation commands:
'cd ..' Change directory up a level.
'ls' or 'dir'. Show a directory listing.
Directory separators may be '/' or '\' (This is shell implementation dependent.).
For ease of use, just move one directory level per command.
e.g. to get from 'fs0:/' to 'fs0:/efi/boot' use:

Code:

{This is an example only.}
fs0:  {Make this filesystem current.}
cd efi
cd boot

Note: Most EFI shells support command completion (press/multiple press 'Tab'.) and command history (cursor up/down).

To continue...

Code:

fs0:  {Make fs0: current}
ls {or 'dir'}

This returns:

Code:

FS0:\> ls
08/24/2021 21:23 <DIR>      2,048 EFI
08/24/2021 21:23 <DIR>      2,048 boot

To save space here, the EFI bootloader files are located in 'fs0:\efi\boot'

Code:

cd efi
cd boot
ls

This returns:

Code:

Directory of: FS0:\efi\boot\
08/24/2021 21:23 <DIR>       2,2048  .
08/24/2021 21:23 <DIR>       2,2048  ..
07/11/2021 01:37          1,015,808  BOOTia32.efi
07/11/2021 13:46            934,240  BOOTx64.efi
07/11/2021 01:37          1,418,624  grubx64.efi
07/11/2021 09:53            845,480  mmx64.efi
          4 File(s)     4,214,152 bytes
          2 Dir(s)

'grubx64.efi' is the 64-bit EFI Grub bootloader executable, so

Code:

grubx64.efi {Start the Grub bootloader}

Antix Installation:

Cursor down to 'Language - Keyboard - Timezone' and press 'Enter'
Select your own language, keyboard and timezone. Cursor down to '<=== Back to main menu' and press 'Enter'.

Cursor down to '>>>Advanced Options<<<' and press 'Enter'.
Select 'Kernel options 4.9 Legacy' and choose 'Kernel:5.10 Modern'.
Select 'Desktop options', 'zzz-IceWM'.
Select '<=== Back to main menu'.
Lastly, select 'antiX-22 x64-full (18 October 2022)'

When the desktop has opened, single click on the 'Installer' icon.
If required, select 'Change Keyboard Settings' or 'Next'.
At the 'Select type of installation' section, choose 'Customize the disk layout'
At the 'Choose partitions' section:
Ensure that 'sda1' is shown as ('Use For') 'ESP' and ('Format') 'Preserve (vfat)'.
Change the entries for 'sda2' to:
For 'Use For', set it to 'root' and click on 'Next'.
Confirm the requested actions and continue to install the system.
Restart the system when requested.

Install 32-bit EFI Grub Bootloader:
In a terminal:

Code:

sudo grub-install --target=i386-efi   {Install the 32-bit EFI grub bootloader.}
sudo grub-install  {Reinstall the 64-bit Grub bootloader. This forces a 64-bit boot as primary.}

Create and enable a 1GB swapfile:
Make a backup of the existing 'fstab' (filesystem table). Modify the original to enable a swapfile.

Code:

sudo su
cp /etc/fstab /etc/fstab.ORIG
echo /swapfile none swap sw 0 0 >> /etc/fstab {Add a single line to '/etc/fstab'}
cat /etc/fstab  {Check that this line has been added correctly. This **MUST** be correct.}
fallocate -l 1G /swapfile {Create a 1GB swapfile.}
chmod 600 /swapfile  {Set the correct file attributes.} 
mkswap /swapfile
swapon -a {Activate the swapfile.}

Update the system:

I find it easiest to use the 'apt' command line package manager.
In a terminal:

Code:

sudo apt update
sudo apt upgrade

The basic Antix installation is now complete.

Next: Modifying the multiboot environment.

More soon.

B.

bodge99 · 01-24-2023, 07:59 AM

CluelessLass:

Sincere Condolences.

Don't worry about anything here at all. This stuff is totally unimportant in the scheme of things.

Please stay safe.

Kind Regards.

Bob.

bodge99 · 01-25-2023, 12:59 PM

Part 4. Modifying the multiboot environment:

Boot the 'External install' VM.
From the Grub menu, choose & boot Mint.

The standard multiboot setup has a few disadvantages when used with an external device. The biggest potential problem is that one installation has overall boot control. i.e. this system's local Grub files control everything. I call this "having lead Grub". If this installation is now deleted, then it's possible that the external drive won't allow (a default) boot as the system and its associated Grub files are now missing.
This cannot happen with my method, as the Grub installation within the ESP/EFI partition has "lead Grub".

Backup and move the original files. Install 32 & 64-bit EFI Grub:

Code:

sudo su {Become Root}
mount /dev/sda1 /mnt
mv /mnt/EFI /mnt/EFIORIG
grub-install --boot-directory=/mnt/EFI/boot --efi-directory=/mnt --target=i386-efi   {Install the 32-bit EFI grub bootloader.} 
grub-install --boot-directory=/mnt/EFI/boot --efi-directory=/mnt  {Install the 64-bit EFI grub bootloader.}
exit  {Become a normal user.}

Add a 'grub.cfg' so that the ESP/EFI based Grub has initial bootloader control.
Find and store the filesystem UUID's into a text file.

Code:

blkid > myblkid.txt

Sample 'myblkid.txt'

Code:

cat ./myblkid.txt 
/dev/sda3: LABEL="mint" UUID="09efa28c-4451-4bcd-a540-71df24641753" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cb37cc30-6bba-41fd-8398-c0c0e6775f9c"
/dev/sda4: LABEL="backup" UUID="42ebb050-6b58-43b7-be3a-9bee16bed3e3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="816a3d36-f9b1-4e0a-8ca9-9474bde11800"
/dev/sda2: LABEL="rootantiX22" UUID="d1e6b5f1-5ca0-4b1f-9b67-29b89429bcf7" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ea1ba46d-24f0-4be0-8f57-8011777ab4d8"
/dev/sda1: UUID="AFB8-6985" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="50bfb9ca-f692-4cd8-b0b3-924d42cf4df2"

Create a 'grub.cfg' (This is at '/mnt/EFI/boot/grub.cfg'.)

Code:

sudo xed /mnt/EFI/boot/grub.cfg

Populate this file with the following.. Use the UUID's for your system as stored in 'myblkid.txt'
Note: I've added a 10 second timeout. This will help if a tablet USB controller locks/resets, disabling a keyboard until the system has fully booted.
Note: 'sda1' is ESP/EFI, 'sda2' is AntiX and 'sda3' is Mint.

Code:

loadfont /EFI/boot/grub/fonts/unicode.pf2
terminal_output gfxterm

set timeout_style=menu
set timeout=10

menuentry "Mint 21.1" { 
    search --set=root --fs-uuid 09efa28c-4451-4bcd-a540-71df24641753
    set prefix=($root)/boot/grub
    configfile $prefix/grub.cfg }

menuentry "AntiX" { 
    search --set=root --fs-uuid d1e6b5f1-5ca0-4b1f-9b67-29b89429bcf7
    set prefix=($root)/boot/grub
    configfile $prefix/grub.cfg }

Save the file and exit 'xed'.

Download the 32-bit and the 64-bit EFI shell executables. Rename them as shown and place them in 'Downloads'.

32-bit EFI Shell:
https://github.com/tianocore/edk2/bl...Ia32/Shell.efi
Download 'Shell.efi'. Rename the downloaded file as 'shellia32.efi'

64-bit EFI Shell:
https://github.com/tianocore/edk2/bl.../X64/Shell.efi
Download 'Shell.efi'. Rename the downloaded file as 'shellx64.efi'.

Copy the downloaded files to the ESP/EFI filesystem.

Code:

cd Downloads
sudo cp shellia32.efi /mnt
sudo cp shellia32.efi /mnt/shell.efi {Make a second copy, named differently.}
sudo cp shellx64.efi /mnt
sudo umount /mnt

Some Uefi Bios's require an external shell program, sometimes it is required to be named as 'shell.efi' or as 'shellia32.efi' (for 32-bit).
For 64-bit Uefi, some Uefi Bios's require the file to be named as 'shell.efi' or as 'shellx64.efi'.

If you require a 64-bit external shell executable here, then you'll need to delete the existing (32-bit) 'shell.efi' and make a copy of 'shellx64.efi' as 'shell.efi'.

Reboot, select Antix from the initial Grub menu. After Antix has started properly, reboot again and select the Mint Grub option. If both start correctly, then delete the original ESP/EFI files and make a copy of the current **working** files.

In a terminal:

Code:

sudo mount /dev/sda1 /mnt
sudo rm -r /mnt/EFIORIG {Delete the original files.}
sudo cp -r /mnt/EFI /mnt/EFIBACKUP {Backup the current working files.}
sudo umount /mnt

Maintenance:
If any particular installation is changed, all you need in the primary (ESP/EFI based) based 'grub.cfg' is the menuentry name, the file system UUID (this will change if the partition is reformatted) and the location of the system's 'grub.cfg'. This is normally found at '/boot/grub/grub.cfg', but be aware that some systems (e.g. OpenSuse) use '/boot/grub2/grub.cfg'.
A system update of Grub will make changes to the ESP/EFI filesystem. These are actually easy to 'unpick' but it is easiest to just delete the 'EFI' directory and copy the 'EFIBACKUP' directory as 'EFI'.

To do this, mount the external drive's EFI/ESP partition in any Linux to '/mnt' and delete and copy.
In a terminal, using 'sda1' as an example:

Code:

sudo mount /dev/sda1/mnt
sudo rm -r /mnt/EFI
sudo cp -r /mnt/EFIBACKUP /mnt/EFI
sudo umount /mnt

I'll post some Grub and booting problem tips which should be useful to some..

More soon..

B.

bodge99 · 01-27-2023, 05:12 PM

Booting and Grub problems:
part 1.

First off..
How A UEFI Linux System Boots: (slightly simplified).

On powerup, code within the Bios firmware performs basic initialisation of the hardware. When this initial setup has completed, basic boot information is read from the system EFI boot variables that are held in NVRAM (non-volatile RAM). These are essentially an ordered list of devices that the system will attempt to boot from.

The selected boot option (either the default boot, one selected by the user or a remaining "fall through" option (e.g. the EFI shell, if available.)).
A normal system boot then looks for a specific 'efi' executable. This starts the Grub Bootloader which obtains further possible boot options from a configuration file within the target system. The selection (or default choice) here then starts the Linux kernel, using the initramfs/initrd.

Looking at each part, in turn:

NVRAM Boot variables, aka EFIVARS:
Some of these are provided as default by the system Bios (e.g. EFI shell, CDRom, detected disk drives.), some are supplied by the installation of an OS (or by the installation/reinstallation of an EFI bootloader.) or manual additions may also be made.

In Linux, these variables can be read or modified using the 'efibootmgr' tool.
As an example, this tool returns the following when invoked on a VirtualBox installation of Linux Mint.

Code:

bob@m21:~$ sudo efibootmgr
 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003,0004
Boot0000* ubuntu
Boot0001* UiApp
Boot0002* UEFI VBOX CD-ROM VB0-1a2b3c4d 
Boot0003* UEFI VBOX HARDDISK VB24d0c404-8e2b977f 
Boot0004* EFI Internal Shell

Sometimes, you need the '-v' switch for more information:

Code:

bob@m21:~$ sudo efibootmgr -v
 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003,0004
Boot0000* ubuntu	HD(1,GPT,07da21cd-2a16-4d95-bf6f-6d54a8f257c2,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0002* UEFI VBOX CD-ROM VB0-1a2b3c4d 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0003* UEFI VBOX HARDDISK VB24d0c404-8e2b977f 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(1,65535,0)N.....YM....R,Y.
Boot0004* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)

These choices are those displayed when using your boot override key. There may be additional entries, due to boot time (external, e.g. USB) hardware detection.

The entries here show that default boot option is Ubuntu (actually Mint). This system is located on a drive whose partition UUID is '07da21cd...'
The EFI executable is : '\EFI\ubuntu\shimx64.efi'. Please see 'EFI Grub Files:', below.

Directory & file tree of an Ubuntu ESP/EFI filesystem. Other Linux distro's will have identical or a very similar layout.

Code:

root@m21:/boot/efi# tree .
EFI
 ├── BOOT
 │   ├── BOOTX64.EFI
 │   ├── fbx64.efi
 │   └── mmx64.efi
 └── ubuntu
      ├── BOOTX64.CSV
      ├── grub.cfg
      ├── grubx64.efi
      ├── mmx64.efi
      └── shimx64.efi

3 directories, 8 files

The biggest difference is that other distro's use a different location for 'grubx64.efi'. e.g. OpenSuse uses '/EFI/opensuse', AntiX 22 uses '/EFI/antix22' or '/EFI/antix-22' (depending on how the bootloader was installed) and MXLinux 21 uses '/EFI/MX21' ...etc.
Ubuntu/Mint use an initial 'grub.cfg'. This file defines the location of the main system 'grub.cfg' (at '/boot/grub/grub.cfg').
I personally regard this method as slightly more robust and use variations of this for specific purposes.

Sample initial 'grub.cfg':

Code:

search.fs_uuid 088aeccf-dd1f-4d9c-a969-3b5f72917e2b root hd0,gpt2 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

This uses a Grub search tool to look for a filesystem with a given UUID. The partition returned is stored as the 'root' variable.
A second variable is then set from this. Finally, control to passed to the target systems's 'grub.cfg'.
It is the system 'grub.cfg' that actually starts the Linux kernel & initrd/initramfs.

Code:

EFI Grub Files:
'grub.cfg'    : Initial 'grub.cfg'. Specificially sets the location of the main system's 'grub.cfg'.
'grubx64.efi' : The EFI Grub bootloader executable (unsigned).
'mmx64.efi'   : This is the MOKManager utility. It is used for signing bootloaders with a Machine Owner Key. 
              : When this is used, it normally calls 'grubx64.efi'
'shimx64.efi' : The signed Grub bootloader executable. If secure booting is disabled, this file runs essentially identically to 'grubx64.efi',
'BOOTX64.CSV' : A UCS-2 or UTF-16 text file that is used with the fallback executable.
'fbx64.efi'   : This is a fallback option tool, invoked if the normal boot version fails for some reason.
'BOOTX64.EFI' : A backup copy of 'shimx64.efi'. Normally used in fallback booting.

Note: If you have Windows installed, 'BOOTX64.EFI' may actually be a copy of the windows bootloader 'bootmgfw.efi'.

Next: More on Grub, manual booting and fixing boot problems.

B.

bodge99 · 02-05-2023, 04:27 AM

Hi.

I've been asked to add Fedora to the external multiboot setup.

I've had to make a minimal change to the Fedora installation (specifically to the location of the Fedora version of the Grub Efi boot executables).
This is because Fedora uses Grub slightly differently than just about every other distro out there. As with Mint and AntiX, the system runs and updates perfectly normally.

Therefore, I'll delay posting the second section on Grub & booting problems until later.

More soon.

B.

bodge99 · 02-07-2023, 07:38 AM

Fedora Installation.:
External Drive EFI Autostart:

In gparted, Create a partition of 29.79 GiB (= 30504 MiB) and format to ext4. I "borrowed" space from the 'backup' partition.
Mount the Fedora iso in the VirtualBox VM. I'm using the Cinnamon-Live version.
Boot the Virtual Machine.

At the Grub menu: If you have an option for EFI Shell, select this.
Otherwise, press 'c' for 'command line'. At the Grub prompt, enter 'exit'.
You will now either be at the EFI shell or the Fedora Iso will autorun.
If you are at the EFI Shell: Type in 'exit' to enter the VirtualBox 'Bios'. Select 'Boot Manager'. Cursor down to 'UEFI VBOX CD-ROM..' and press 'enter'.

When the Iso has booted:
At the Fedora Cinnamon desktop, open a terminal.
Rename the existing 'EFI' directory, so moving it out of the way:

Code:

sudo mount /dev/sda1 /mnt
sudo mv /mnt/EFI /mnt/EFI-UBUNTU
sudo umount /mnt
exit

Select 'Install to Hard Drive'.
Choose your keyboard layout and 'Continue'.
Now choose your 'Root Account' and 'User Creation' settings.

'Installation Destination':
'Storage Configuration' - Choose 'Advanced Custom'. Click on the (at the top left) green 'Done'.
On the next screen:
Right click on 'sda1', 'Edit', 'Set mountpoint'. Enter '/boot/efi' here. Click on 'Set mountpoint'.
Right click on your new Fedora partition. 'Edit', 'Format'. Set 'Select new format' as 'ext4', 'Label' as 'Fedora' and 'Mountpoint as '/'. Click on 'Format'.
Click on 'Done', twice and 'Accept Changes'. Now click on 'Begin Installation'.

Let the installation finish and shut down. Remove the Iso from the Virtual Machine.
Restart the VM. Boot Fedora. Fully update using 'Dnfdragora-updater' (RHS on the panel/task bar).
Restart the VM again.

Rebuild 'initramfs':
This is recommended so that the initramfs will now include more drivers. This allows the operating system to boot on a far greater range of different computers or tablets etc.
In a terminal:

Code:

sudo dracut --force --no-hostonly --regenerate-all

For speedier boot & shutdown in the VM, uninstall the Fedora version of virtualbox-guest-additions using dnfdragora (on the panel/taskbar).
In the VM menu: 'Devices', 'Insert Guest Additions CD Image'. Click 'Run' to allow the software to install. Restart when the installation has completed.

Default Fedora EFI directory tree:

Code:

.
├── EFI
│   ├── BOOT
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTX64.EFI
│   │   ├── fbia32.efi
│   │   └── fbx64.efi
│   └── fedora
│       ├── BOOTIA32.CSV
│       ├── BOOTX64.CSV
│       ├── gcdia32.efi
│       ├── gcdx64.efi
│       ├── grub.cfg
│       ├── grubia32.efi
│       ├── grubx64.efi
│       ├── mmia32.efi
│       ├── mmx64.efi
│       ├── shim.efi
│       ├── shimia32.efi
│       └── shimx64.efi
├── mach_kernel
└── System
    └── Library
        └── CoreServices
            └── SystemVersion.plist

7 directories, 18 files

Modified EFI directory tree:
The Ubuntu Grub files here have 'lead Grub'.
NOTE: I've ignored the "workaround" added '/EFI/fedora/i386-efi' directory & contents here. See below.

Code:

.
├── EFI
│   ├── boot
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTX64.EFI
│   │   ├── fbx64.efi
│   │   ├── grub
│   │   │   ├── fonts
│   │   │   │   └── unicode.pf2
│   │   │   ├── grub.cfg
│   │   │   ├── grubenv
│   │   │   ├── i386-efi
│   │   │   │   ├── acpi.mod
│   │   │   │   ├── adler32.mod
│   │   │   │   ├── affs.mod
│   │   │   │         :
│   |   │   │     {Truncated listing.} 
│   |   │   │         :
│   │   │   │   ├── zfsinfo.mod
│   │   │   │   ├── zfs.mod
│   │   │   │   └── zstd.mod
│   │   │   ├── locale
│   │   │   │   ├── en_AU.mo
│   │   │   │   ├── en_CA.mo
│   │   │   │   ├── en_GB.mo
│   │   │   │   └── en@quot.mo
│   │   │   └── x86_64-efi
│   │   │       ├── acpi.mod
│   │   │       ├── adler32.mod
│   │   │       ├── affs.mod
│   │   │             :
│   │   │         {Truncated listing.} 
│   │   │             :
│   │   │       ├── zfsinfo.mod
│   │   │       ├── zfs.mod
│   │   │       └── zstd.mod
│   │   └── mmx64.efi
│   ├── BOOT-FEDORA
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTX64.EFI
│   │   ├── fbia32.efi
│   │   └── fbx64.efi
│   ├── fedora
│   │   ├── BOOTIA32.CSV
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTX64.CSV
│   │   ├── BOOTX64.EFI
│   │   ├── gcdia32.efi
│   │   ├── gcdx64.efi
│   │   ├── grub.cfg
│   │   ├── grubia32.efi
│   │   ├── grubx64.efi
│   │   ├── mmia32.efi
│   │   ├── mmx64.efi
│   │   ├── shim.efi
│   │   ├── shimia32.efi
│   │   └── shimx64.efi
│   └── ubuntu
│       ├── BOOTX64.CSV
│       ├── grub.cfg
│       ├── grubx64.efi
│       ├── mmx64.efi
│       └── shimx64.efi
├── mach_kernel
├── myextnldrv
├── shell.efi
├── shellia32.efi
├── shellx64.efi
├── startup.nsh
└── System
    └── Library
        └── CoreServices
            └── SystemVersion.plist

14 directories, 597 files

What I want here:
The preliminary boot is from the Ubuntu Grub installation. Fedora is chainloaded from here. (See the initial 'grub.cfg', below').
The 32 & 64-bit Fedora versions of 'BOOTIA32.EFI' and 'BOOTX64.EFI' are copied from Fedora's '/BOOT' (named here as '/BOOT-FEDORA') directory to '/fedora'. This allows Fedora to boot correctly (as per its particular invocation of Grub.).

Finally, a marker file ('myextnldrv') and an autorunning EFI shell script file 'startup.nsh' are placed in the top level directory here. See below.

Prepare the required EFI directory structure:
Boot from any convenient Linux system, either Fedora from the external drive, a host system or VirtualBox. If required, connect the external drive.
Identify the required external drive EFI/ESP partition. I'll use '/dev/sda1' here.
In a terminal:

Code:

sudo su
mount /dev/sda1 /mnt

mv /mnt/EFI /mnt/EFI-FEDORA  {Move the Fedora files out of the way.}
mv /mnt/EFI-UBUNTU /mnt/EFI  {Bring the Ubuntu Grub files back.}

mv /mnt/EFI-FEDORA/fedora /mnt/EFI  {Files here are chain-booted from Ubuntu Grub.}
mv /mnt/EFI-FEDORA/BOOT/BOOT*.EFI /mnt/EFI/fedora {Move Fedora *.EFI files to the required location.}

rm -r /mnt/EFI-FEDORA {Use 'rm -rf /mnt/EFI-FEDORA' if running Fedora.}
touch /mnt/myextnldrv {Create zero length marker file for partition/file system identification purposes.}

cp -R /mnt/EFI/boot/grub/i386-efi /mnt/EFI/fedora {Workaround for some versions of (not Ubuntu) 'BOOTIA32.EFI'} 
exit {Become a normal user.}

Add an entry for Fedora to the EFI/ESP 'grub.cfg':

Code:

sudo xed /mnt/EFI/boot/grub/grub.cfg {or use your local text editor.. e.g. gedit, pluma etc.}

Add the following stanza and save the file. Ensure that the UUID here is that of the external drive's EFI/ESP filesystem.

Code:

menuentry "Fedora" {
    search --set=root --fs-uuid AFB8-6985
    set prefix=($root)/EFI/fedora 
    if [ $grub_cpu = "x86_64" ]; then
        chainloader $prefix/BOOTX64.EFI
    else
        chainloader $prefix/BOOTIA32.EFI
    fi }

Note: I've used a UUID search here. This makes the Grub entry slightly more robust.

Create the auto running 'startup.nsh' file:

Code:

sudo xed /mnt/startup.nsh

Populate this file with the following:

Code:

@echo -off
cls
for %a run (0 10)
set -v mydrv %a
if exist FS%mydrv%:\myextnldrv then
FS%mydrv%:
echo "FS%mydrv%:\myextnldrv located"
goto DRVFOUND
endif
endfor
goto END
:DRVFOUND
if exist myextnldrv then
echo "%cwd%myextnldrv
endif
:END
set -d mydrv
cd EFI
cd ubuntu
grubia32.efi
grubx64.efi

Finally, make a copy of the current '/EFI' directory & contents:

Code:

sudo cp -r /mnt/EFI /mnt/EFIBACKUP
sudo umount /mnt {Unmount before restart or shutdown.}

Booting the external drive:

This assumes that there are no other instances of any 'startup.nsh' file on any EFI/ESP/fat32 filesystem at boot time.

Boot the machine or tablet etc. Use your boot override mechanism (or enter the Bios settings). Select the 'EFI shell' boot option.
The computer will scan all connected EFI/ESP/fat32 filesystems looking for a 'startup.nsh' file.

This file will autorun if found.

'startup.nsh' operation description:
Initially, Up to 11 filesystems are tested. ( i.e. fs0: to fs10: ). Adjust the second number in the command if required.
A test is made of each drive, in turn, for the existence of a file named 'myextnldrv' in the top level (a.k.a. 'root') directory.
When this file is located, the current drive and working directory is then set. The relevant Grub EFI executable is then invoked.
Note: The 32-bit Grub EFI executable will fail to run in a 64-bit environment. Booting now continues with 'grubx64.efi'.

More soon.

B.

bodge99 · 02-07-2023, 10:46 AM

Hi,

For tablet use, I'd recommend adding a swapfile...

Add a 1GB swapfile to Fedora:

Repeating this from post No. 79.

Boot Fedora.
Make a backup of the existing 'fstab' (filesystem table). Modify the original to enable a swapfile.

Code:

sudo su
cp /etc/fstab /etc/fstab.ORIG

echo /swapfile none swap sw 0 0 >> /etc/fstab {Add a single line to '/etc/fstab'}
cat /etc/fstab  {Check that this line has been added correctly. This **MUST** be correct.}

fallocate -l 1G /swapfile {Create a 1GB swapfile.}
chmod 600 /swapfile  {Set the correct file attributes.} 

mkswap /swapfile
swapon -a {Activate the swapfile.}

B.

colorpurple21859 · 02-08-2023, 09:32 AM

for bodge99, have you considered the following:

1. Adding --no-nvram to the i386-efi grub install commands in posts 77 and 79, removing the need to reinstall grubx64.efi
2. Adding --removable to the grub-install commands in post 81?

Other than that, your posts have been excellent.

bodge99 · 02-08-2023, 11:37 AM

Hi,

Colorpurple21859:

Thanks for the input.. I've found that using the '--no-nvram' flag can cause problems on some UEFI systems.. It would appear that some NVRAM access mechanisms are somewhat non-standard here (rare, yes!). I don't quite understand the exact mechanism, as I would have thought that **NOT** invoking an NVRAM write couldn't cause problems.. but it would appear that it can.. ho hum.

'--removable' flag: I view this one as a "personal taste" item. This one seems to work slightly differently, depending on the exact Grub version used.
I personally prefer to have 'EFI/boot/bootx64.efi' registered to NVRAM. I'd rather "have it and not use it" as opposed to "want it and not have it".

I'm also looking at the standard Fedora EFI file layout more closely. It would appear that the use of the 'mach_kernel' and 'System' files are Apple UEFI specific and that the installation on non-Apple kit is actually a Fedora bug?? I'll look more closely at this one.

B.

colorpurple21859 · 02-08-2023, 11:50 AM

In Fedora attempt to make grub easier to use, IMHO as made it a nightmare. Fedora has the packages for grub commands to work similar to other distros, but doesn't install them.

bodge99 · 02-17-2023, 04:41 AM

Hi,

I've been busy recently and haven't had time to post anything. More will be coming shortly.

Q. I've been asked to add Windows 10 to the multiboot external drive setup. As this is a Linux forum, I'm unsure how well this would be received here.
If this would be of use to anyone here then I'll provide a writeup.. Comments are more than welcome..
Before anyone says otherwise.. yes, you can run a complete version of W10 from an external USB drive.

I'm also going to make some changes to the external drive setup. I've just been dealing with a UEFI system that has no Bios support for either an internal or external EFI shell. Perhaps I've "been lucky" up to now. ;>)

I'm going to look at forcing the use of the 'startup.nsh' shell file by replacing the relevant 'bootx64.efi' and 'bootia32.efi' files with renamed 'shell.efi' files (both 32 and 64-bit versions).

More soon.

B.

bodge99 · 03-03-2023, 04:01 PM

UEFI Booting:
External Drive Boot Modifications:

Recap:
On powerup, the UEFI Bios will attempt to boot using information obtained from the system stored NVRAM Boot variables (EFIVARS). If these are not found (i.e. are not configured) then the Bios will attempt to boot '/efi/boot/bootx64.efi' by default (this path and filename are NOT case sensitive within the EFI environment).

Control is then passed to the bootloader which now starts the system.

A successful boot (using 'bootx64.efi') causes an entry to be added to the NVRAM boot list if an identical one is not already present. Most modern bootloaders will then promote the use of a signed bootloader executable, if this is available. If 'Secure booting' is disabled in the system Bios, then the signed bootloader will function in an identical manner as the unsigned bootloader.

Example: (Using 'efibootmgr -v' in Linux.)

Code:

Boot0004* ubuntu	HD(1,GPT,07da21cd-2a16-4d95-bf6f-6d54a8f257c2,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

This is the fifth boot entry on a system that is installed with Linux Mint (a derivative of Ubuntu, this uses the Ubuntu Grub configuration.).
The actual Grub bootloader invoked here is 'shimx64.efi'. This is the signed version of 'grubx64.efi'.

Most systems have either an internal EFI shell or allow a user supplied external EFI shell executable to be used. There are systems that have neither. These systems rely on the use of the NVRAM boot list (with or without manual selection of external boot devices) or the 'fallback' boot using 'efi/boot/bootx64.efi'. This is perfectly fine but this causes a minor problem with how I want my external multiboot drive to be booted.

I want the startup shell/batch file 'startup.nsh' to run automatically if there is no internal/external EFI shell available.
This can be accomplished by replacing the external drive's 'bootx64.efi' and 'bootia32.efi' with the relevant renamed 'shell.efi' files.
i.e. Replace 'bootx64.efi' with 'shellx64.efi' renamed as 'bootx64.efi' etc.

Examples follow.. I'll assume Mint, Antix and Fedora are installed on the external drive.
Mount the external device to '/mnt'. You can either use a real Linux system or your External Install VM, booted from a Linux Mint Iso.
I'll assume that the external drive is seen as 'sda'. Adjust as required.
Note: For Fedora: This is treated as a 'special case' installation, due to its 'unusual' Grub implementation and kernel handling.
As mentioned in post No. 87, The 'mach_kernel' and 'System' files are Apple UEFI specific and are not required here. These are deleted below.

Code:

sudo su
mount /dev/sda1 /mnt

{For Mint & Antix etc.}
mv /mnt/EFI/boot/BOOTX64.EFI /mnt/EFI/boot/BOOTX64.EFIORIG    {Backup original file.}
mv /mnt/EFI/boot/BOOTIA32.EFI /mnt/EFI/boot/BOOTIA32.EFIORIG

cp /mnt/shellx64.efi /mnt/EFI/boot/BOOTX64.EFI      {Copy & rename shell executables.} 
cp /mnt/shellia32.efi /mnt/EFI/boot/BOOTIA32.EFI 


{For Fedora only.}
rm /mnt/mach_kernel {Delete unwanted file.}
rm -R /mnt/System   {Delete unwanted files.}

mv /mnt/EFI/fedora/BOOTX64.EFI /mnt/EFI/fedora/BOOTX64.EFIORIG    {Backup original file.}
mv /mnt/EFI/fedora/BOOTIA32.EFI /mnt/EFI/fedora/BOOTIA32.EFIORIG

cp /mnt/shellx64.efi /mnt/EFI/fedora/BOOTX64.EFI      {Copy & rename shell executables.} 
cp /mnt/shellia32.efi /mnt/EFI/fedora/BOOTIA32.EFI

Befor proceeding, check that your directory layout corresponds with the following tree.

Code:

.
├── EFI
│   ├── boot
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTIA32.EFIORIG
│   │   ├── BOOTX64.EFI
│   │   ├── BOOTX64.EFIORIG
│   │   ├── fbx64.efi
│   │   ├── grub
│   │   │   ├── fonts
│   │   │   │   └── unicode.pf2
│   │   │   ├── grub.cfg
│   │   │   ├── grubenv
│   │   │   ├── i386-efi
│   │   │   │   ├── acpi.mod
│   │   │   │   ├── adler32.mod
│   │   │   │   ├── affs.mod
│   │   │   │   │      :
│   │   │   │   : {Truncated listing.} 
│   │   │   │   │      :
│   │   │   │   ├── zfsinfo.mod
│   │   │   │   ├── zfs.mod
│   │   │   │   └── zstd.mod
│   │   │   ├── locale
│   │   │   │   ├── en_AU.mo
│   │   │   │   ├── en_CA.mo
│   │   │   │   ├── en_GB.mo
│   │   │   │   └── en@quot.mo
│   │   │   └── x86_64-efi
│   │   │       ├── acpi.mod
│   │   │       ├── adler32.mod
│   │   │       ├── affs.mod
│   │   │       │      :
│   │   │       : {Truncated listing.} 
│   │   │       │      :
│   │   │       ├── zfsinfo.mod
│   │   │       ├── zfs.mod
│   │   │       └── zstd.mod
│   │   └── mmx64.efi
│   ├── BOOT-FEDORA
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTX64.EFI
│   │   ├── fbia32.efi
│   │   └── fbx64.efi
│   ├── fedora
│   │   ├── BOOTIA32.CSV
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTIA32.EFIORIG
│   │   ├── BOOTX64.CSV
│   │   ├── BOOTX64.EFI
│   │   ├── BOOTX64.EFIORIG
│   │   ├── gcdia32.efi
│   │   ├── gcdx64.efi
│   │   ├── grub.cfg
│   │   ├── grubia32.efi
│   │   ├── grubx64.efi
│   │   ├── i386-efi
│   │   │   ├── acpi.mod
│   │   │   ├── adler32.mod
│   │   │   ├── affs.mod
│   │   │   │      :
│   │   │   :  {Truncated listing.} 
│   │   │   │      :
│   │   │   ├── zfsinfo.mod
│   │   │   ├── zfs.mod
│   │   │   └── zstd.mod
│   │   ├── mmia32.efi
│   │   ├── mmx64.efi
│   │   ├── shim.efi
│   │   ├── shimia32.efi
│   │   └── shimx64.efi
│   └── ubuntu
│       ├── BOOTX64.CSV
│       ├── grub.cfg
│       ├── grub.efi
│       ├── grubia32.efi
│       ├── grubx64.efi
│       ├── mmx64.efi
│       └── shimx64.efi
├── myextnldrv
├── shell.efi
├── shellia32.efi
├── shellx64.efi
└── startup.nsh

Note: This directory & file tree ignores the 'EFIBACKUP' directory structure. This existing backup will now be deleted and a new copy made.

Code:

rm -r /mnt/EFIBACKUP {Delete the original files.}
cp -r /mnt/EFI /mnt/EFIBACKUP
umount /mnt {Unmount before restart or shutdown.}

This modified format brings this external drive to virtually the same specification as I use with my other external multiboot devices. The only difference is that I haven't provided any legacy support. Adding this will allow this external drive to multiboot on any 64-bit UEFI or legacy boot PC.

More soon.

B.