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

bodge99 · 03-12-2023, 04:15 PM

Bug Fix:
Alteration to the 'startup.nsh' file: See post No 84.

I've discovered that the auto running 'startup.nsh' can fail on some earlier UEFI machines.
The problem arises at the point where the attempt is made to run 'grubia32.efi' within a 64-bit environment.
This file will only run within a 32-bit UEFI environment. The failure to run within a 64-bit environment is supposed to be "graceful" (i.e. the shell file execution is supposed to continue with the next command.).
I've found one machine where this failure causes the shell file to abort.

The fix is to move the attempted invocation of the 32-bit bootloader (grubia32.efi) to a second shell file.
If the attempt to run 'grubia32.efi' succeeds, control is passed to the 32-bit boot environment which then starts the kernel from 'grub.cfg'.
If this attempt fails, the shell file either aborts or completes.. so returning control to the calling file (i.e. startup.nsh).
Now, the 64-bit bootloader (grubx64.efi) is invoked and the kernel is started from 'grub.cfg'.

Alterations:
Mount the external drive to '/mnt'.
Replace the contents of 'startup.nsh' with the code below.
Create a new file, named as 'testbitness.nsh'. Populate it with the code below.

I'll assume that the external drive is '/dev/sda'. Adjust as required.

Code:

sudo mount /dev/sda1 /mnt {Mount the EFI/ESP to '/mnt'}
sudo xed /mnt/startup.nsh {Delete the existing contents. Now copy & paste the new code. Save & exit 'Xed'.}
sudo xed /mnt/testbitness.nsh {Populate with the code below. Save & exit 'Xed'.}
sudo umount /mnt

startup.nsh

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
echo "myextnldrv NOT found. Aborting."
goto END
:DRVFOUND
echo "Call file as test for bit-ness"
testbitness.nsh
echo "32-bit test failed. Shell is 64-bit."
grubx64.efi
:END

testbitness.nsh

Code:

echo "Trying 32-bit UEFI"
cd EFI
cd ubuntu
grubia32.efi

Booting the external drive: (This replaces the booting section in post No. 84.)

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.
If there is no internal or external shell Bios option, then the modified fallback boot will invoke the relevant shell files (Renamed as 'BOOTIA32.EFI' and 'BOOTX64.EFI'. See post No. 90).
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 identified current drive is then set.

The 'testbitness.nsh' secondary shell file is now called.
The file attempts to run 'grubia32.efi'. If this succeeds, control is passed to the 32-bit boot environment which then starts the kernel from 'grub.cfg'.
If this attempt fails, the shell file either aborts or completes.. Both of these return control to the calling file (i.e. startup.nsh).
The shell environment now must be 64-bit. The 64-bit bootloader (grubx64.efi) is now invoked and the kernel is started from 'grub.cfg'.

More soon.

B.

bodge99 · 03-26-2023, 06:52 PM

UEFI Booting Problems:
Some worked examples and a few tips.

Part 1. 'fstab' and device/filesystem mounting.

In my experience, many booting problems arise due to changes that a user has made to a system. Sometimes minor oversights can cause a system to fail to boot. (been there, done that!).
I've seen many many folk that then rush to use a boot repair tool.. which unfortunately can sometimes make things worse.
Please don't think that I'm criticising any specific boot repair tool.. I'm not, it's just that some of these tools assume that the user has a reasonable knowledge of how Linux boots and hardware identification etc. In times of panic, it's easy to make incorrect choices.. again.. been there, done that!!

Just for reasons of completeness..
Legacy Boot: (slightly simplified..)

The hard drive or other boot device contains an 'msdos' partition table. This partition table holds information about (up to) four primary partitions.
Originally, this was a "hard limit" on what could be placed on a hard drive. This limit was overcome somewhat with the introduction of the concept of an "extended partition". This extended partition can have a greater number of logical partitions within it.

At the very beginning of the drive (outside of any partition) there exists the 'master boot record' and the 'first stage bootloader'.
These hold information such as 'is this drive bootable' and 'where is the bootloader'. Only one bootloader can be "pointed to". This is one of the reasons why some folk have OS booting problems on legacy systems. Operating systems such as Windows will overwrite info here with no regard to any other OS at all.
On system start, Grub runs and loads its configuration file ('grub.cfg'). From this stage, booting is identical to UEFI.

UEFI booting recap:
Essential other files: 'fstab' & 'grub.cfg'. Description below.

UEFI Booting Overview: Powerup to kernel start (normal boot. Grub bootloader.).

On powerup, the machine Bios performs basic system initialisation. Basic boot information is 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 either the signed (shimx64.efi) or unsigned (grubx64.efi) Grub bootloader.
This then loads a configuration file (/boot/grub/grub.cfg) which then starts to load the Linux kernel. The kernel uses a ram based filesystem (extracted from the initrd [initial ram device/drive or initial ramdisk filesystem]) to configure the system..
Note: There are Linux distros that support booting without the use of an initrd. An example is Slackware which can be configured to use the 'huge' kernel without an initrd.

After the configuration phase, the initial ram file system is deleted, freeing this memory. Control is then passed to the system 'init' (System Initilisation). This may be System V, SystemD, Upstart, Runit, OpenRC etc.

The Filesystem Table:
Partition and filesystem information held within this file is required for a successful boot. This is a text file that is located at '/etc/fstab'.
This file holds information on which filesystems should be used within the running system. Essentially, this file is a list of 'mount' instructions that are used to configure the system file and drive structure.

Examples follow:

Typical Ubuntu/Mint (etc.) 'fstab':
Note: I've adjusted the line spacing to make this file easier to read.

Code:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>                       <mount point>    <type>  <options>       <dump>  <pass>

# / was on /dev/sda3 during installation
UUID=7caee267-2eb7-462a-bcab-498fd987bde5   /           ext4    noatime,errors=remount-ro 0       1

# /boot/efi was on /dev/sda2 during installation
UUID=077C-A8CF                              /boot/efi   vfat    umask=0077      0       1

/swapfile                                   none        swap    sw              0       0

This shows that the main filesystem is 'ext4' and has a (filesystem) UUID of 7caee267-2eb7-462a-bcab-498fd987bde5. It was originally placed on 'sda3'.
Note: This 'sda3' information may have changed after installation. Don't assume that this is correct. I've also added the 'noatime' option here.

The ESP/EFI is 'vfat/fat32'. It was originally '/dev/sda1' and its filesystem is mounted to '/boot/efi' within the system's main filesystem.

System Swap is handled by a swapfile which is located at the root directory (aka the top level directory '/').

Typical Slackware (etc.) 'fstab':

Code:

/dev/sda3        swap             swap        defaults         0   0
/dev/sda2        /                ext4        defaults         1   1
/dev/sda1        /boot/efi        vfat        defaults         1   0

#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0

This shows that the system swap is actually a partition and not a file. The main filesystem is 'ext4' on 'sda2'. The ESP/EFI partition is 'sda1' and is mounted to '/boot/efi'.
Functionally, these two 'fstab's are essentially identical (ignoring the options).

The 'fstab' entries can be written in several ways, each functionally identical. There are a few potential disadvantages to each method. (detailed in the next post.)

Firstly:
Mounting filesystems:

Consider this: Below is the info returned from the 'blkid' command for a flashdrive that is formatted as 'ext4' on one partition. I've also given it a filesystem label as well as a partition label.

'blkid' returns this: Note: I've split each section into separate lines for ease of reading.

Code:

bob@bob-VirtualBox:~$ sudo blkid | grep sda1  {Just show the data for 'sda1'}

/dev/sda1: LABEL="My-FS-label" UUID="f1900c6d-9a84-4dbb-9e18-843d17cff29b"

BLOCK_SIZE="4096" TYPE="ext4" 

PARTLABEL="My-PARTITION-label" PARTUUID="08eaf31c-b115-4e4c-bae4-7e2cb0bf8b9a"

If I want to mount this flashdrive to '/mnt', I could use any of the following five (manual) methods.

Code:

{As 'Root'}

mount /dev/sda1 /mnt                                      {Identify the partition by the well known & easy to use method.}
mount UUID=f1900c6d-9a84-4dbb-9e18-843d17cff29b /mnt      {Identify the filesystem by its UUID.}
mount PARTUUID=08eaf31c-b115-4e4c-bae4-7e2cb0bf8b9a /mnt  {Identify the partition by its partition UUID (PARTUUID).}
mount LABEL="My-FS-label" /mnt                            {Identify the required filesystem by its filesystem label.}
mount PARTLABEL="My-PARTITION-label" /mnt                 {Identify the required partition by its partition label.}

The equivalent 'fstab' entries using info from the following 'blkid' command. This one is for the main system drive on a Devuan system.
Note: I've added the filesystem and partition names using 'gparted'.

Code:

