Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upgraded version on 18.04.2 does not boot #210

Open
bigk-fr opened this issue Jul 29, 2019 · 6 comments
Open

upgraded version on 18.04.2 does not boot #210

bigk-fr opened this issue Jul 29, 2019 · 6 comments

Comments

@bigk-fr
Copy link

bigk-fr commented Jul 29, 2019

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 ?

@willprice
Copy link

willprice commented Aug 2, 2019

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
image

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

@kamilion
Copy link
Owner

kamilion commented Aug 3, 2019

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.

@kamilion
Copy link
Owner

kamilion commented Aug 3, 2019

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.

@willprice
Copy link

willprice commented Aug 3, 2019

Hi @kamilion,
Thanks for getting back to me so quickly.

So I tried both suggestions on xubuntu-18.04.1.iso.

  1. Setting purge_kernel = False to no avail.
  2. sed -i s:/casper/initrd:/casper/initrd.lz:g ISO/ on the files you mentioned, and success! 🎉

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?

@kamilion
Copy link
Owner

kamilion commented Aug 7, 2019

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.

@willprice
Copy link

Thanks for the explanation, makes sense. I'll have a look at the unmkinitramfs threads in more detail as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants