Setting your kernel for JIBRI safely (not working yet, needs troubleshooting)

Hi all, I wanted to troubleshoot and hopefully provide a definitive way to set your kernel for your Jibri installation.

I have done an install on the newest Ubuntu 20.04 a few months ago, and cannot do it again as changing my grub entry is causing a crash where the system won’t boot.

It’s telling me it can’t find the right kernel, and does not fall back as expected. Error log at the end of this post.

Why do i need to set a kernel?
Because Jibri requires the alsa or sound module, which is not installed on most cloud VPS providers, including the most popular one Amazon.

In every Jibri guide, it is set in a different way: (seems broken at the moment?)
Jitsi and Jibri on AWS - Very easy comprehensive guide for dummies → copies the menuid directly, failure prone and you don’t know if you done it wrong.
[Setup / Guide] Jitsi Meet Native + Multiple (6) Jibri Docker instances working on the same AWS server → This is what prompted the guide, as using the index of the grub menu entries is dangerous.

The ideal way to set your kernel:
Install a generic kernel, that has the alsa module.
sudo apt install linux-image-extra-virtual
You’ll see it reference something like Linux 5.4.0-84-generic in the install packages, it helps later on.
Now, list your boot entries that you have for that new generic kernel

grep -A200 submenu /boot/grub/grub.cfg |grep -P '^(?=.*menuentry)(?=.*generic)'

(This is slightly different from what you see elsewhere - I hide the other kernels so we don’t get confused).
As an example, I see:

	menuentry 'Ubuntu, with Linux 5.4.0-84-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-84-generic-advanced-e8070c31-bfee-4314-a151-d1332dc23486' {
	menuentry 'Ubuntu, with Linux 5.4.0-84-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-84-generic-recovery-e8070c31-bfee-4314-a151-d1332dc23486' {

In what is likely the top line, and not the one that mentions recovery mode, copy it’s menuentry at the start of the line. On mine looks like Ubuntu, with Linux 5.4.0-84-generic , but it will be different for everyone.

Now, you will edit /etc/default/grub , either with VI or Nano, whatever feels more comfortable for you.
Comment out the GRUB_DEFAULT=0 (loads the first entry in your grub bootlist), and change it to the string we found earlier. For me, this section of the file now looks like:

GRUB_DEFAULT="Ubuntu, with Linux 5.4.0-84-generic"

This is not a proper setup yet - we are using it to let grub check and tell us the best way to do it.

At this point, we can sudo update-grub, which will give me a friendly warning like this (this is good!)

Warning: Please don't use old title `Ubuntu, with Linux 5.4.0-84-generic' for GRUB_DEFAULT, use `Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-84-generic' (for versions before 2.00) or `gnulinux-advanced-e8070c31-bfee-4314-a151-d1332dc23486>gnulinux-5.4.0-84-generic-advanced-e8070c31-bfee-4314-a151-d1332dc23486' (for 2.00 or later)

Again, this is good! We know that we’ve specified something it recognises. Everyone is running grub newer than 2.00 these days, so we now edit /etc/default/grub again and change it to it’s final value:

(my values will be different to yours)

#GRUB_DEFAULT="Ubuntu, with Linux 5.4.0-84-generic"

This new default is great - it will try to boot the generic image, and if something is wrong it will give up an load your AWS image - you can see this by the > symbol in the middle which tells you it’s got two kernels it will attempt to try and boot. This is actually your $menuentry_id_option earlier, but sometimes it has a prefix that if you used (osprober), everything would break.

Now at this point, other guides go on to install chrome and the rest of Jibri. This is probably a bad idea! because if you havn’t got this working correctly, you have a mostly borked install that’s very difficult to recover (much quicker to start from scratch)

Lets see if it works!

sudo update-grub

You should have no warning now. You can do the leap of faith with sudo reboot.

This is unfortunately where my guide falls apart, as when I boot, My setup crashes! According to the serial console, here is the error where it can’t find my boot.

[    0.000000] Linux version 5.4.0-84-generic (buildd@lgw01-amd64-050) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #94-Ubuntu SMP Thu Aug 26 20:27:37 UTC 2021 
(Ubuntu 5.4.0-84.94-generic 5.4.133)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-84-generic root=PARTUUID=5198cbc0-01 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Hygon HygonGenuine
[    0.000000]   Centaur CentaurHauls
[    0.000000]   zhaoxin   Shanghai  
... lots of cpu init that's hard to copy ..
[   10.366218] rtc_cmos 00:00: setting system clock to 2021-09-21T11:25:30 UTC (1632223530)
[   10.373185] md: Waiting for all devices to be available before autodetect
[   10.460173] md: If you don't use raid, use raid=noautodetect
[   10.464642] md: Autodetecting RAID arrays.
[   10.468024] md: autorun ...
[   10.470867] md: ... autorun DONE.
[   10.473906] VFS: Cannot open root device "PARTUUID=5198cbc0-01" or unknown-block(0,0): error -6
[   10.562806] Please append a correct "root=" boot option; here are the available partitions:
[   10.569825] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[   10.674637] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.0-84-generic #94-Ubuntu
[   10.682527] Hardware name: Amazon EC2 t3.small/, BIOS 1.0 10/16/2017
[   10.686735] Call Trace:
[   10.691100]  dump_stack+0x6d/0x8b
[   10.759061]  panic+0x101/0x2e3
[   10.761974]  mount_block_root+0x23f/0x2e8
[   10.765568]  mount_root+0x38/0x3a
[   10.768584]  prepare_namespace+0x13f/0x194
[   10.771873]  kernel_init_freeable+0x23f/0x263
[   10.775368]  ? rest_init+0xb0/0xb0
[   10.859141]  kernel_init+0xe/0x110
[   10.862101]  ret_from_fork+0x35/0x40
[   10.865843] Kernel Offset: 0x36a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)