SliTaz Forum
You are not logged in.
Hi,
I'm trying to create a bootable ISO using [c]tazlito[/c], justx flavor and syslinux/isolinux bootloader.
Doing that I ended up reading [c]tazlito[/c] script and I can see that it expects files in the rootcd/efi/boot folder.
The problem is that the [c]tazlito[/c] script throws an error when I place files there while trying to allocate/create uefi.img:
===========
[c]Try 'stat --help' for more information.
stat: invalid option -- 'm'
Try 'stat --help' for more information.
awk: cmd. line:26: for (i=s,e=2; i<n; i++) {
awk: cmd. line:26: ^ syntax error
awk: cmd. line:26: for (i=s,e=2; i<n; i++) {
awk: cmd. line:26: ^ syntax error
stat: invalid option -- 'm'
Try 'stat --help' for more information.
stat: invalid option -- 'm'
Try 'stat --help' for more information.
/usr/bin/tazlito: line 429: ( - )*4: syntax error: operand expected (error token is ")*4")[/c]
===========
My guess is that the default shebang in the script /bin/sh assumes certain shell. Which one is that? Or is it just a bug in the [c]tazlito[/c] script?
Anyway is there any doc how to prepare UEFI iso with [c]tazlito[/c]?
Offline
I've managed to fix the errors by using busybox version of stat and awk i.e. I added in the beginning of the [c]tazlito[/c] script:
[c]...
alias stat='busybox stat'
alias awk='busybox awk'
...[/c]
And I also had to replace all '[c]stat -m[/c]' to '[c]busybox stat -m[/c]'. That fixed all the errors.
I don't know if the authors would be willing to accept these fixes to the script.
Thought still trying to make my ISO work with EFI computers.
Offline
Thanks, that was fast 
Offline
I got syslinux to start on EFI machine from the [c]tazlito[/c] generated efi.img.
The problem now is that it wants both the bzImage and the rootfs.gz files in the efi.img.
Is there a way to keep syslinux only files in the efi.img (i.e. /efi/boot) and access /boot/bzImage and /boot/rootfs.gz files i.e. share the image and the initrd between regular boot and UEFI boot?
Ping @bellard or somebody else please...
Offline
While I'm not sure if it's possible to access /boot/bzImage and /boot/rootfs.gz when booting into EFI partition, I'm trying to place both files in the /efi/boot folder to have them in the efi.img EFI partition.
The problem is that the filesystem on the efi.img seems to get corrupted whenever I place more than just a few megs on it. For instance, running filesystem check on it gives:
[c]fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
/EFI
Directory has non-zero size. Fixing it.
/EFI/.
Directory has non-zero size. Fixing it.
/EFI/..
Directory has non-zero size. Fixing it.
/EFI/BOOT
Directory has non-zero size. Fixing it.
/EFI/BOOT/.
Directory has non-zero size. Fixing it.
/EFI/BOOT/..
Directory has non-zero size. Fixing it.
/EFI/BOOT/V64
File size is 0 bytes, cluster chain length is > 0 bytes.
Truncating file to 0 bytes.
/EFI/BOOT/VESAMENU.C32
File size is 32400 bytes, cluster chain length is 2048 bytes.
Truncating file to 2048 bytes.
/EFI/BOOT/LIBUTIL.C32
File size is 24456 bytes, cluster chain length is 2048 bytes.
Truncating file to 2048 bytes.
Reclaimed 26 unused clusters (53248 bytes).
Perform changes ? (y/n) y
efi.img: 11 files, 34526/34552 clusters[/c]
Trying to read the vesamenu.c32 and libutil.c32 files in this case throws "Input/output error".
I see that the [c]fixup_uefi_part()[/c] function from the [c]tazlito[/c] script modifies the efi.img file directly but then does it break it? Is this a known issue?
Offline
@st_user
dont think that efi class2 (meaning no CSM/legacy option) will be supported in taz wizard installer before 2019.....
you can try to see out with debian-likes or redhat-likes if you can't turn out uefi off or csm/legacy on (i have to test on my side) but in fact if it's a time problem go on another distro, slitaz is not ready (and we're lookin for that enhancement since maybe 2015/16) so wait months or get a temporary distro, while devs are doing their work.
Offline
thanks @lm2.
I don't really need to install Slitaz anywhere, all I need is a bootable ISO. Also I'm not hoping to get wizard working, trying to fix native [c]tazlito[/c] script.
Offline
it did the trick with fixing the filesystem, thanks @bellard! The situation now is that I don't seem to get corrupted files but once I place rootfs.gz to the efi partition, it stops booting or finding the syslinux config file when booting from USB stick. I did some googling and I understood the efi partition doesn't have some booting tokens/flags. Does it make sense? Can it loose it?
In other words, if I place only the bzImage and the basic bootloder files to addfiles/rootcd/efi/boot then I see the following in the result efi.img
[c]-rwxr-xr-x 1 root root 172.1K Jan 1 1980 BOOTX64.EFI
-rwxr-xr-x 1 root root 4.7M Jan 1 1980 BZIMAGE
-rwxr-xr-x 1 root root 131.3K Jan 1 1980 LDLINUX.E64
-rwxr-xr-x 1 root root 192.7K Jan 1 1980 LIBCOM32.C32
-rwxr-xr-x 1 root root 23.9K Jan 1 1980 LIBUTIL.C32
-rwxr-xr-x 1 root root 31.0K Jan 1 1980 MENU.C32
-rwxr-xr-x 1 root root 1.1K Jan 1 1980 SYSLINUX.CFG
-rwxr-xr-x 1 root root 31.6K Jan 1 1980 VESAMENU.C32[/c]
The system boots from a USB stick - I've attached a picture. Like I mentioned earlier, the problem there is that there seems to be no way to access the rootfs.gz then.
If I add the rootfs.gz file to the addfiles/rootcd/efi/boot, then the result efi.img is this:
[c]-rwxr-xr-x 1 root root 172.1K Jan 1 1980 BOOTX64.EFI
-rwxr-xr-x 1 root root 4.7M Jan 1 1980 BZIMAGE
-rwxr-xr-x 1 root root 131.3K Jan 1 1980 LDLINUX.E64
-rwxr-xr-x 1 root root 192.7K Jan 1 1980 LIBCOM32.C32
-rwxr-xr-x 1 root root 23.9K Jan 1 1980 LIBUTIL.C32
-rwxr-xr-x 1 root root 31.0K Jan 1 1980 MENU.C32
-rwxr-xr-x 1 root root 62.4M Jan 1 1980 ROOTFS.GZ
-rwxr-xr-x 1 root root 1.1K Jan 1 1980 SYSLINUX.CFG
-rwxr-xr-x 1 root root 31.6K Jan 1 1980 VESAMENU.C32[/c]
And this is when the system stops booting and gives the black screen with "No default or UI directive found" message. I've attached a screen as well.
I do run [c]diff[/c] on all the files between the addfiles/rootcd/efi/boot ones and the ones from the mounted efi.img on the mounted usb stick and all files give no difference, so the files don't seem to be corrupted. Can something indeed happen to the efi partition? I'm out of ideas at this moment. I'm thinking of trying grub instead of syslinux loader but I'm not sure it's the issue.
[attachment=46243,2661] [attachment=46243,2662]
Offline
hey @bellard, you've added some improvements! Any chance it's possible to fix fat16 as well?
Offline
Try the lastest tazlito : fat12 (up to 16M) *and* fat16 (up to 250M) should be ok.
Offline
Hmm, no luck, almost same behavior. Syslinux starts just fine without the big file in EFI image. But if I put the big file there, then nothing happens and then laptop reboots back to the Boot menu almost immediately (doesn't show any text) though the device is seen correctly as EFI Bootable USB device in the menu.
I've tried both latest commits i.e. the one you pointed to (5d84fadfd928) and the last one with the fat32 support.
Thanks @bellard for helping with this.
Offline
Remove addfiles/rootcd/efi tree and rebuild the iso image.
Tazlito uses startup.nsh and the linux embedded loader. It doesn't need any other efi loader.
Offline
@bellard, I removed the addfiles/rootcd/efi folder. When the image is generated, I see that all the partitions are created correctly i.e. MBR partitions, EFI partitions and Apple partitions. But when I [c]dd[/c] the image to the USB stick, the laptop doesn't see it as a bootable device so basically I can't boot from USB with this image.
To get the latest [c]tazlito[/c] script, I pull the repo (http://hg.slitaz.org/tazlito) and copy the script to /usr/bin/tazlito. Is this ok? Or do I need to update my system to the latest state with the [c]tazpkg[/c] ?
I don't know much about this, so to boot from startup.nsh (btw the script doesn't have executable flag on the image, I don't know if it matters) - does the kernel need to be enabled for that (you've mentioned linux embedded loader)? I wonder if this can be the issue.
I have 2 custom kernels but they both are based on the Slitaz config (I added more drivers). So the image with the kernel 4 behaves the way I described - UEFI laptop doesn't see the bootable USB stick.
After trying to generate the image with kernel 3 (which basically Slitaz based one), I get an error when build the image:
[c]Copying addfiles content to the rootfs... [ Done ]
Root filesystem is generated... [ Done ]
Preparing the rootcd directory... [ Done ]
Moving the boot directory... [ Done ]
Copying addfiles content to the rootcd... [ Done ]
6638 Kbytes saved in 209 duplicate files.
446 duplicate symlinks.
Creating initramfs with lzma compression...
Filesystem size: 59M
0 Kbytes saved in 0 duplicate files.
0 duplicate symlinks.
/usr/bin/tazlito: line 3279: arithmetic syntax error[/c]
What am I dong wrong?
Offline
Can you dd your USB stick with http://mirror1.slitaz.org/iso/rolling/slitaz-rolling-core64.iso or
http://mirror1.slitaz.org/iso/rolling/slitaz-core-5in1.iso (built on 2018-May-20) and boot your laptop ?
I have tested both with qemu only:
$ qemu-system-x86_64 -m 512 -bios /usr/share/qemu/x64/OVMF.fd -cdrom slitaz-rolling-core64.iso
$ qemu-system-x86_64 -m 512 -bios /usr/share/qemu/x64/OVMF.fd -hda slitaz-rolling-core64.iso
If the boot is ok, you should upgrade the syslinux-extra package to get /usr/bin/isohybrid up to date.
/efi/boot in the iso image is not used; it reflects /boot/isolinux/efi.img vfat content where any file has the executable flag.
Offline
Ok, I've just tried both http://mirror1.slitaz.org/iso/rolling/slitaz-rolling-core64.iso and http://mirror1.slitaz.org/iso/rolling/slitaz-core-5in1.iso
Same result - it's not seen by the laptop boot manager as a bootable device.
Right, makes perfect sense now what you're saying about the executable flag.
Please, don't hesitate to ask me to try something or let me know otherwise how I can be helpful to get this to work.
Offline
me too, i'm available to confirm if an iso is able to boot an uefi system (no csm/legacy, on usb gpt filesystem)
Offline
Can you dd your USB stick with http://mirror1.slitaz.org/iso/rolling/slitaz-core-5in1.iso (2018-May-24 11:38:00) ?
The boot time may be a bit long.
Offline
Great.
root@slitaz:~# uname -a
Linux slitaz 3.16.55-slitaz64 #2 SMP Mon May 21 20:31:03 CEST 2018 x86_64 GNU/Linux
root@slitaz:~# ls -l /sys/firmware/efi
total 0
-r--r--r-- 1 root root 4096 May 24 16:11 config_table
dr-xr-xr-x 2 root root 0 May 24 16:11 efivars
-r--r--r-- 1 root root 4096 May 24 16:11 fw_vendor
-r--r--r-- 1 root root 4096 May 24 16:11 runtime
drwxr-xr-x 5 root root 0 May 24 16:11 runtime-map
-r-------- 1 root root 4096 May 24 16:11 systab
root@slitaz:~# slitaz
SliTaz GNU/Linux
================================================================================================================================
Release : 5.0
Architecture : i486
Kernel : 3.16.55-slitaz64
Machine type : x86_64
Home path : /home/slitaz
Configs : /etc/slitaz
Main config : /etc/slitaz/slitaz.conf
Log files : /var/log/slitaz
Packages DB : /var/lib/tazpkg
Installed : 280 packages
Mirror : http://mirror1.slitaz.org/packages/cooking/
System date : Thu May 24 16:11:58 UTC 2018
--------------
Boot options : \EFI\BOOT\vmlinuz-3.16.55-slitaz64.efi rw root=0x100 autologin initrd=\EFI\BOOT\rootfs5.gz initrd=\EFI\BOOT\rootfs4.gz initrd=\EFI\BOOT\rootfs3.gz initrd=\EFI\BOOT\rootfs2.gz initrd=\EFI\BOOT\rootfs1.gz64
================================================================================================================================
root@slitaz:~# blkid /dev/sr0
/dev/sr0: UUID="2018-05-24-11-37-58-00" LABEL="SliTaz core-5in1" TYPE="iso9660" PTUUID="5b0687f7" PTTYPE="dos"
root@slitaz:~# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 1.5G 244.0K 1.5G 0% /run
tmpfs 2.7G 176.7M 2.5G 7% /
devtmpfs 1.4G 0 1.4G 0% /dev
tmpfs 1.5G 0 1.5G 0% /dev/shm
tmpfs 1.5G 4.0K 1.5G 0% /var/lock
[attachment=46336,2671]
Offline
hi @Bellard, no success on my end - I've tried both of my UEFI bootable devices. It's still the same issue - boot manager doesn't even see USB stick.
Funny enough, it does boot on my VBox which is set to EFI bootable mode. Btw this image boots much faster on my VBox than the one you sent few days ago so I don't know why you're saying it would be slow. The previous one was real slow to boot.
On the side note, I updated my Slitaz system and the image does build now with tazlito though with the same result - real HW EFI boot manager doesn't see it.
I tried again making it the way I was trying it previously - I place my _big_ ~65MB files to addfiles/rootcd/efi/boot and build the image. If you remember, this wouldn't work previously but now it did work (I guess it's due to updated system utils as you mentioned). Syslinux x64 version starts fine, it shows loading the rootfs.gz and then it goes to reboot. My guess is that my bzImage is not built with x64 gcc and libs. Can this be the reason?
I'll be trying to dig into this direction here. I just don't know how to help you understand the problem where the stick is not even seen. What is it happening to the image when I explicitly place files to addfiles/rootcd/efi resulting in the image that is properly marked and detected as UEFI bootable and doesn't happen if I don't use this folder?
Offline
Totally wild idea - can it be so that the EFI executable kernel file must be named either bootia32.efi or bootx64.efi ?
Offline
@st_user:
bootx64.efi will be lunched without arguments : no rootfs*.gz.
Did you disable the secure boot ?
Can you boot EFI shell ? and run startup.nsh ...
Offline
Now I place Syslinux x86 version as bootia32.efi to addfiles/rootcd/efi/boot and the stick is not seen by the boot manager either. Like I said, Syslinux x64 with bootx64.efi was detected and started just fine. So is it then x86 vs x64 issue? Does the kernel need to be compiled as x64 and placed as bootia32.efi?
Offline
@bellard, Secure boot is disabled.
How do I boot to EFI shell? I keep reading about it but wasn't able to get to it on my laptop. On VBox it stars by default.
Offline
[ Generated in 0.016 seconds, 7 queries executed - Memory usage: 1.6 MiB (Peak: 1.77 MiB) ]