SliTaz Forum
You are not logged in.
Press the hot key to launch the EFI boot menu. Maybe F7 or F2 ...
Offline
hi @Bellard,
I can't get to UEFI shell on my Lenovo Ideapad 320s. My finding so far is that it either needs UEFI shell from external USB or UEFI shell can be enabled with special Lenovo software.
But I've run tests with more HW: I've tried a couple of regular Dell laptops (e6510 and latitude e5520). Result is still the same - no bootable media found when I switch booting to the UEFI mode.
Funny enough, after switching to UEFI mode, it's possible to point to a specific file to boot from (see the image I attached). I do point to the startup.nsh but with the same result - it starts with no bootable media found error. Just in case it could trigger any thought on your end.
Well, next thing I'll try to get to UEFI shell either on Lenovo or one of the Dells.
p.s. Sorry, messed up attachments - should be just 2 files.
Offline
Can you retry with http://mirror1.slitaz.org/iso/rolling/slitaz-core-5in1.iso (2018-May-30 12:07:11) ?
GPT support is reworked see http://hg.slitaz.org/wok/rev/f582dbc28a10
'# parted -l' and '# fdisk -l' are happier with it
Offline
I just tried it on 3 different laptops - no luck, still not seen at boot up.
With the new image I see now that there's only 1 partition available for mounting - with the UEFI content one. Previously there was 2 partitions. Though [c]file[/c] shows it does have MBR.
[c]file slitaz-core-5in1.iso
slitaz-core-5in1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 124927 sectors[/c]
Offline
$ fdisk -l slitaz-core-5in1.iso
Found valid GPT with protective MBR; using GPT
Disk slitaz-core-5in1.iso: 123788 sectors, 60.4M
Logical sector size: 512
Disk identifier (GUID): 9ca50087-dce8-470b-5ee5-b33aae3550a2
Partition table holds up to 4 entries
First usable sector is 34, last usable sector is 124894
Number Start (sector) End (sector) Size Name
1 172 122687 59.8M EFI System Partition
$ parted -s slitaz-core-5in1.iso print
Erreur: end of file while reading /home/tux/Downloads/slitaz-core-5in1.iso
Modèle: (file)
Disque /home/tux/Downloads/slitaz-core-5in1.iso : 63,4MB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : unknown
Disk Flags:
$ # Ensure image is large enough
$ dd if=/dev/zero bs=1k count=1024 >> slitaz-core-5in1.iso
1024+0 records in
1024+0 records out
1048576 bytes (1.0MB) copied, 0,018728 seconds, 53.4MB/s
$ parted -s slitaz-core-5in1.iso print
Erreur: La sauvegarde de table GPT est corrompue mais l'originale semble valide et sera donc utilisée.
Avertissement: Il semble que l'espace disponible sur /home/tux/Downloads/slitaz-core-5in1.iso ne soit pas totalement utilisé, voulez-vous ajuster la table GPT pour utiliser tout l'espace (908 blocs en plus) ou continuer ainsi ?
Modèle: (file)
Disque /home/tux/Downloads/slitaz-core-5in1.iso : 64,4MB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Disk Flags:
Numéro Début Fin Taille Système de fichiers Nom Fanions
1 88,1kB 62,8MB 62,7MB fat16 EFI System Partition démarrage, esp
Offline
I think all bits have come together now.
In order to run startup.nsh you need to have UEFI shell. UEFI shell can be either in 1) EFI System Partition (ESP) or 2) in chipset build-in one (I understood it's rare).
What we both tried with virtual environment is something that has built-in UEFI shell.
My laptops have completely clean hard drives i.e. no any ESP hence nothing to run startup.nsh
I created an empty USB with fat32 and UEFI shell as \EFI\Boot\bootx64.efi on it. I put Slitaz USB in one slot and the UEFI shell USB in the other slot and all boots just fine. So one USB boots into UEFI shell and finds the other USB with startup.nsh and runs it in 5 sec.
UEFI shell was downloaded from here: https://github.com/tianocore/edk2/blob/master/ShellBinPkg/UefiShell/X64/Shell.efi?raw=true
This one was quite helpful: https://superuser.com/questions/1057446/how-to-boot-to-uefi-shell?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
So, does it make sense to place the UEFI shell renamed as bootx64.efi next to the startup.nsh when making the Slitaz image?
Offline
The EFI shell is not used anymore since http://hg.slitaz.org/wok/rev/99a7a1e955d4 and http://hg.slitaz.org/tazlito/rev/035c08dd4580
\EFI\Boot\bzImage64 is renamed as \EFI\Boot\bootx64.efi
Can you try again with http://mirror1.slitaz.org/iso/rolling/slitaz-core-5in1.iso (2018-Jun-03 04:43:03) ?
Offline
Success loading the image now(!) but with some minor glitches.
It gives few errors in the beginning: "failed to open file: efi\boot\linux.cmdline64" and "failed to open file: efi\boot\rootfs[5,4,3,2].gz64". I've attached a picture.
And then after approx 5 seconds the Linux kernel and the system boots up just fine.
Is it real errors?
Offline
pictures to the previous post.
[attachment=46371,2685] [attachment=46371,2686]
Offline
It's not real errors.
64 kernels look for <file>64 and fallback to <file>
see http://hg.slitaz.org/wok/file/99a7a1e955d4/linux/stuff/linux-efi.u#l85 and
http://hg.slitaz.org/wok/file/99a7a1e955d4/linux/stuff/linux-efi.u#l34
In your case it load :
EFI\BOOT\linux.cmdline
EFI\BOOT\rootfs5.gz
EFI\BOOT\rootfs4.gz
EFI\BOOT\rootfs3.gz
EFI\BOOT\rootfs2.gz
EFI\BOOT\rootfs1.gz64
Thanks for the report.
Offline
The next weekly build will hide these useless error messages.
http://hg.slitaz.org/wok/rev/5546d3d1350b
PS: can some mac user test EFI boot ?
Offline
thanks @bellard
I've got access to few macs, I'll be able to try those at some point this week.
Now, if I need custom version of linux.cmdline - do I just put one in addfiles/bootcd/efi/boot or would I need to use customized version of tazlito script for that?
There's 2 versions of the kernel and kernel modules: x86 and 64. Does linux-kernel Slitaz package now has 2 versions i.e. bzImage and bzImage64 and the modules? What Slitaz packages would I need to install to build custom bzImage64 with the modules?
Offline
Since tazlito 511 you can put your custom version of linux.cmdline in addfiles/bootcd/efi/boot
See http://hg.slitaz.org/tazlito/rev/e11610f472bf
The packages linux-* install 32 bits kernel/modules.
The packages linux64-* install 64 bits kernel/modules.
You should need linux64-* only, but your can install both anyway.
See http://hg.slitaz.org/flavors/file/70537525b9ae/preinit/packages.list
http://hg.slitaz.org/flavors/file/70537525b9ae/preinit
Offline
Hi @bellard,
Thanks a lot for fixing the linux.cmdline file and the explanation.
The image I build initiates booting up just fine but then stops at starting udevd. Can you have a look please - you can probably spot it immediately? I've tried Lenovo laptop and VBox machine - same behavior.
I'm using justx Slitaz flavor, attaching a list of the packages - can it be that some package is missing for linux64? Linux64 is not the native package to justx flavor.
Would you recommend using a different flavor - all I need is the very basic system with GUI?
Btw, when I'm building the image, I get some syslinux package errors - don't fully understand the true reason for those.
My Slitaz is fully up to date, using latest tazlito 512.
[attachment=46384,2696] [attachment=46384,2697] [attachment=46384,2698]
Offline
Ok, I now more or less know what the problem and where to dig.
Nevertheless, the syslinux error still remains - if I use my set of older Slitaz packages, then the image is built without that error. The error shows up only if I use the latest set of the Slitaz packages so I wonder if it's the package's content that's wrong, not the tazlito or other system scripts.
Offline
well, I figured out what the problem is but haven't been able to solve it so far.
There's a problem with Xorg and UEFI, so Xorg won't start with UEFI.
Problem similar to this https://bugzilla.redhat.com/show_bug.cgi?id=977816 or this https://github.com/NixOS/nixpkgs/issues/10381
I've played with nomodeset though without luck.
The actual Xorg error is:
[c][ 14.806] (II) VESA(0): initializing int10
[ 14.807] (EE) VESA(0): V_BIOS address 0x0 out of range[/c]
So if somebody has any clue, please shout.
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.57 MiB (Peak: 1.77 MiB) ]