root@devuan:/home/bob# blkid | grep sda2 {Just the 'sda2' info.}

/dev/sda2: LABEL="Devuan-FS-Name" UUID="dd2bd7ae-b2de-464a-b1ae-3176db97dc39" 
BLOCK_SIZE="4096" TYPE="ext4" 
PARTLABEL="Devuan-Partition-Name" PARTUUID="b07e51d5-00d0-4316-9511-a8ea535d2ccf"

These lines are functionally equivalent.
'fstab' entries:

Code:

/dev/sda2	                                /       ext4    defaults,noatime     0        1
UUID=dd2bd7ae-b2de-464a-b1ae-3176db97dc39       /       ext4    defaults,noatime     0        1
PARTUUID=b07e51d5-00d0-4316-9511-a8ea535d2ccf   /       ext4    defaults,noatime     0        1
LABEL="Devuan-FS-Name"	                        /       ext4    defaults,noatime     0	      1
PARTLABEL="Devuan-Partition-Name"	        /       ext4    defaults,noatime     0        1

Next: Potential mounting & 'fstab' problems. Boot variables. 'grub.cfg'.
Workarounds, shortcuts and a few tips.

More soon.

B.

bodge99 · 04-05-2023, 08:37 AM

Part 2. Mounting and/or 'fstab' problems:

Using the following partition/filesystem as an example:

Code:

/dev/sda1: LABEL="My-FS-label" UUID="f1900c6d-9a84-4dbb-9e18-843d17cff29b"

BLOCK_SIZE="4096" TYPE="ext4" 

PARTLABEL="My-PARTITION-label" PARTUUID="08eaf31c-b115-4e4c-bae4-7e2cb0bf8b9a"

I'll assume theat the mountpoint ('/mnt') exists and is available.
Note: if anything is already mounted on '/mnt' then any existing directory contents will become unavailable (i.e. effectively 'hidden') by a second mount operation until this second one is unmounted. At this point, the original files/directories will become available again.

Code:

mount /dev/sda1 /mnt

This operation will succeed if 'sda1' exists and has a valid (known to the system) filesystem. It is possible for this command to mount the wrong filesystem if multiple filesystems exist.
Example: A system uses '/dev/sda1' in its 'fstab' to identify its EFI/ESP filesystem. A plugged in flashdrive is identified by the system as 'sdb1'.
If the system is rebooted with the flashdrive still connected then it's possible for the system to identify the flashdrive as 'sda1' and the EFI/ESP filesystem as 'sdb2'.
If this happened then the system would not boot. Oops!
The exact same problem can occur if two flashdrives are plugged into a system. On restart, the flashdrive previously detected as 'sdb1' may now be detected as 'sda1'. The user would need to check the flashdrive contents (or the filesystem label, if used) in order to ensure that the correct flashdrive was being accessed.

Code:

mount LABEL="My-FS-label" /mnt

Most systems are set up to automount specific filesystems and to display the filesystem label within GUI file managers. This can be very useful if sufficiently unique filesystem labels are used. This label will be displayed irrespective of how the flashdrive is mounted.

Code:

mount UUID=f1900c6d-9a84-4dbb-9e18-843d17cff29b /mnt

This is guaranteed to work, assuming that the filesystem is valid and is actually available to the system at the time the mount command is invoked.
It is important to ensure that filesystems with duplicate UUID's are not used concurrently within the same system. The results of any attempt to do this are undefined and is almost certainly not what is expected. More on this later.

Code:

mount PARTLABEL="My-PARTITION-label" /mnt
   {and}
mount PARTUUID=08eaf31c-b115-4e4c-bae4-7e2cb0bf8b9a /mnt

The use of these is much less frequent with Linux in the PC "universe". You'll see greater use of these (esp. 'PARTUUID') with SBC's (small board computers).

Note: If a filesystem is reformatted, the filesystem label is lost and the (filesystem) UUID is changed. The partition UUID (PARTUUID) and partition label remain.
If a partition is destroyed and recreated (and a new filesystem created), all labels are lost and both UUID's are changed.

Booting Problems:
Default Boot & Boot List: EFIVARS

Most operating system installation mechanisms will correctly modify the UEFI boot environment to favour the new installation. However, it is possible for mistakes to occur here.
It's also possible that the user may require specific changes.

An example follows. This is a Slackware installation that is used as a network media fileserver. The owner wanted a network system boot using Grub but keeping the default boot with 'elilo'. This allows some specific system checking scripts to be run in the event of power failure.

