Using the original ISO bootstrap kernel causes BusyBox, when that kernel version has been removed in the chroot environment.

[Tony Travis]

I upgraded Ubuntu-MATE in the "cubic" chroot using:

  apt update
  apt full-upgrade
  apt autoremove

This removed the linux-image for the original iso kernel, but the original kernel was still offered by default as the kernel to boot the remastered iso from, resulting in a BusyBox prompt at boot-time...

However, re-installing the original linux-image package in the chroot allowed the iso to be booted from the original kernel. Selecting one of the new kernels instead of the default (original) while creating the iso avoids the requirement to leave the original linux-image installed in the chroot when upgrading - By default only two linux-image's remain after cleaning up using "apt autoremove".

I think the default should be to boot from the kernel in the newest linux-image, plus a backup of the previous 'old' linux-image in case of problems with the latest kernel.

Thanks,

  Tony Travis.

[Cubic PPA (cubic-wizard)]

Travis,

There are two kernel needed:

#1 - A kernel to bootstrap the ISO. (Basically it tells a computer how to read and load files from the ISO, USB, DVD, CD, etc.).

#2 - A kernel for your customized Linux file system. This is the kernel your customized ISO will **install** onto a new computer.

I think you are convoluting these two different kernels...

You manage your customized Linux file system inside the chroot environment. You can install or uninstall whatever you want there. You can install or remove as many kernels (#2, above) as you like. All changes you make here will be installed onto a computer by your customized iso.

The bootsrtap kernel (#1, above) is *OUTSIDE* your customized Linux file system, and is not something you can change from inside chroot. This kernel is *never* installed onto a computer by your customized iso.

However, Cubic does allow you to change the bootstrap kernel (if you need to)...

Cubic essentially gives you two choices for the bootstrap kernel:

a. Use the original bootstrap kernel that came with the ISO, to bootstrap the new ISO. This kernel is ~still~ on the ISO ~outside~ the chroot environment, so you could not have removed it, even if you tried. This is the default kernel offered by Cubic, because it always works to bootstrap the iso.

b. Use one of the kernels you installed ~inside~ the chroot environment, as a bootstrap kernel. This usually works, but in some cases it doesn't (particularly when customizing server images).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Therefore, using the latest kernel you installed inside chroot as the bootstrap kernel may not be the ideal default for all users, because it doesn't work in all cases. (The bootstrap process is kind of finicky).

Also, the bootstrap kernel isn't something most users need to worry about too much... It may be important if you have installed certain kernel modules for a specific kernel version inside your chroot. In this case, these modules will not load while you are running the Live ISO. But once you've installed the new customized OS, the modules will be copied along with your new default kernel.

[Cubic PPA (cubic-wizard)]

Question:

Do you also get the BusyBox if you...?
1. Remove the old kernel, as you did previously through `apt full-upgrade`.
2. This will also install a newer kernel.
3. Select the newer kernel Cubic's Boot Kernels tab?

In other words, if you install a new kernel inside chroot, and if you select this same new kernel as your boot strap kernel, do you still get the get the BusyBox?

[Tony Travis (ajtravis)]

On 20/04/2019 06:22, Cubic PPA wrote:
> Travis,
>
> There are two kernel needed:
>
> #1 - A kernel to bootstrap the ISO. (Basically it tells a computer how
> to read and load files from the ISO, USB, DVD, CD, etc.).
>
> #2 - A kernel for your customized Linux file system. This is the kernel
> your customized ISO will **install** onto a new computer.
>
> I think you are convoluting these two different kernels...

Hi,

I do understand #1 and #2.

What you have NOT understood from my bug report is that by default the
original OUTSIDE kernel is selected even if you have removed the
linux-image package supporting it INSIDE the chroot/squashfs filesystem,
which can happen automatically if you use "apt autoremove" as I did...

> [...]
> Therefore, using the latest kernel you installed inside chroot as the
> bootstrap kernel may not be the ideal default for all users, because it
> doesn't work in all cases. (The bootstrap process is kind of finicky).

...my main point is that you should avoid setting the OUTSIDE kernel to
the original kernel if the libraries and modules supporting it INSIDE
are absent, which is what can happen automatically if you 'autoremove'.

> Also, the bootstrap kernel isn't something most users need to worry
> about too much... It may be important if you have installed certain
> kernel modules for a specific kernel version inside your chroot. In this
> case, these modules will not load while you are running the Live ISO.
> But once you've installed the new customized OS, the modules will be
> copied along with your new default kernel.

In fact, one of the main reasons that I'm remastering the Ubuntu-MATE
iso is to provide a newer kernel with better hardware support on a
'live' USB-stick with persistence and the kernel modules loaded are
important. I'm using the same iso for installations directly to "md"
RAID and everything works correctly as long as I do not select the
original OUTSIDE kernel for booting 'live' after removing the INSIDE
linux-image supporting it - This might be of interest to other users.

Thanks for your helpful advice,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[Tony Travis (ajtravis)]

On 20/04/2019 07:04, Cubic PPA wrote:
> Question:
>
> Do you also get the BusyBox if you...?
> 1. Remove the old kernel, as you did previously through `apt full-upgrade`.
> 2. This will also install a newer kernel.
> 3. Select the newer kernel Cubic's Boot Kernels tab?
>
> In other words, if you install a new kernel inside chroot, and if you
> select this same new kernel as your boot strap kernel, do you still get
> the get the BusyBox?

Hi,

Everything works correctly if I select the newest INSIDE kernel as the
OUSIDE kernel for booting the iso. The only problem is if, as I did, you
remove the linux-image package INSIDE supporting the original OUTSIDE
kernel and choose that kernel (selected by default) to boot the iso.

Thanks again for Cubic - It works very well and I just want to give a
heads-up about a problem with the default kernel that tripped me up!

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[PJSingh5000 (pjsingh5000)]

Ok, thanks for the clarification and re-testing...

We could set Cubic to always select the highest kernel version number as default, but perhaps we can do a little better...

SCENARIOS
---------

1. What happens if a user installs an older kernel ~after~ installing a newer kernel? For example the user 1st installs kernel 4.5, and then the user installs kernel 4.3. Assuming the user doesn't remove any kernels, kernel 4.3 would be the default kernel used by the OS (since it was installed last). But Cubic would default to kernel 4.5, and this might again result in "BusyBox." In this case, Cubic should have selected kernel 4.3 and not 4.5 as the default.

2. Cubic always selecting the newest kernel would be an issue for the folks using server images, because they would end up getting the "BusyBox" message. (See Bug #1782379, "Can not use newer kernel than comes with the ISO"). However, Cubic already checks if the user is customizing a server image, to present the user with a note about which image they should choose. This same check could be repurposed to always select the "OUTSIDE" kernel if Cubic thinks the user is customizing a server image. For all other users, Cubic could default to a different "INSIDE" kernel.

SUGGESTION
----------

Based on your testing above, we probably want Cubic to select the kernel that is setup to be the default OS kernel, not necessarily the newest kernel. (Of course for server images, this rule wouldn't apply). This way, the bootstrap kernel matches the OS kernel, and everything (theoretically) should work smoothly.

What do think of this suggestion? In your case, the default kernel would be the newest kernel, since that is the one that was setup last.

CHALLENGE
---------

1. I mentioned the server ISO issue. But we have a work-around for that.

2. How do we identify the kernel that the user has setup as the default OS kernel (version 4.3 in the example above).

I know that that `dpkg --list | grep linux-image-generic` always points to the currently installed kernel, but users can install kernels without installing this package, or they can manually download and setup different kernels. Is there an easy way of pinpointing the default configured kernel without parsing trough grub configuration files?

NEXT STEPS
----------

I'd like to get more information on reliably identifying the default "INSIDE" kernel, because I think this would best solve the issue you've raised.

If this can't be done in a simple and consistent way, we could modify Cubic to select the highest kernel version for non-server images, as you have proposed in this bug report. This ~should~ be acceptable for most users, because they probably just want to use the newest kernel they've installed. I'll do a little more testing with different ISOs and kernel versions to see if there are any issues.

[Tony Travis (ajtravis)]

On 20/04/2019 18:15, PJSingh5000 wrote:
> [...] > Based on your testing above, we probably want Cubic to select the kernel
> that is setup to be the default OS kernel, not necessarily the newest
> kernel. (Of course for server images, this rule wouldn't apply). This
> way, the bootstrap kernel matches the OS kernel, and everything
> (theoretically) should work smoothly.
>
> What do think of this suggestion? In your case, the default kernel would
> be the newest kernel, since that is the one that was setup last.

Hi,

I think that's a good suggestion.

> CHALLENGE
> [...]
> I'd like to get more information on reliably identifying the default
> "INSIDE" kernel, because I think this would best solve the issue you've
> raised.

A reliable way to identify the default INSIDE kernel in the chroot is
from the symlinks created for it when the kernel was installed e.g. in
the Cubic chroot on my build-system "pilot":

> root@pilot:~ # ls -l /vmlinuz*
> lrwxrwxrwx 1 root root 30 Apr 8 22:36 /vmlinuz -> boot/vmlinuz-4.18.0-17-generic
> lrwxrwxrwx 1 root root 30 Apr 1 21:42 /vmlinuz.old -> boot/vmlinuz-4.18.0-16-generic

These are prioritised in order of installation, so offering the kernel
pointed to by /vmlinuz would be a good default for the OUTSIDE kernel.

Thanks for your helpful response to my bug report,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[PJSingh5000 (pjsingh5000)]

Referencing https://help.ubuntu.com/community/Grub2/Submenus, "By default GRUB 2 sets the most recent kernel as the default."

I had expected that the default kernel would be the most recently installed kernel, but this does not seem to be the case. This is good justification for your original proposal to use the newest kernel as the default bootstrap kernel (for non-server images).

[Tony Travis (ajtravis)]

On 25/04/2019 05:00, PJSingh5000 wrote:
> Referencing https://help.ubuntu.com/community/Grub2/Submenus, "By
> default GRUB 2 sets the most recent kernel as the default."
>
> I had expected that the default kernel would be the most recently
> installed kernel, but this does not seem to be the case. This is good
> justification for your original proposal to use the newest kernel as the
> default bootstrap kernel (for non-server images).

Hi,

I think a better default would be, as I later suggested, following the
symlink:

   /vmlinuz -> boot/<most recently installed kernel>

HTH,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[Tony Travis (ajtravis)]

On 25/04/2019 10:37, Tony Travis wrote:
> On 25/04/2019 05:00, PJSingh5000 wrote:
>> Referencing https://help.ubuntu.com/community/Grub2/Submenus, "By
>> default GRUB 2 sets the most recent kernel as the default."
>>
>> I had expected that the default kernel would be the most recently
>> installed kernel, but this does not seem to be the case. This is good
>> justification for your original proposal to use the newest kernel as the
>> default bootstrap kernel (for non-server images).
>
> Hi,
>
> I think a better default would be, as I later suggested, following the
> symlink:
>
>   /vmlinuz -> boot/<most recently installed kernel>

Hi,

In the Cubic chroot immediately after extracting the original iso:

> root@pilot:~ # ls -l /vmlinuz*
> lrwxrwxrwx 1 root root 30 Feb 10 00:22 /vmlinuz -> boot/vmlinuz-4.18.0-15-generic
> lrwxrwxrwx 1 root root 30 Feb 10 00:22 /vmlinuz.old -> boot/vmlinuz-4.18.0-15-generic

Update to the most recent linux-image:

> root@pilot:~ # apt update
> root@pilot:~ # apt full-upgrade

After the upgrade:

> root@pilot:~ # ls -l /vmlinuz*
> lrwxrwxrwx 1 root root 30 Apr 25 09:56 /vmlinuz -> boot/vmlinuz-4.18.0-18-generic
> lrwxrwxrwx 1 root root 30 Apr 25 09:56 /vmlinuz.old -> boot/vmlinuz-4.18.0-18-generic

Packages installed:

> root@pilot:~ # dpkg -l 'linux-image*' | awk '$1=="ii"{print $2}'
> linux-image-4.18.0-15-generic
> linux-image-4.18.0-18-generic
> linux-image-generic-hwe-18.04

Version selected by GRUB:

> root@pilot:~ # update-grub
> Sourcing file `/etc/default/grub'
> Generating grub configuration file ...
> Found linux image: /boot/vmlinuz-4.18.0-18-generic
> Found initrd image: /boot/initrd.img-4.18.0-18-generic
> Found memtest86+ image: /boot/memtest86+.elf
> Found memtest86+ image: /boot/memtest86+.bin

The Cubic iso OUTSIDE boot kernel defaults to Version 4.18.0-15, which
is not a problem unless linux-image-4.18.0-15-generic is removed...

HTH,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[PJSingh5000 (pjsingh5000)]

Per https://help.ubuntu.com/community/Grub2/Submenus, "By default GRUB 2 sets the most recent kernel as the default."

I also verified this by manually installing an older kernel ~after~ installing a newer kernel:
  1. Install kernel_4.17.3, first
  2. Install kernel 4.16.18, second
  3. Execute update-grub
  4. This created /boot/grub/grub.cfg
  5. The 1st (default) entry in grub.cfg was for newest kernel vmlinuz-4.17.3-041703-generic

The newest kernel takes precedence, regardless of the order in which kernels are installed.

[PJSingh5000 (pjsingh5000)]

HOWEVER, the symlinks in the root directory still pointed to the most recently installed kernel...

    initrd.img -> boot/initrd.img-4.16.18-041618-generic
    initrd.img.old -> boot/initrd.img-4.17.3-041703-generic
    vmlinuz -> boot/vmlinuz-4.16.18-041618-generic
    vmlinuz.old -> boot/vmlinuz-4.17.3-041703-generic

When I ran `update-initramfs`, it used the ~newest~ kernel instead of the most recently installed older kernel:

    update-initramfs -u
    update-initramfs: Generating /boot/initrd.img-4.17.3-041703-generic

It looks like these symlinks aren't always reliable.

Indeed, booting into the generated ISO confirmed that kernel 4.17.3 was the default active kernel, even though the initrd and vmlinuz symlinks still pointed to version 4.16.18.

[Tony Travis (ajtravis)]

On 25/04/2019 15:50, PJSingh5000 wrote:
> Per https://help.ubuntu.com/community/Grub2/Submenus, "By default GRUB 2
> sets the most recent kernel as the default."
>
> I also verified this by manually installing an older kernel ~after~ installing a newer kernel:
> 1. Install kernel_4.17.3, first
> 2. Install kernel 4.16.18, second
> 3. Execute update-grub
> 4. This created /boot/grub/grub.cfg
> 5. The 1st (default) entry in grub.cfg was for newest kernel vmlinuz-4.17.3-041703-generic
>
> The newest kernel takes precedence, regardless of the order in which
> kernels are installed.

Hi,

That'ss because the kernel and initrd versions are sorted:

   /usr/sbin/update-grub
     /usr/sbin/grub-mkconfig
       /etc/grub.d/10_linux
         /usr/share/grub/grub-mkconfig_lib
           version_find_latest ()

> sudo bash -x /usr/sbin/grub-mkconfig -o testing.cfg
> [...]
> + test -x /etc/grub.d/10_linux
> + echo
> + echo '### BEGIN /etc/grub.d/10_linux ###'
> + /etc/grub.d/10_linux
> Found linux image: /boot/vmlinuz-4.18.0-17-generic
> Found initrd image: /boot/initrd.img-4.18.0-17-generic
> Found linux image: /boot/vmlinuz-4.18.0-16-generic
> Found initrd image: /boot/initrd.img-4.18.0-16-generic
> + echo '### END /etc/grub.d/10_linux ###'
> [...]

So, you're right that the symbolic links are not a reliable default.

HTH,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[PJSingh5000 (pjsingh5000)]

The following changes are available in the development branch:

* Cubic now defaults to the newest kernel as the bootstrap kernel.

* For server images, Cubic no longer defaults to the original iso bootstrap kernel. For server images, Cubic now defaults to the newest kernel as the bootstrap kernel. The message 'Select this option since you are customizing a server image' is no longer displayed next to the original iso's bootstrap kernel.

* Removed the message, 'This kernel will be used by your customized Linux filesystem,' because the message relied the initrd and vmlinuz symlinks in the root directory to identify the default kernel. These symlinks are not an accurate way to determine the default boot kernel.

* The list of available bootstap kernels is now sorted from newest to oldest, so the selected default is always the first item in the list.

[PJSingh5000 (pjsingh5000)]

Would you please test the fix for this issue in the *Development* branch, and let me know if it resolves your problem?

    # Remove Cubic
    $ sudo apt autoremove --purge cubic

    # Remove the *Release* repository
    $ sudo apt-add-repository --remove ppa:cubic-wizard/release

    # Add the *Development* repository
    $ sudo add-apt-repository ppa:cubic-wizard/development

    # Install the *Development* version of Cubic
    $ sudo apt update
    $ sudo apt install cubic

[Cubic PPA (cubic-wizard)]

Fix is now availabe in *Release* branch, revisoon 54.

If you have the Release PPA enabled...

    $ sudo apt update
    $ sudo apt install cubic

If you have the Development PPA enabled...

    # Remove Cubic
    $ sudo apt autoremove --purge cubic

    # Remove the *Development* repository
    $ sudo apt-add-repository --remove ppa:cubic-wizard/development

    # Add the *Release* repository
    $ sudo add-apt-repository ppa:cubic-wizard/release

    # Install the *Release* version of Cubic
    $ sudo apt update
    $ sudo apt install cubic

[Tony Travis (ajtravis)]

On 27/04/2019 01:06, Cubic PPA wrote:
> Fix is now availabe in *Release* branch, revisoon 54.
>
> If you have the Release PPA enabled...
>
> $ sudo apt update
> $ sudo apt install cubic
>
> If you have the Development PPA enabled...
> [...]

Hi,

Sorry, I didn't have time to check the development version before
version 54 was released. I've been testing version 54 and I found a
potential problem if the linux-image supporting the original ISO boot
kernel OUTSIDE has been purged in the Cubic chroot in this example:

The new default ISO boot kernel is set correctly to 4.18.0-18, but the
original ISO boot kernel 4.18.0-15 is still offered as an alternative,
despite the supporting linux-image-4.18.0-15-generic being purged when
remastering Ubuntu-MATE 18.04.2 LTS.

# In the Cubic chroot before making any changes
> root@pilot:~ # dpkg -l 'linux-image*'
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-===================================-======================-======================-===========================================================================
> un linux-image <none> <none> (no description available)
> ii linux-image-4.18.0-15-generic 4.18.0-15.16~18.04.1 amd64 Signed kernel image generic
> ii linux-image-generic-hwe-18.04 4.18.0.15.65 amd64 Generic Linux kernel image
> un linux-image-unsigned-4.18.0-15-gene <none> <none> (no description available)

# Upgrade the chroot
> root@pilot:~ # apt update
> root@pilot:~ # apt full-upgrade
> root@pilot:~ # dpkg -l 'linux-image*'
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-===================================-======================-======================-===========================================================================
> un linux-image <none> <none> (no description available)
> ii linux-image-4.18.0-15-generic 4.18.0-15.16~18.04.1 amd64 Signed kernel image generic
> ii linux-image-4.18.0-18-generic 4.18.0-18.19~18.04.1 amd64 Signed kernel image generic
> ii linux-image-generic-hwe-18.04 4.18.0.18.68 amd64 Generic Linux kernel image
> un linux-image-unsigned-4.18.0-15-gene <none> <none> (no description available)
> un linux-image-unsigned-4.18.0-18-gene <none> <none> (no description available)

# purge the linux-image supporting the original ISO boot kernel
> root@pilot:~ # apt purge linux-image-4.18.0-15-generi
> root@pilot:~ # dpkg -l...

[Cubic PPA (cubic-wizard)]

Tony,

The purpose of the Boot Kernels tab in Cubic is to allow you to pick a bootstap kernel for your ISO.

The kernel list comes from two places:
1. The kernels you have installed in your chroot environment (i.e. your customized linux system).
2. The original bootstrap kernel OUTSIDE your chroot. (There is a message next to the kernel in the list explaining this).

So #2 is always offered as a bootstrap kernel, since some users may want to use that to bootstrap. Everybody has a different use case.

Remember, even though you may have removed this kernel inside chroot, you din't remove it from the ISO. The only way to remove it from the new ISO is by selecting a different kernel on Cubic's Boot Kernel tab and clicking Generate.

If you create a new Cubic project using your remastered ISO, you will see that your new kernel is the "new original" bootstrap kernel, and not the one that came with the original ISO.

[Tony Travis (ajtravis)]

On 27/04/2019 16:35, Cubic PPA wrote:
> Tony,
>
> The purpose of the Boot Kernels tab in Cubic is to allow you to pick a
> bootstap kernel for your ISO.

Hi,

Yes, I know that :-)

> The kernel list comes from two places:
> 1. The kernels you have installed in your chroot environment (i.e. your customized linux system).
> 2. The original bootstrap kernel OUTSIDE your chroot. (There is a message next to the kernel in the list explaining this).
>
> So #2 is always offered as a bootstrap kernel, since some users may want
> to use that to bootstrap. Everybody has a different use case.
>
> Remember, even though you may have removed this kernel inside chroot,
> you din't remove it from the ISO. The only way to remove it from the new
> ISO is by selecting a different kernel on Cubic's Boot Kernel tab and
> clicking Generate.

The reason I reported this issue is that if you DO select the original
OUTSIDE kernel after the linux-image supporting it INSIDE has been
removed you end up with a broken ISO that boots to BusyBox. This is a
potential problem that could be avoided by Cubic only offering ISO boot
kernels OUTSIDE that it verifies have the linux-image support INSIDE.

This is a potential trap for anyone, like me, who wants an upgraded ISO
with only one kernel in it - I've been checking manually that the ISO
boot kernel offered by Cubic has a supporting linux-image installed in
the chroot before generating a new ISO image, but I think it would be
useful if Cubic did the check automatically to avoid a BusyBox prompt.

HTH,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[Cubic PPA (cubic-wizard)]

Reopening bug. See Comment #18 (https://bugs.launchpad.net/cubic/+bug/1825586/comments/18).

[Pico (picomitchell)]

I'm not familiar enough to know if the issues I've just run into is related to this, but it seems similar.

With Cubic 2019.04-54 the ISO Boot Kernel defaults to "the kernel version you are currently running". I believe before it defaulted to "the kernel used to boot the original live ISO".

When I generate an ISO with this new default option selected, and then try to boot to it I hit BusyBox and the error "(initramfs) Unable to find a medium containing a live file system".

If I generate a new ISO with "the kernel used to boot the original live ISO" selected I can boot up just fine.

I did notice that the Boot Files listed in Cubic are "vmlinuz-4.15.0-48-generic" and "initrd.img-4.15.0-20-generic" (notice the non-matching versions). While "initrd.img-4.15.0-20-generic" does exist in "squashfs-root/boot/" I also see "initrd.img-4.15.0-48-generic". Should this higher version be getting selected by Cubic?

I didn't do any specific customization to the Boot Kernel other than running system updates in chroot.

I'm not sure if there's some other bug going on here that I don't understand, but I'm thinking that it would at least be nice if Cubic remembered which kernel I selected last time so that I don't have to remember to change this each time I update the iso.

[Tony Travis (ajtravis)]

On 29/04/2019 21:54, Pico wrote:
> I'm not familiar enough to know if the issues I've just run into is
> related to this, but it seems similar.
>
> With Cubic 2019.04-54 the ISO Boot Kernel defaults to "the kernel
> version you are currently running". I believe before it defaulted to
> "the kernel used to boot the original live ISO".
>
> When I generate an ISO with this new default option selected, and then
> try to boot to it I hit BusyBox and the error "(initramfs) Unable to
> find a medium containing a live file system".
> [...]

Hi,

This is because the linux-image supporting the running kernel in your
build system is not present in the Cubic chroot: My proposal is that
Cubic should check to ensure the linux-image supporting the ISO boot
kernel is present before offering it as a default or optional kernel.

HTH,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[Cubic PPA (cubic-wizard)]

Pico,

The kernel mismatch is indeed a bug.
I'm in the process of working on it, but haven't opened a bug report for it yet.
If you like, you can open the bug report, and include the relevant information.

[Cubic PPA (cubic-wizard)]

Regarding the boot file mismatch, please see Bug #1827157, "The vmlinuz and initrd versions listed on the ISO Boot Kernel tab do not match."

[Cubic PPA (cubic-wizard)]

I conducted the following test using Cubic Version 2019.04-54.

This test did not result in a "BusyBox".

I tested using kernel versions 4.18.0-18 and 4.18.0-15 which are VERY similar.

May be the issue occurs when "INSIDE" and "OUTSIDE" kernel versions are significantly different from each other? I will repeat the test with a very different kernel, perhaps something like 5.0.0-13-generic.

TEST 1
------

(1)
I created a project in Cubic using:

    ubuntu-18.04.1-desktop-amd64.iso

(2)
I upgraded:

    $ apt updated
    $ apt upgrade

(3)
I added the missing package:

    $ apt install --reinstall linux-image-4.18.0-15-generic

(4)
I did not do any additional customization.

(5)
I noticed that in /boot, the newest kernel was 4.18.0-18-generic.

    $ ls -1 /boot/{vmlinuz,initrd}*
        /boot/initrd.img-4.18.0-15-generic
        /boot/initrd.img-4.18.0-18-generic
        /boot/vmlinuz-4.18.0-15-generic
        /boot/vmlinuz-4.18.0-18-generic

(6)
I purged all kernels, except 4.18.0-18-generic.

    $ dpkg -l linux-* | awk '/^ii/{ print $2}' | grep -v -e `echo 4.18.0-18-generic | cut -f1,2 -d"-"` | grep -e [0-9] | grep -E "(image|headers|modules)" | xargs sudo apt-get -y purge

(7)
I verified that only kernel 4.18.0-18 files remained.

    $ ls -1 /boot
        config-4.18.0-18-generic
        efi
        grub
        initrd.img-4.18.0-18-generic
        memtest86+.bin
        memtest86+.elf
        memtest86+_multiboot.bin
        System.map-4.18.0-18-generic
        vmlinuz-4.18.0-18-generic

    $ ls -1 lib/modules
        4.18.0-18-generic

(8)
On Cubic's ISO Boot Kernel tab, I selected the LAST item in the list.
(This is the "OUTSIDE" kernel).

    4.18.0-15 (vmlinuz, initrd)

(9)
I generated the new *.iso.

(10)
When I booted this ISO into VirtualBox, it booted just fine.

(11)
I clicked the "Try" button.
This booted me into the live environment without issue.

(12).
I confirmed that the working kernel was the "OUTSIDE" kernel

    $ uname -r
        4.18.0-15-generic

(13)
I opened a terminal window and confirmed that this kernel was not installed.

    $ ls -1 /boot
        config-4.18.0-18-generic
        efi
        grub
        initrd.img-4.18.0-18-generic
        memtest86+.bin
        memtest86+.elf
        memtest86+_multiboot.bin
        System.map-4.18.0-18-generic
        vmlinuz-4.18.0-18-generic

TEST 2
------

(1)
I opened the same Cubic project as above.

(2)
I did not make any changes.

(3)
On Cubic's ISO Boot Kernel tab, I selected the FIRST item in the list.
(This is the "INSIDE" kernel).

    4.18.0-18 (vmlinuz-4.18.0-18-generic, initrd.img-4.18.0-18-generic)

(4)
I generated the new *.iso.

(5)
When I booted this ISO into VirtualBox, it booted just fine.

(6)
I clicked the "Try" button.
This booted me into the live environment without issue.

(7)
I confirmed that the working kernel was the "INSIDE" kernel

    $ uname -r
        4.18.0-18-generic

[Tony Travis (ajtravis)]

On 01/05/2019 03:58, Cubic PPA wrote:
> I conducted the following test using Cubic Version 2019.04-54.
>
> This test did not result in a "BusyBox".
>
> I tested using kernel versions 4.18.0-18 and 4.18.0-15 which are VERY
> similar.
>
> May be the issue occurs when "INSIDE" and "OUTSIDE" kernel versions are
> significantly different from each other? I will repeat the test with a
> very different kernel, perhaps something like 5.0.0-13-generic.

Hi,

I used mkusb/dus to create a 'live' USB-stick from the ISO I generated
using Cubic and booted the target system from the USB-stick and that is
when I got BusyBox. Using an OUSIDE kernel with a supporting linux-image
in the ISO avoided BusyBox. I'll do it again to confirm the bug is real.

Thanks for the time you've spent resolving this issue,

   Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. [phone] http://minke-informatics.co.uk
mob. [phone] mailto:<email address hidden>

[Cubic PPA (cubic-wizard)]

OK. Thanks. I test with mkusb/dus.

[Cubic PPA (cubic-wizard)]

Performed additional tests using ubuntu-mate-18.04.2-desktop-amd64.iso.

Performed three tests using:
    (a) Kernel 4.18.0-15 (original Kernel on the ISO).
    (b) Kernel 4.18.0-18 (obtained via `apt full-upgrade`).
    (c) Kernel 5.0.15-050015 (obtained from http://Kernel.ubuntu.com/~Kernel-ppa/mainline/).

    Note, in the tests below, "Outside" bootstrap Kernel was version 4.18.0-15.
    I did not install any additional software or drivers, other than upgrading using `apt full-upgrade`.

[Test 1.1 and Test 1.2]

Installed newer Kernel (version 4.18.0-18 or version 5.0.15-050015).
Selected "Outside" Kernel (version 4.18.0-15) as bootstrap Kernel before generating ISO using Cubic.
ISO booted in VirtualBox, without issue.
ISO installed in VirtualBox, without issue.

Created USB using mkusb/dus.
USB booted without issue.
Clicked "Try" button and was taken to the Live desktop without issue.
I did not install onto hardware, but assume the result will be similar to the VirtualBox test above.

[Test 2]

Opened same project in Cubic.
Removed oldest "Inside" Kernel (version 4.18.0-15) matching "Outside" Kernel (version 4.18.0-15).
Selected "Outside" Kernel (version 4.18.0-15) as bootstrap Kernel before generating ISO using Cubic. (Note this Kernel no longer exists in the customized Linux file system, but of course is still available on the ISO "Outside" of the customized Linux file system).
ISO booted in VirtualBox, without issue.
ISO installed in VirtualBox, without issue.

Created USB using mkusb/dus.
USB booted without issue.
Clicked "Try" button and was taken to the Live desktop without issue.
I did not install onto hardware, but assume the result will be similar to the VirtualBox test above.

[Test 3]

Opened same project in Cubic.
Selected newest "Inside" Kernel (version 5.0.15-050015) as bootstrap Kernel before generating ISO using Cubic.
ISO booted in VirtualBox, without issue.
ISO installed in VirtualBox, without issue.

Created USB using mkusb/dus.
USB booted without issue.
Clicked "Try" button and was taken to the Live desktop without issue.
I did not install onto hardware, but assume the result will be similar to the VirtualBox test above.

[Cubic PPA (cubic-wizard)]

Based on test results, closing bug report.

- Trunk version 2019.05-204-development

- Release version 2019.05-55-release