SliTaz Forum
You are not logged in.
Checking some points for a doc with the last Rolling core64 ISO, I saw a /efi/boot repertory with bootx64.efi inside. First, thanks for this.
Would it be possible to add a few modules for GRUB 2 too, at least ext2, ntfs, iso9660 and chain for each architecture or in a first time x64. I know I'm selfisf 
?
There is also a efi.img in /boot/isolinux. Does this mean it is possible to boot this ISO on a UEFI computer? (can't test it, I give back her PC to my daughter)
I also saw that the kernel version has changed (3.16.55). It was still 3.2.98 two months ago.
Are all the packages on the mirror compatible with it?
What do you think to have a "newsletter" to announce changes in the ISOs (or other things like documentation updates or new docs...). I think I could do this if I have the information; I'd write some lines, submit them to ?? and then we can send it through the mailing list.
May be it'd wake up some ancien users or give idea to others...
What about it?
Offline
Ooops! Kultex has been faster than me...
Offline
and it is not only core64
http://hg.slitaz.org/wok/rev/708b5293dd29
Offline
Waooh, big job! I think I'm going to wait a few days before updating.
By the way, as the kernel is later than 3.3, does the EFI Stub Loader will be compiled in it?
Can't test anything this week, I've only 32bit at home, grrrr 
Offline
You can test EFI boot with qemu :
$ qemu-system-i386 -bios /usr/share/qemu/ia32/OVMF.fd -cdrom slitaz-rolling.iso
$ qemu-system-i386 -bios /usr/share/qemu/ia32/OVMF.fd -hda slitaz-rolling.iso
$ qemu-system-x86_64 -bios /usr/share/qemu/x64/OVMF.fd -cdrom slitaz-rolling-core64.iso
$ qemu-system-x86_64 -bios /usr/share/qemu/x64/OVMF.fd -hda slitaz-rolling-core64.iso
Still need a bootloader or a embedded initramfs.
Offline
Ceel maybe you or somebody else has time to test intel microcode package....
http://hg.slitaz.org/wok/rev/8310ba69ef5b
and as fare as I understand, only early microcode methode helps against spectre
http://forum.slitaz.org/topic/microcode#post-45546
I think, we have to follow this howto:
http://linuxfromscratch.org/blfs/view/svn/postlfs/firmware.html
sorry - I have at the moment absolutly no time......
Offline
@ kultex,
I see what I can do. I'm going to read first the howto you've linked.
@ Bellard,
My first post is a little confusing. I was still in my stuff. A few months ago, I did Live / frugal install / full install of SliTaz in Boot Mode UEFI. I borrowed grubx64.efi and some modules in another distro. But I realise there is no /boot/grub repertory in the last ISO64 so I guess we didn't take the same way. What is the bootx64.efi you use to boot in EFI mode?
I will have a try with Qemu tomorrow; I thought to test EFI boot with VirtualBox but I need a more powerful computer (because 32bit and few memory...). But maybe Qemu can run these old computers.
Offline
Test of the intel-microcode package
Before updating (kernel 3.2.98):[c]
root@slitaz:/home/ceel# dmesg | grep microcode
microcode: CPU0 sig=0xf24, pf=0x8, revision=0x9
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
root@slitaz:/home/ceel#
[/c]
After updating (kernel 3.16.55):[c]
root@slitaz:/home/ceel# dmesg | grep microcode
root@slitaz:/home/ceel#
[/c]
I suppose this is because the new kernel uses (or seems to use) the early loading of microcode (message [c]early console in decompress_kernel[/c] at the very beginning of the boot).
But the microcode is correctly installed:[c]
ceel@slitaz:~$ head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
stepping : 4
microcode : 0x9
ceel@slitaz:~$
[/c]
family-model-stepping gives 0f-02-04[c]
root@slitaz:/home/ceel# tazpkg -lf intel-microcode
Installed files by "intel-microcode"
================================================================================
.../...
/lib/firmware/intel-ucode/0f-02-04
.../...
================================================================================
97 files
[/c]
The microcode for my computer is in the package.
[c]
root@slitaz:/home/ceel# tazpkg -gi intel-microcode
intel-microcode-2018 100% |*******************************| 1210k 0:00:00 ETA
Installation of package "intel-microcode"
================================================================================
Intel processor microcode update for Linux
--------------------------------------------------------------------------------
Copying package... [ Done ]
Extracting package... [ Done ]
Remember modified packages... [ Done ]
Installing package... [ Done ]
Removing all tmp files... [ Done ]
Execute post-install commands... [ Done ]
================================================================================
Package "intel-microcode" (20180312) is installed.
[/c]
Tried to force a late loading of the microcode:[c]
root@slitaz:/home/ceel# echo 1 > /sys/devices/system/cpu/microcode/reload
sh: can't create /sys/devices/system/cpu/microcode/reload: nonexistent directory
root@slitaz:/home/ceel#
[/c]
No /microcode repertory in /sys/devices/system/cpu; unable to force an update of the microcode to see if it changes.
I still tried the early loading method. After reboot:[c]
ceel@slitaz:~$ dmesg | grep -i microcode
ceel@slitaz:~$
[/c]
:-(
The howto says that [c]CONFIG_MICROCODE[/c] should be [c]=y[/c]; [c]=m[/c] in SliTaz kernel but I don't think it can be the problem.
The microcode update instructions say that the microcode of some Linux distributions can be updated through the old microcode update interface which is avaialble in the kernel with CONFIG_MICROCODE_OLD_INTERFACE=y.
[c]
root@slitaz:/home/ceel# zcat /proc/config.gz | grep -i CONFIG_MICROCODE_OLD_INTERFACE
CONFIG_MICROCODE_OLD_INTERFACE=y
[/c]
Could it be the cause that the microcode.img is not loaded in the other method?
I tried to write microcode.dat in /dev/cpu/microcode as described:[c]
root@slitaz:/home/ceel/downloads# dd if=microcode.dat of=/dev/cpu/microcode bs=1M
dd: writing '/dev/cpu/microcode': Invalid argument
1+0 records in
0+0 records out
0 bytes (0B) copied, 0.512669 seconds, 0B/s
root@slitaz:/home/ceel/downloads# dmesg | grep -i microcode
microcode: CPU0 sig=0xf24, pf=0x8, revision=0x9
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
microcode: error! Bad data in microcode data file
root@slitaz:/home/ceel/downloads#
[/c]
Offline
following: Changing the microcode running Q4OS.
Kernel configuration[c]
ceel@q4os-desktop:/lib/firmware$ uname -a
Linux q4os-desktop 4.9.0-5-686-pae #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) i686 GNU/Linux
ceel@q4os-desktop:/lib/firmware$ cat /boot/config-4.9.0-5-686-pae | grep -i config_blk_dev_initrd
CONFIG_BLK_DEV_INITRD=y
ceel@q4os-desktop:/lib/firmware$ cat /boot/config-4.9.0-5-686-pae | grep -i config_microcode
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set
[/c]
Microcode loaded at boot:[c]
ceel@q4os-desktop:/lib/firmware$ head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
stepping : 4
microcode : 0x9
[/c]
Late loading method[c]
ceel@q4os-desktop:/lib/firmware$ sudo cp -v /media/ceel/stable/lib/firmware/intel-ucode/0f-02-04 intel-ucode
'/media/ceel/stable/lib/firmware/intel-ucode/0f-02-04' -> 'intel-ucode/0f-02-04'
root@q4os-desktop:~# echo 1 > /sys/devices/system/cpu/microcode/reload
root@q4os-desktop:~#
ceel@q4os-desktop:/lib/firmware$ dmesg | grep microcode
[ 3.240490] microcode: sig=0xf24, pf=0x8, revision=0x9
[ 3.240612] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 2845.386151] platform microcode: firmware: direct-loading firmware intel-ucode/0f-02-04
[/c]
Checking:[c]
ceel@q4os-desktop:~$ head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
stepping : 4
microcode : 0x9
ceel@q4os-desktop:~$
[/c]
The Howto says: "If the microcode was not updated, there is no new microcode for this system's processor.
So maybe it would have worked yesterday evening if it had existed an update for my porcessor..."
I think intel will never update so old processors. Someone else has to test it waiting I find a computer not so aged.
Testing the early loading of microcode:[c]
root@q4os-desktop:~# cp -v /media/ceel/stable/boot/microcode.img /boot
'/media/ceel/stable/boot/microcode.img' -> '/boot/microcode.img'
[/c]
Adding microcode.img in grub.cfg:[c]
initrd /boot/microcode.img /boot/initrd.img-4.9.0-5-686-pae
[/c]
All seems ok at reboot; no particular messages.
EDIT: result of [c]zcat /proc/config.gz | grep -i microcode[/c] modified; bad copy/paste, the two last lines were missing.
Offline
Tried to force a late loading of the microcode:
[c]root@slitaz:/home/ceel# echo 1 > /sys/devices/system/cpu/microcode/reload
sh: can't create /sys/devices/system/cpu/micropode/reload: nonexistent directory[/c]
[c]root@slitaz:/home/ceel# modprobe microcode
root@slitaz:/home/ceel# echo 1 > /sys/devices/system/cpu/microcode/reload
root@slitaz:/home/ceel# dmesg | grep microcode
microcode: CPU0 sig=0xf24, pf=0x8, revision=0x9
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[/c]
The howto says that CONFIG_MICROCODE should be =y; =m in SliTaz kernel but I don't think it can be the problem.
I am probably wrong. I set [c]CPU microcode loading support[/c] to [c]<*>[/c] in the kernel configuration:
[*][c]MICROCODE[/c] changed from [c][=m][/c] to [c][=y][/c]
[*][c]MICROCODE_EARLY[/c] changed from [c][=n][/c] to [c][=y][/c][c][/c]
[*]and [c]MICROCODE_INTEL_EARLY[/c] changed from [c][=n][/c] to [c][=y][/c]
I think that the module microcode must be built in the kernel.
I tried to recompile the kernel but
[c]root@slitaz:/usr/src/linux-3.16.55# make bzImage
.../...
BC kernel/timeconst.h
/bin/sh: bc: not found
kernel/Makefile:127: recipe for target 'kernel/timeconst.h' failed
make[1]: *** [kernel/timeconst.h] Error 127
Makefile:909: recipe for target 'kernel' failed
make: *** [kernel] Error 2
root@slitaz:/usr/src/linux-3.16.55#
[/c]
Unable to test more the early loading of the microcode.
Offline
thx Ceel for working on it...
very strange, that microcode isnt built in the new kernel - because Pascal changed it in January
http://hg.slitaz.org/wok/rev/8861cc63f78e
Pascal - is it possible to set it to y again?
Offline
Yes, strange. I checked again this evening. Microcode is really buit as a module as well as in core32 as in core34.
The good news: there is an update available for the processor of my work computer.
[c]
root@slitaz:~# head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping : 3
microcode : 0x1c
root@slitaz:~# echo 1 > /sys/devices/system/cpu/microcode/reload
root@slitaz:~# dmesg | grep microcode
microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU0 updated to revision 0x24, date = 2018-01-21
microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU1 updated to revision 0x24, date = 2018-01-21
microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU2 updated to revision 0x24, date = 2018-01-21
microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU3 updated to revision 0x24, date = 2018-01-21
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
root@slitaz:~# head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping : 3
microcode : 0x24
[/c]
So I can finish the test when the kernel will be configured.
BTW, we were still with 3.2.98 in january. I saved the last ISOs. I should be able to test it right away.
Offline
No chance After boot:
[c]
tux@slitaz:~/Documents$ head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping : 3
microcode : 0x1c
tux@slitaz:~/Documents$ dmesg | grep -i microcode
microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c
microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
tux@slitaz:~/Documents$ zcat /proc/config.gz | grep -i microcode
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y[/c]
But maybe the early boot doesn't work in the 3.2.98 version and it was the reason you've changed?
Anyway this last test was stupid and unuseful; we won't back to 3.2.98...
Offline
Pascal already did it, but there are microcode errors....
http://cook.slitaz.org/?pkg=linux
find: ${install}/lib/modules/*-slitaz*/kernel/arch/x86/kernel/cpu/microcode/microcode.ko.xz: No such file or directory
find: ${install}/linux64/lib/modules/*-slitaz*/kernel/arch/x86/kernel/cpu/microcode/microcode.ko.xz: No such file or directory
I tried to find something about it - only this docu...
https://github.com/torvalds/linux/blob/master/Documentation/x86/microcode.txt
at the moment no more time
Offline
The kernel has been recooked this afternoon. And the winner is... Bellard 
Now the early loading of the microcode works:[c]
tux@slitaz:~/Documents$ head -n7 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping : 3
microcode : 0x24
[/c]
Maybe still a problem:[c]
tux@slitaz:~/Documents$ cat /var/log/messages | grep -i microcode
Mar 27 18:05:01 (none) user.warn kernel: [<c1020ea2>] ? save_microcode.constprop.5+0x55/0xba
Mar 27 18:05:01 (none) user.warn kernel: [<c1748ae5>] ? save_microcode_in_initrd_intel+0x35/0x50
Mar 27 18:05:01 (none) user.warn kernel: [<c1748920>] ? save_microcode_in_initrd+0x1d/0x30
Mar 27 18:05:01 (none) user.err kernel: Cannot save microcode patches from initrd.
Mar 27 18:05:01 (none) user.info kernel: microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x24
Mar 27 18:05:01 (none) user.info kernel: microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x24
Mar 27 18:05:01 (none) user.info kernel: microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c
Mar 27 18:05:01 (none) user.info kernel: microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c
Mar 27 18:05:01 (none) user.info kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[/c]
CPU2 and 3 haven't been updated.
However, they were when I used the late loading (see previous post http://forum.slitaz.org/topic/new-kernel-in-core64-and-compatibility-with-uefi#post-46054 )
Offline
I think I've understood.
With Rolling core64, CPU 3 & 4 are updated -> it seems the 32bit kernel doesn't use CPU 3 & 4. Right?
Offline
@ Bellard,
Hi, I come back to the original subject of this topic.
What is the bootx64.efi you use to boot in EFI mode?
Understood. It's vmlinuz renamed.
Why not using rEFInd or GRUB 2 to boot in UEFI? They are much smaller than the kernel
I created 32bit ISOs with TazLiTo, replacing the kernel by rEFInd/GRUB 2:
[*]from Qemu, rEFInd doesn't work correctly (does not read its config file and does not scan partitions);
[*]with GRUB 2, from Qemu, SliTaz booted in graphic mode;
[*]from Virtual Box (Live session with kernel 3.2.98), rEFInd works correctly but SliTaz starts in console mode.
I don't understand these differences; please can you enlighten me?
Is Qemu entirely compatible with EFI? Maybe it needs to be updated.
And maybe Virtual Box needs to be updated too?
I noticed when I created my ISOs that TazLiTo
[*]limits the space for /efi (I had to suppress the not useful rEFInd's icons (otherwise -> [c]Boot Failed. EFI[/c]); or maybe it doesn't like we do modifications in /efi?
[*]delete my /boot/grub repertory when it generates ISOs (-> have to launched GRUB 2 from its command line);
[*]doesn't extract my /boot/refind_linux.conf file from my ISOs.
Bugs or normal working?
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]