By default, Slackware uses 'elilo' for UEFI booting. Grub can be manually added if required. The default boot order is then changed to Grub.

The initial installation was performed in Virtualbox and transferred to the system after configuration was completed.

The installation has had Grub added: Output from 'efibootmgr'. Grub is the default boot manager at this time..

Code:

root@me:~# efibootmgr
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0006,0004,0000,0001,0002,0003,0005
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0){auto_created_boot_option}
Boot0002* UEFI VBOX HARDDISK VBd3685548-906b9c36 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,0,0){auto_created_boot_option}
Boot0003* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Slackware	HD(1,GPT,374fb40c-abe8-4c9e-81a2-6dbc781baa90,0x800,0x64000)/File(\EFI\Slackware\elilo.efi)
Boot0005* UEFI PXEv4 (MAC:080027F653C7)	PciRoot(0x0)/Pci(0x3,0x0)/MAC(080027f653c7,1)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option}
Boot0006* slackware-15.0+	HD(1,GPT,374fb40c-abe8-4c9e-81a2-6dbc781baa90,0x800,0x64000)/File(\EFI\slackware-15.0+\grubx64.efi)

Slackware
Boot into the shell and run:

Code:

        bcfg boot add 0 fs0:\EFI\Slackware\elilo.efi mySlackware

                             {or, depending on how your shell handles directory separators. }
                             
        bcfg boot add 0 fs0:/EFI/Slackware/elilo.efi mySlackware

This returns:

Code:

  Target = 0007
  bcfg: Add Boot0007 as 0

Note: For this example, the same thing can be performed from the running system using the 'eliloconfig' tool.

The modified bootvars are:

Code:

root@me:~# efibootmgr
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0007,0006,0004,0000,0001,0002,0003,0005
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0){auto_created_boot_option}
Boot0002* UEFI VBOX HARDDISK VBd3685548-906b9c36 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,0,0){auto_created_boot_option}
Boot0003* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Slackware	HD(1,GPT,374fb40c-abe8-4c9e-81a2-6dbc781baa90,0x800,0x64000)/File(\EFI\Slackware\elilo.efi)
Boot0005* UEFI PXEv4 (MAC:080027F653C7)	PciRoot(0x0)/Pci(0x3,0x0)/MAC(080027f653c7,1)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option}
Boot0006* slackware-15.0+	HD(1,GPT,374fb40c-abe8-4c9e-81a2-6dbc781baa90,0x800,0x64000)/File(\EFI\slackware-15.0+\grubx64.efi)
Boot0007* mySlackware	PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,0,0)/HD(1,GPT,374fb40c-abe8-4c9e-81a2-6dbc781baa90,0x800,0x64000)/File(\EFI\Slackware\elilo.efi)

This shows that Slackware was started using the EFI shell. The actual shell commands used are:-

Code:

fs0:
cd EFI
cd Slackware
elilo.efi

The default boot entry here is now 'Boot0007', labelled 'mySlackware', the bootloader used is 'elilo' and the EFI executable is 'elilo.efi'.
Note: There are now three entries that will start Slackware. Two from 'elilo.efi' and one from 'grubx64.efi'.
Any system changes from this point would not automatically update both 'elilo' entries. The original '0004' entry will soon become stale and non-functional.
I would normally delete this entry using

Code:

efibootmgr -B -b 0004

Note: Under certain circumstances it can be advantageous to delete all of the EFIVARS entries. It is safest to delete each entry separately.
e.g For a boot list having the following entries:

Code:

Boot0000  
Boot0001  
Boot0002    {Ignoring the actual text of each entry here.}
Boot2000  
Boot2002 
Boot2005

These would be deleted with:

Code:

efibootmgr -B -b 0000
efibootmgr -B -b 0001
efibootmgr -B -b 0002
efibootmgr -B -b 2000
efibootmgr -B -b 2002
efibootmgr -B -b 2005

This will now return a message similar to:

Code:

No BootOrder is set; firmware will attempt recovery

Note: The entry deletions can be performed in any order.

On system reboot, the Bios will repopulate the EFIVARS with default entries.
The required default boot entry can then be added (see the 'Grub' section, below, for an automated method.).

Next: Grub, 'grub.cfg', Direct kernel boot.

More soon.

B.

simiriti · 04-05-2023, 02:28 PM

If your Toshiba WT8-A netbook is not detecting any bootable Linux USB, there could be several reasons why this is happening. Here are some steps you can try to troubleshoot the issue:

Make sure that the USB drive is properly formatted and has a bootable Linux image. You can use a tool like Rufus to create a bootable USB drive.

Check if your netbook's BIOS is set to boot from the USB drive. To do this, restart your netbook and enter the BIOS settings by pressing the appropriate key (usually F2 or Delete) during startup. Look for the "Boot" or "Boot Order" section and make sure that the USB drive is listed as the first boot device.

Try using a different USB drive or a different Linux image. Sometimes, USB drives can become corrupt or damaged, which can cause boot issues.

Make sure that Secure Boot is disabled in your netbook's BIOS settings. Secure Boot is a security feature that can prevent booting from unauthorized operating systems.

If none of the above steps work, you can try updating your netbook's BIOS firmware to the latest version. You can usually download the latest firmware from Toshiba's website.

If none of these steps solve the issue, it's possible that there may be a hardware problem with your netbook's USB ports. In that case, you may need to take your netbook to a professional technician for further diagnosis and repair.

beachboy2 · 04-06-2023, 11:32 AM

This all looks horribly familiar and just like my hybrid ASUS T100T with its famous missing bootia32.efi file:

https://www.linuxquestions.org/quest...d-linux-38954/

NB If the Toshiba Encore 2 and WT8-A models also use a Broadcom wifi card, then I strongly advise using MX Linux 21.3, which should recognise this card automatically.

Post #7 appears to show that once the missing bootia32.efi file is loaded, then Ubuntu etc can be installed on the Toshiba Encore 2 (OEM: W8.1 32-bit):
https://forum.ubuntu-fr.org/viewtopic.php?id=2054775

[SOLVED] UBUNTU installation on Toshiba Encore 2 tablet.

J'ai réussi c'est bon.
1. J'ai téléchargé l'iso xubuntu 20.04
2. J'ai téléchargé ce fichier : https://github.com/jfwells/linux-asus-t … otia32.efi
3. J'ai mit L'iso d'Ubuntu sur ma clé USB grâce a Unetbootin
4. J'ai mit le fichier téléchargé "bootia32.efi" sur ma clé dans le dossier /EFI/BOOT
5. installation sans pb
Il me reste à trouver un clavier virtuel et voir pour la rotation d'écran mais le plus dur est fait
Merci à lucmars d'avoir orienté mes recherches vers : https://forum.ubuntu-fr.org/viewtopic.php?id=1489691

Translation:

I succeeded it's good.
1. I downloaded the xubuntu 20.04 iso
2. I downloaded this file: https://github.com/jfwells/linux-asus-t … otia32.efi
3. I put the Ubuntu iso on my USB key thanks to Unetbootin
4. I put the downloaded file "bootia32.efi" on my key in the folder /EFI/BOOT
5. problem-free installation

I still have to find a virtual keyboard and see for the screen rotation but the hard part is done.
Thanks to lucmars for directing my research to: https://forum.ubuntu-fr.org/viewtopic.php?id=1489691

bodge99 · 04-06-2023, 11:44 AM

Part 3. Grub booting, direct kernel boot.

The purpose of 'grubx64.efi'/'shimx64.efi' is to start the Linux kernel. Grub uses a configuration file which can normally be found at '/boot/grub/grub.cfg'.
Some distros (e.g. Suse Linux) use '/boot/grub2/grub.cfg'. The reasons for any differences are normally historic. The overall functionality is identical.

'grub.cfg': This is a text file which can be viewed or edited with any basic text editor. Editing this file is normally discouraged. The primary reason for this is that alterations are normally made to other, supporting files and the system 'grub.cfg' file is regenerated using this new information. This requires a running system or one that is 'chroot'ed to another running system.

'grub.cfg' header:

Code:

bob@bob-VirtualBox:~$ cat /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

This file is normally regenerated automatically every time there is a kernel update etc. This operation can be performed manually, if required.

However, there is at least one valid reason why you would want to edit this file directly..
Further details below, but briefly.. If a system is moved from one filesystem to another (the new filesystem will have a different UUID) then the system 'fstab' and 'grub.cfg' will then need to be altered.

Most 'grub.cfg's are quite long.. it used to control the bootloader and to prepare the initial boot environment to suit specific requirements.
From the perspective of "I just need to boot a problematic system ***RIGHT NOW***", the essence of the 'grub.cfg' can be reduced to this:

Code:

      set root=(hd0,2)
      linux /boot/vmlinuz root=/dev/sda2
      initrd /boot/initrd.img

