Received: from trent.utfs.org (trent.utfs.org [94.185.90.103]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id EF12C7819AA for ; Mon, 21 Oct 2019 17:45:01 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id D6E7B5FB1A; Mon, 21 Oct 2019 19:45:00 +0200 (CEST) Date: Mon, 21 Oct 2019 10:45:00 -0700 (PDT) From: Christian Kujau To: Chris Brannon cc: alpine-user@lists.alpinelinux.org Subject: Re: Syslinux & Xen & microcode updates In-Reply-To: <87r236t8cl.fsf@cmbmachine.messageid.invalid> Message-ID: References: <87r236t8cl.fsf@cmbmachine.messageid.invalid> User-Agent: Alpine 2.21.99999 (DEB 352 2019-06-22) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 21 Oct 2019, Chris Brannon wrote: > APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla \ > root=[...] modules=ext4 --- intel-ucode.img --- initramfs-vanilla That didn't work, as vmlinuz-vanilla now tried to find its initrd in intel-ucode.img, but that did not contain a rootfs and it panicked with this infamous "Kernel panic - not syncing: VFS: Unable to mount root fs..." message. > FWIW there is a subtle difference in how microcode is handled on EFI and > non-EFI Xen. For non-EFI Xen, the ucode= parameter is either a > zero-based index into the list of loaded modules, the value "scan" to > scan the list, or -1 to use the last module in the list. See here: > https://xenbits.xenproject.org/docs/4.12-testing/misc/xen-command-line.html#ucode-x86 Ah, I didn't know about that value being different depending on whether EFI or non-EFI systems are used, thanks! So, while "intel-ucode.img --- initramfs-vanilla" did not work (tested just now), I fiddled around some more (boy, was it late last night) and although I dismissed it first, the concatenation of the microcode and the initrd[0] did indeed work, although I am missing the usual "microcode" messages in dmesg, something like: microcode: sig=0x806e9, pf=0x80, revision=0xb4 microcode: Microcode Update Driver: v2.2. So, with this absent, the following message is now gone: MDS: Vulnerable: Clear CPU buffers attempted, no microcode ...and this spectre-meltdown-checker.sh check script (that bugged me to attempt a microcode update) is now much happier :-D So, to recap, the following worked, although it bugs me that dmesg is quiet about this: ============================================================== # cd /boot # apk info -W intel-ucode.img /boot/intel-ucode.img is owned by intel-ucode-20190918-r0 # cat intel-ucode.img initramfs-vanilla > intel-ucode_initramfs-vanilla.img # update-extlinux -v Updating extlinux configuration. Found Xen hypervisor: /boot/xen.gz, kernel: /boot/vmlinuz-vanilla Found initramfs: /boot/initramfs-vanilla Found kernel: /boot/vmlinuz-vanilla Found initramfs: /boot/initramfs-vanilla Found microcode for Intel CPUs: /boot/intel-ucode.img 2 entries found. Installing libutil.c32 libcom32.c32 mboot.c32 menu.c32 vesamenu.c32 to /boot. /boot is device /dev/sda1 # sed -i 's/ initramfs-vanilla$/ intel-ucode_initramfs-vanilla.img/' extlinux.conf # cat extlinux.conf DEFAULT menu.c32 PROMPT 0 MENU TITLE Alpine/Linux Boot Menu MENU AUTOBOOT Alpine will be booted automatically in # seconds. TIMEOUT 50 LABEL xen-vanilla MENU LABEL Xen + Linux vanilla COM32 mboot.c32 APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla root=[...] modules=ext4 rootfstype=ext4 --- intel-ucode_initramfs-vanilla.img ============================================================== Thanks for responding, Christian. [0] https://bbs.archlinux.org/viewtopic.php?pid=1814467#p1814467 "Advice: Where to capture custom Microcode system requirements/setup?" -- BOFH excuse #412: Radial Telemetry Infiltration