This is an Asus X102BA system which I recently installed but discovered it only boots from an USB stick. I used a 32-bit offline media to install TW.
It looks like this machine can boot from an USB stick in either legacy (TW offline media) or UEFI mode (rEFInd). From disk it can boot in UEFI mode (previous Manjaro installation, rEFInd installed to disk). I’m not sure whether it can boot in legacy mode from disk whether MBR or GPT.
After installing and noticing the issue, I did two things in attempt to get things working:
Remove the protective MBR flag from HDD – it was preventing the system from seeing the EFI entries.
Install grub2-x86_84-efi and then grub2-install --target x86_64-efi /dev/sda (first I used i386-efi), then grub2-mkconfig – I assume something didn’t go quite right in this step
At this point booting from HDD, I get to GRUB menu but then TW gets stuck as the title says. I can select and boot Manjaro to desktop, it boots in UEFI mode.
Booting from USB:
$ ls -l /sys/firmware/
drwxr-xr-x 5 root root 0 mai 18 18:49 acpi
drwxr-xr-x 2 root root 0 mai 18 18:49 devicetree
drwxr-xr-x 3 root root 0 mai 18 18:47 dmi
drwxr-xr-x 22 root root 0 mai 18 18:49 memmap
$ ls -lh /boot/efi/EFI/*
-rwxr-xr-x 1 root root 121K abr 5 2018 bootx64.efi
-rwxr-xr-x 1 root root 121K abr 5 2018 grubx64.efi
-rwxr-xr-x 1 root root 312K mai 14 00:10 grubx64.efi
-rwxr-xr-x 1 root root 144 mai 13 23:32 BOOT.CSV
drwxr-xr-x 2 root root 4,0K mai 13 23:25 drivers_x64
drwxr-xr-x 2 root root 8,0K mai 13 23:32 icons
drwxr-xr-x 2 root root 4,0K mai 13 23:25 icons-old
-rwxr-xr-x 1 root root 34K mai 13 23:32 refind.conf
-rwxr-xr-x 1 root root 249K mai 13 23:25 refind_x64.efi
drwxr-xr-x 2 root root 4,0K mai 13 23:32 vars
$ sudo parted -l
Model: ATA TOSHIBA MQ01ABF0 (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 boot, legacy_boot, esp
2 538MB 2149MB 1611MB linux-swap(v1) swap
3 2149MB 2685MB 537MB ext2
4 2685MB 110GB 107GB ext4
5 110GB 110GB 8389kB bios_grub
6 110GB 314GB 204GB btrfs
7 314GB 316GB 2148MB linux-swap(v1) swap
Model: SanDisk Ultra USB 3.0 (scsi)
Disk /dev/sdb: 30,8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1765kB 4593MB 4591MB primary boot, hidden, type=17
sudo fdisk -l
Disk /dev/sda: 298,09 GiB, 320072933376 bytes, 625142448 sectors
Disk model: TOSHIBA MQ01ABF0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: A068EDFC-AF0F-438A-9BFF-C8EA96A962AD
Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 4196351 3145728 1,5G Linux swap
/dev/sda3 4196352 5244927 1048576 512M Linux filesystem
/dev/sda4 5244928 214960127 209715200 100G Linux filesystem
/dev/sda5 214960128 214976511 16384 8M BIOS boot
/dev/sda6 214976512 612558847 397582336 189,6G Linux filesystem
/dev/sda7 612558848 616753839 4194992 2G Linux swap
Disk /dev/sdb: 28,64 GiB, 30752636928 bytes, 60063744 sectors
Disk model: Ultra USB 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x705341b1
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 3448 8970239 8966792 4,3G 17 Hidden HPFS/NTFS
Yes, the same routine. Although efivars weren’t loaded, modprobe efivars failing due to lack of modules, so I used --no-nvram in grub2-install.
There’s an option Legacy USB Support, disabling it makes the TW 32-bit media inaccessible. Plugging a rEFInd media shows as both UEFI and non-UEFI options so it must be an issue with TW media or this machine BIOS/UEFI implementation.
It’s good to know that grub from Arch/Manjaro still works. Maybe I should try using that.
I have tw32 installed in a VM and booting with UEFI. This used to work well until last summer. Then some changes to grub2 left it unable to boot that way. I complained about that in bug 1177009.
It seems that grub2-*-efi now forces the grub “linux” command to actually use the “linuxefi” command. And that breaks loading tw32.
At present, I am using “grub2-x86_64-efi-2.04-16.1.noarch.rpm” from last August (the last version before that change was made). But I’m pretty sure that “grub2-x86_64-efi-2.04-lp220.127.116.11.noarch.rpm” from Leap 15.2 will also work. Note that this is not the latest version on Leap 15.2, but should still be in the repos.
I actually have the latest grub2-x86_64-efi installed at the system level for that tw32 system. But I keep a copy of “/usr/share/grub2/x86_64-efi” from the earlier version. I actually have that in “/usr/local/share/grub2/x86_64-efi”. And then if I need to setup booting again, I use the “–directory” option to select that older directory when running “grub2-install”.
My suggestion: Install “grub2-x86_64-efi-2.04-lp18.104.22.168.noarch.rpm” from Leap 15.2, and then save a copy of the directory “/usr/share/grub2/x86_64-efi” elsewhere for future use.
Yes, I actually have “grub2-i386-pc” installed for MBR booting, but that doesn’t do anything on a system that uses UEFI. But it does keep Tumbleweed happy. When an update requires reinstalling booting, it reinstalls the MBR booting (which still doesn’t do anything). From time to time I check whether the latest grub2-x86_64-efi will boot the system, but that always fails and I have to revert to the older grub2 version for that.
And here’s it running, although with missing capabilities:
$ dmesg | grep -iw efi
0.000000] efi: EFI v2.31 by American Megatrends
0.000000] efi: ACPI=0x5c3f0000 ACPI 2.0=0x5c3f0000 SMBIOS=0xf04c0
0.000000] efi: No EFI runtime due to 32/64-bit mismatch with kernel
0.057160] efi: Setup done, disabling due to 32/64-bit mismatch
7.474768] fb0: EFI VGA frame buffer device
10.745815] fb0: switching to radeondrmfb from EFI VGA
I tried i386-efi before but it seems unsupported, or possibly buggy? The 32-bit loader seems invisible jumping to BIOS setup instead while the 64-bit loader at least printed something to screen.
At least it used to, at the time this system was first installed 3 years ago. Unfortunately the OS prober didn’t work which could help with this case.
That was the trick it seems, as it can be seen from the output above. I almost messed up, because it didn’t work immediately. I guess I forgotten to refer to the 64-bit grub version, so when I updated to point to grubx64.efi then it works. Thanks Mr Rickert!
Before fixing I attempted to boot with a Leap 15.2 thumb drive. It boots in UEFI mode and could be used to be installed this way on this system. But booting linux system gives gives “Sorry, cannot boot system” or something. TW 32-bit media is less capable as it can only boot in legacy mode.
This is a machine with 1,4GB of RAM. I tested out Xfce/Gnome/KDE in VMs, and in all of them the 32-bit version used ~200MB less RAM once booted up. So I decided for Xfce 32-bits and I set up zRAM. The intended usage is for LibreOffice, Google Meet, webmail mostly. I may consider switching to the 64-bit overall, it might be able to afford the extra RAM usage. I hope I can perform a benchmark to understand if it runs smoother under 64-bit. I don’t miss any software only compiled for 64-bit. Thoughts?