upgraded version on 18.04.2 does not boot
I downloaded ubuntu 18.04.2 boot ok used customizer latest snapshot performed a "apt upgrade" in chroot rebuilt iso, no error tried to boot, didn't work : 'initramfs unable to find a medium containing a live file system' in busybox at boot tried in bios and efi mode, same result. Have I missed something ?
I'm having the same issue too.
I downloaded xubuntu 18.04.1 (or 18.04.2) from http://cdimages.ubuntu.com/xubuntu/releases/18.04/release/
Installed it in a VirtualBox VM using EFI. I then installed customizer according to the instructions in the wiki and used the following customizer.conf:
[DEFAULT]
work_dir = /home/customizer
locales = C
resolution = 800x600
compression = gzip
vram = 256
iso = /home/will/build/vendor/xubuntu-18.04.1.iso
deb =
hook = /home/will/build/setup-live-distro.sh
kernel = default
purge_kernel = True
[preferences]
work_dir = /home/customizer
locales = en_GB.UTF-8
resolution = 1024x768
compression = gzip
vram = 256
[saved]
iso = /home/will//vendor/xubuntu-18.04.1.iso
deb =
hook = /home/will/build/setup-live-distro.sh
kernel = default
purge_kernel = True
and then created an iso like so:
# customizer -e
# customizer -c
apt-get update
# customizer -r
Then I copied the generated ISO from the VM to my host, and tried booting from the ISO.
When booting, this message pops up just before the plymouth boot screen appears

After plymouth times out, the machine is left in a busybox terminal

Huh. Do me a favor and grab minilubuntu from here: https://github.com/kamilion/kamikazi-core/releases/tag/0.9.0-rc7
I just built that against 18.04.2 about 17 days ago (from the time of this posting) I have verified it works in Secure Boot against an Asus F505ZA-DH51 (which includes canonical's signing key in the MOK list already.)
If it works and your ISO doesn't... something may have changed on canonical's side in the last two weeks, and I can look into it further.
All of the customizer hooks and surrounding buildscripts are in that repo as well.
Perhaps there may be some differences with how the xubuntu ISO layout is? I know ubuntu-server has problems in Customizer due to ISO layout being unexpected.
You might try what I do,
kernel = linux-signed-generic-hwe-18.04-edge
purge_kernel = False
under [saved] in customizer.conf as seen here:
https://github.com/kamilion/kamikazi-core/blob/master/buildscripts/bionic/customizer-mini.conf#L22
As far as I can tell, you're already using a linux-signed-generic image, which should work, but 18.04.2 defaults to the hardware enablement kernel, so having purge_kernel = True may be your problem.
I switched to -edge to get 5.0 for better ryzen support. YMMV.
Just poked around with things a bit; seems you may need to edit ISO/boot/grub/grub.cfg, ISO/boot/grub/loopback.cfg and ISO/isolinux/txt.cfg to change the initrd=/casper/initrd line to initrd=/casper/initrd.lz -- Just had this happen on an EFI boot while I was testing myself.
Hi @kamilion, Thanks for getting back to me so quickly.
So I tried both suggestions on xubuntu-18.04.1.iso.
- Setting
purge_kernel = Falseto no avail. -
sed -i s:/casper/initrd:/casper/initrd.lz:g ISO/on the files you mentioned, and success! :tada:
Thanks for you help it's much appreciated.
So what's the story with initrd vs. initrd.lz? Is this some change in Ubuntu's naming of init RAM disks?
Actually, it's due to the SPECTRE mitigations, a copy of the intel and AMD microcode is prepended to the initramfs, which (as far as I know) is already compressed. So I guess at this point, an uncompressed initramfs is broken due to the existence of a compressed header? You can look at some of the other issues for the unmkinitramfs 'solutions' that also work around this issue.
Thanks for the explanation, makes sense. I'll have a look at the unmkinitramfs threads in more detail as well.