I am trying to run Alpine Linux inside a qemu VM.
It fails to boot with a message about APIC… suggests using ‘noapic’ kernel boot parameter.
Normally that would be easy… edit the grub menu line
but
Alpine boots with isolinux
not with grub.
To add a boot parameter to isolinux you have to edit the file syslinux.cfg
but
That file is inside the .iso file.
so
it looks like I have to unpack the Alpine .iso, edit the syslinux.cfg file, then remake the .iso.
Does anyone know a better way
Good question. I’m not sure how to do that off the top of my head. I would sure think there would be a way to do that. I wonder if there is something like an environment variable you could set when the VM boots. I don’t know if that even exists but seems reasonable.
I know you can tske zip7 and extract a Windows ISO and then save the the ISO. You could maybe
use unzip and extract the ISO, do your config, save and then build Alpine.
I am working on that, but with different tools
- do a loop mount of the iso
- copy the contents to a tmp workdirectory
- edit the workdirectory
- remake the iso from the edited workdirectory with
mkisofs
I got that far and it is not bootable… it makes a data CD.
I am looking at xorriso
instead of mkisofs… it can add the bootable bit… I hope.
Bootloader Impact in QEMU
- Legacy BIOS Mode (x86_64)
- Alpine’s ISO uses isolinux (via Syslinux) for booting in legacy BIOS mode.
- In QEMU, this works seamlessly with:
Bash:
qemu-system-x86_64 -boot d -cdrom alpine.iso -m 512
- No special tweaks needed—isolinux handles the boot menu and kernel handoff cleanly.
- UEFI Mode
- Alpine switches to GRUB or EFI stub booting when UEFI is detected.
- In QEMU, you’ll need to pass a UEFI firmware binary like:
Bash:
-bios OVMF.fd
- This enables Alpine to boot in UEFI mode, useful for testing GRUB configs or EFI boot stubs.
Real-World Effects in Your VM Workflows
- Diskless Mode: Alpine boots entirely from RAM, using setup-alpine to configure and optionally commit changes via lbu commit. Bootloader choice doesn’t affect this much unless you’re testing persistence.
- apkovl + apkcache: If you’re mounting a virtual drive to persist configs, the bootloader must support mounting and reading that volume early in boot. Both isolinux and GRUB handle this fine.
- Custom ISO Builds: If you’re crafting hybrid ISOs for both BIOS and UEFI, you’ll need to include both isolinux.cfg and grub.cfg, and possibly use xorriso with --boot_image hybrid.
This is what “copilot” has to say!!!
I did not know about that… thanks. I am using UEFI boot in my machine… does it mean using uefi in the host or in qemu?.. I think it means in qemu… I think it is defaulting to legacy boot in qemu, because it works without that parameter.
I can boot Alpine with qemu in Void ( or any other linux), but I cant boot Alpine with qemu in NetBSD … it says I need the ‘noapic’ kernel boot parameter.
but
I cant supply that boot parameter because alpine boots with isolinux… I have to edit the iso file… no other way… no, maybe I could try qemu with uefi boot of its guest.
This is complicated.
Why are you even using UEFI in a virtual environment? Setup Alpine for msdos and grub boot and isolinux will detect grub and boot the VM, or it should!!!
I am not. I am using the qemu default which is legacy boot.
Setup Alpine for msdos and grub boot and isolinux will detect grub and boot the VM, or it should!!!
My Alpine seems to only have isolinux, not grub
I have one SOLUTION
Here are the steps.
- Do a loop mount of the alpine .iso
mkdir /mnt/isomnt
mount -o loop /mnt/share/alpine-standard-3.22.1-x86_64.iso
- Copy the content of the iso to a workfile
mkdir newisocontent
cp -r /mnt/isomnt/* newisocontent
- Edit syslinux.cfg
chmod 744 syslinux.cfg
vi syslinux.cfg
add noapic to the APPEND line
- Make a new bootable iso
$ xorriso -as mkisofs -r -J -V "MyAlpine.iso" \
-b boot/syslinux/isolinux.bin \
-c boot/syslinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-o /mnt/share/MyAlpine.iso ~/newisocontent
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'stdio:/mnt/share/MyAlpine.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 16.3g free
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/home/nevj/newisocontent'
xorriso : UPDATE : 127 files added in 1 seconds
xorriso : UPDATE : 127 files added in 1 seconds
xorriso : UPDATE : 9.12% done
xorriso : UPDATE : 34.40% done
ISO image produced: 137764 sectors
Written to medium : 137764 sectors at LBA 0
Writing to 'stdio:/mnt/share/MyAlpine.iso' completed successfully.
xorriso is a fork of mkisofs with additions. I believe one can also do this with mkisofs
or genisoimage
Note: the -b and -c parameters are the location of the files isolinux.bin and boot.cat in the filesystem of the .iso.
The file it makes is bootable
$ file *
alpine-standard-3.22.1-x86_64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'alpine-std 3.22.1 x86_64' (bootable)
MyAlpine.iso: ISO 9660 CD-ROM filesystem data 'MyAlpine.iso' (bootable)
Not quite the same as the original .iso file ( no DOS/MBR boot sector) but bootable.
- Try booting it in NetBSD
I did all the above in MX.
I can then take the file MyAlpine.iso
into NetBSD using my shared ext2 filesystem , and boot it with qemu as follows
qemu-system-x86_64 -m 512 -nic user -display sdl,gl=on \
-boot d -hda alpinevm.qcow2 \
-cdrom /mnt/share/MyAlpine.iso
It boots (slowly?) brings up a small window, then about half way thru the boot process the qemu window becomes large…so large I can not access the bottom line… because my NetBSD screen is only 800 x 600. … but it does boot.
It looks like this
That is the CTWM window manager at 800 x 600 in NetBSD. You can see the qemu window hangs off the edges and I cant resize it… Alpine sets the size while booting. If my amdgpu worked it would be OK.
So that is one SOLUTION. There are probably other ways…including what you suggest … get grub into Alpine.
And if you do not have Grub then their is nothing to detect!!!
Alpine does not boot itself with grub. afaik isolinux is a bootloader itself, and it boots alpine directly… I will have another closer look. I have never had a hard install of alpine, so I dont know how it interacts with grub. An external grub in a multiboot situation might detect it and boot it.
I am using the minimal Alpine .iso. Maybe if I used the full .iso it may have grub.
I think you are mis-interpreting this, Alpine boots from grub, isolinx through syslinx, just detects grub for the boot, it is all linked together!!!
I shall go and re-assess the situation.
I admit my understanding of Alpine is minimal. I could easily miss things.
Here is what google ai tells me
" Alpine Linux boots by using a bootloader like Syslinux or UEFI to load the kernel and an initramfs, which then copies the entire Alpine system into RAM for diskless execution from the boot media or a storage device. The initial process is handled by the initramfs containing necessary tools, and once the system is running from RAM, it uses the OpenRC init system with the BusyBox shell to provide a basic command-line environment.
- Hardware and Bootloader:
-
BIOS/UEFI: The process begins with the system’s BIOS or UEFI firmware.
-
Bootloader: A bootloader, such as the default Syslinux or a UEFI option, is then loaded.
- Loading the Kernel and Initramfs:
-
The bootloader’s primary role is to locate and load the Linux kernel and the initramfs image into memory.
-
The initramfs is a small, temporary filesystem that contains the kernel, drivers, and essential utilities needed to start the system and access the root filesystem.
- Kernel Initialization:
- Control is handed over from the bootloader to the kernel, which starts the initialization process.
- At this stage, the initramfs is the only available filesystem.
- Copying to RAM (Diskless Mode):
- Alpine Linux is designed to copy its entire operating system into RAM, allowing it to run disklessly.
- This makes the system faster and more resilient to issues with the initial boot media.
- Once the OS is running from RAM, the OpenRC init system takes over.
- It then starts the BusyBox utilities, providing a minimal command-line interface using the ash shell.
- Diskless Execution:
- The system operates from RAM, with the possibility of storing local packages or configuration files on a customizable boot device if one is used.
- "
No mention of grub there?
This Alpine page says you can optionally add grub to alpine , but you shoukd remove syslinux if you do it.
I think Alpine is different to the distros you have used.?
If you can, burn the ISO to a cd then boot the cd or a USB?
Yeah, good test.
I will make it a hybrid iso, and put it on a usb drive.
You mean my edited alpine… not the standard one? They differ
alpine-standard-3.22.1-x86_64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'alpine-std 3.22.1 x86_64' (bootable)
MyAlpine.iso: ISO 9660 CD-ROM filesystem data 'MyAlpine.iso' (bootable)
It may well boot in qemu, but not on its own… because it does not have an MBR
I am starting to get what you are on about… I think when I make a hybrid iso, it will add the MBR to it… I will check … I think it only needs the MBR to boot from a usb drive… CD’s have their own boot tools built into fhe CD reader.
Try doing that in NetBSD
The choice is qemu at CLI, or Xen
You need to change machines!!!
You mean so netbsd will work with my graphics card? I considered that… my other machine has intel onboard graphics… that should work, but that machine it legacy boot so netbsd will overwrite the MBR with its own bootloader…netbsd behaves like Windows in that respect,
or
wait a couple of years for netbsd to catch up. on its drivers… I can cope with a vga screen… there will be a fix for qemu,
or
I can put netbsd in a VM and do it there where screen drivers do not matter.
While you have Alpine , have a look. It has busybox and the apk package system and the ash shell. I can make an alpine VM with 1M of ram and only 4G of virtual disk… that is almost as small as a docker container.
How come your text is hidden until I expand the picture?