initramfs busybox after boot

Asked by Johnny

Hi CubicPPA,

If I make an installation and the kernel is updated during the installation, the system boots in initramfs it does not detect the volume group root.

If I make the installation without network the bone boots correctly. I deduce that if the installation makes a kernel update, it breaks the boot.

All Custom ISO installation with network fails if the kernel is updated during installation

When i create a new ISO a run apt update && apt upgrade && update-initramfs -c -k all in chroot environment

Custom ISO : Ubuntu 20.04 LTS
Cubic last version on Ubuntu 20.04.LTS

Best regards

Question information

Language:
English Edit question
Status:
Answered
For:
Cubic Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Cubic PPA (cubic-wizard) said :
#1

I also noticed that, if you leave networking on while installation, some updates (like the kernel) are always downloaded and installed, even if you uncheck "Download updates" in Ubiquity.

Does everything work OK, when you create a new ISO a run `apt update && apt upgrade && update-initramfs -c -k all` in Cuic's Terminal environment, or is this when you experience the issue?

Have you made any changes to any files under `/boot/grub` or to `/etc/default/grub` in Cubic's terminal page?
If so, what were the changes?

Revision history for this message
Johnny (johnnybee) said :
#2

Hi CubicPPA,

###
Yes exactly , I disconnect the network to be sure of my test and I note that the installation proceeds correctly.

If the network is connected the installation will perform the updates. The installation proceeds correctly but if the kernel is updated during this step the system reboot on initramfs / busybox

I have not made any changes in custom-root '/boot/grub' or '/etc/default/grub'

###
"Does everything work OK, when you create a new ISO a run `apt update && apt upgrade && update-initramfs -c -k all` in Cuic's Terminal environment, or is this when you experience the issue?"

> Everything work ok if i create a new ISO and run apt update && apt upgrade && update-initramfs -c -k all` in Cuic's Terminal environment. The system boot correctly after installation.

The issue only happens when a kernel update is done during installation.

Best regard

Revision history for this message
Johnny (johnnybee) said :
#3

On boot i have :

Volume group system not found
Cannot process to volume group system
Gave up waiting for root file system device. Common problems :
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough ?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/system-root does not exist. Dropping to a shell!

BusyBox v1.30.1
(initramfs)

Revision history for this message
Cubic PPA (cubic-wizard) said :
#4

Thanks for the info.
I'll test this on my end.
(Please note, it may take me some time to get to).

Revision history for this message
PJSingh5000 (pjsingh5000) said :
#5

I tested with xubuntu-20.04.1-desktop-amd64.iso.

I customized this ISO in Cubic, but I purposely did not make any changes.
The kernel version installed in XUbuntu was 5.4.0-42.
However, the initrd.img and vmlinuz in /boot were broken symlinks to this kernel.
As you know, this is normal for newer Ubuntu Live ISOs.

(The kernel in my host OS was 5.11.0-17-generic).

I clicked through Cubic, accepting all defaults.

I used the generated ISO to install XUbuntu in VirtualBox.
I made sure the Network connectivity was active.
In the installer, I ensured "Download updates" was check-marked.

During installation, I saw that a new kernel was downloaded and installed.
The new kernel was 5.4.0-73.
I also saw that grub was updated during installation.

After installation, I attempted to boot into the installed OS.
I did not get a busybox message.

Here is the output for grub.cfg, kernel version, and the symlinks in /boot for the installed system.

You can see the newer kernel was successfully downloaded and installed.

$ cat /boot/grub/grub.cfg | grep splash
linux /boot/vmlinuz-5.4.0-73-generic root=UUID=XXXXX ro quiet splash $vt_handoff
linux /boot/vmlinuz-5.4.0-73-generic root=UUID=XXXXX ro quiet splash $vt_handoff
linux /boot/vmlinuz-5.4.0-42-generic root=UUID=XXXXX ro quiet splash $vt_handoff

$ uname -r
5.4.0-73-generic

$ ls -l /boot
total 130780
-rw-r--r-- 1 root root 237773 Jul 9 2020 config-5.4.0-42-generic
-rw-r--r-- 1 root root 237851 Apr 14 12:35 config-5.4.0-73-generic
drwx------ 2 root root 4096 Dec 31 1969 efi
drwxr-xr-x 4 root root 4096 May 15 17:26 grub
lrwxrwxrwx 1 root root 27 May 15 17:26 initrd.img -> initrd.img-5.4.0-73-generic
-rw-r--r-- 1 root root 49524770 May 15 17:26 initrd.img-5.4.0-42-generic
-rw-r--r-- 1 root root 50410632 May 15 17:26 initrd.img-5.4.0-73-generic
lrwxrwxrwx 1 root root 27 May 15 17:22 initrd.img.old -> initrd.img-5.4.0-42-generic
-rw-r--r-- 1 root root 182704 Feb 13 2020 memtest86+.bin
-rw-r--r-- 1 root root 184380 Feb 13 2020 memtest86+.elf
-rw-r--r-- 1 root root 184884 Feb 13 2020 memtest86+_multiboot.bin
-rw------- 1 root root 4738430 Jul 9 2020 System.map-5.4.0-42-generic
-rw------- 1 root root 4750832 Apr 14 12:35 System.map-5.4.0-73-generic
lrwxrwxrwx 1 root root 24 May 15 17:26 vmlinuz -> vmlinuz-5.4.0-73-generic
-rw-r--r-- 1 root root 11662080 Jul 31 2020 vmlinuz-5.4.0-42-generic
-rw------- 1 root root 11764480 Apr 14 12:37 vmlinuz-5.4.0-73-generic
lrwxrwxrwx 1 root root 24 May 15 17:26 vmlinuz.old -> vmlinuz-5.4.0-42-generic

Revision history for this message
PJSingh5000 (pjsingh5000) said :
#6

I wasn't able to recreate this in my test.

Have you modified grub in any way?

During ISO boot, the ISO goes through a bootstrap process.
The initrd and vmlinuz files located in <your live iso>/casper are used to bootstrap the customized OS.

Also, the grub from <your live iso>/boot is used.
If this version of grub can not find the initrd and vmlinuz files (from <your live iso>/casper) you may get a busybox message.

What are the default menu entries for your ISO:
- boot/grub/grub.cfg
- boot/grub/loopback.cfg
- isolinux/txt.cfg

(These are found on Cubic's Options page, Boot tab. The default entries are usually the 1st ones in these files; they say something line "Ubuntu" or "Try Ubuntu").

Revision history for this message
Johnny (johnnybee) said :
#7

Hi PJSingh5000,

Thank you very much for your feedback.

I'm trying to reproduce my problem in dev environment. I'can't reproduce too.

After update and upgrade the custom OS in chroot env, i make update-initramfs -c -k all. But i think i miss the update-grub command after update-initramfs command.

Do you think this is the original problem ?

Regards

Revision history for this message
Cubic PPA (cubic-wizard) said :
#8

It could be, but I thought the Ubiquity installer does `update-grub` in the target environment anyway.
It's hart to tell at this point.
If it happens again, take note of your steps; it would be good to know if there is something specific that causes this problem.

Can you help with this problem?

Provide an answer of your own, or ask Johnny for more information if necessary.

To post a message you must log in.