The first line sets the root partition for Grub. This 'root' is a Grub variable. This one is the second partition on the first hard drive. (Drives count from 'zero' and partitions from 'one'. This is a Grub convention).

The second line provides the location and name of the Linux kernel. The system root is identified specifically. Although this location is the same as the 'root=(hd0,2)' statement, the root partition is specified here according to the Linux naming convention ('/dev/sda2'). This variable is passed directly to the kernel.

The third line identifies the location and name of the system 'initrd'.

There can be potential problems when trying to use this file directly. The user would have to ensure that the drive and partition designations are correct. The kernel and initrd names and locations must also be accurate.

File accuracy can be improved by the use of UUID's and Grub partition/filesystem search facilities. For optimal accuracy, this implies the use of the full Grub environment. This further implies, for guaranteed functionality, that an external device is used. A USB device such as a flashdrive or an external hard drive in a caddy is perfect for this purpose..

Typical minimal 'grub.cfg' when used from an external device:

This is an alternative basic 'grub.cfg':
This one directly calls an existing system 'grub.cfg'.
Here, 'root' and 'prefix' are Grub variables.

Code:

      set root=(hd0,2)
      set prefix=($root)/boot/grub
      configfile $prefix/grub.cfg

Both of these 'grub.cfg' file contents could be typed directly into a system that is displaying the Grub prompt (more on this later), but better versions will be discussed in the next post.

Next: External rescue device. Kernel handling. Kernel (et. al.) transplant. Initrd modifications, cloning/copying & moving systems.

More soon.

B.

bodge99 · 04-06-2023, 11:53 AM

I've just received an email from somebody on this forum.

The tone of this email is quite nasty.. This person is complaining about the scope of the recent posts that I have made here.

I've written these posts for a couple of reasons.. I'm keeping everything in one location.. and, if this stuff only helps one person then I'm more than happy.

I must admit, I'm a little upset by this. I would have thought that if any particular person isn't interested in my posts, then they just wouldn't bother reading them.

I'm just trying to help folk..

I'll just leave it at this point.

B.

beachboy2 · 04-06-2023, 01:30 PM

bodge99,

That is unacceptable.

Report it.

boughtonp · 04-07-2023, 09:17 AM

Bodge, most people no doubt appreciate your help, (whether they've received it already or discover your posts in future).

Assuming the person wasn't Jeremy (site owner) or michaelk (section moderator), then you're free to ignore them, tell them to get stuffed, and/or remind them of the unsubscribe function. (And if their message violated LQ Rules, report them to Jeremy.)

However, I have been considering suggesting that what you're posting might be better suited to blog posts, where things can be better organized - since you can tag individual posts, more easily link next/previous posts/articles to each other, etc - and of course can still reference and/or summarize articles when relevant for this (or any other) thread.

https://www.linuxquestions.org/questions/blog/

If you're not sure, there's options to control who can see the blog, so you can keep things private whilst experimenting, then later open them up if you decide to make use of it.

beachboy2 · 04-07-2023, 09:37 AM

boughtonp,

I totally agree with your suggestion for bodge99 to assemble his various posts in a group of individual blogs within a main LQ blog.

More people can benefit from viewing a complete blog as opposed to a string of posts to multiple threads.

LassClueless · 04-23-2023, 11:43 AM

Dear Bodge,

I'm so hoping you're still following this conversation, despite the unpleasant email, as I would really appreciate (yet more of) your help, please.

I took your advice and decided to give AntiX Linux a try. I followed your instructions and created an installation USB (using the 64-bit version, yes?), then I thought I would be a big brave girl and try to install it all on my own, without waiting for/asking for any instructions you chose to post after receiving the mean email.

And, amazingly, I seem to have got it to install! Only I can't work out how to connect to wi-fi, or get the keyboard to appear (the touchscreen seems to work, although I've not tried to do much with it, and it recognises a USB keyboard too), or to get the screen to rotate. Maybe there's other stuff that's not working either but I've not spent enough time playing around to discover what it is/they are yet. If, despite everything, you are still involved in this forum, I'd really appreciate your help (again), please.

Clueless

ps I'm sorry for dropping out of the conversation for so long, but the day before my brother's funeral my dad was told the cancer he was treated for five or so years ago had returned and - this time - couldn't be fixed, and he had months left to live. Only it turned out to be weeks... (I wish I was making this up but, unfortunately I'm not!) On the upside, though, a bit of the part of my brain that had been given over to worrying about him then became free to think about sorting my tablet, so every cloud and all that...