Pop!_OS 20.04 (13) Respin Issue

What files do you see listed on the ISO Boot tab in Cubic on the Options page?

(Also, please share the download link you used for Pop OS, so I can download and test the same version as you).

hello.

thank you for the quick response.

here is my setup process. https://www.youtube.com/watch?v=baA4vdNxpa0

and here is my installation process with error. https://www.youtube.com/watch?v=Apv5L3nBbIY

videos might be a bit rough / unnecessary, but i figured i needed to reset my system to get the file names anyway...

the files listed on the iso boot tab in cubic are

version: 5.4.0-7642, vmlinuz.efi, initrd.gz

version: 5.4.0-7642, vmlinuz-5.4.0-7642-generic, initrd.img-5.4.0-7642-generic.

the link is from https://pop.system76.com/ to this file. https://pop-iso.sfo2.cdn.digitaloceanspaces.com/20.04/amd64/intel/13/pop-os_20.04_amd64_intel_13.iso

thanks!

i am dumb. i just realised i skipped over the iso boot tab. i'll get this information again soon.

hello,

here's another video with the tabs selected through https://youtu.be/q-DlwnccVMI?t=152

the files are

/boot/grub/grub.cfg
/isolinux/isolinux.cfg

thank you!

I downloaded the official ISO from the link you provided.

It is interesting that the actual "casper" directory is named "casper_pop-os_20.04_amd64_intel_debug_25" (and "capser" is a symlink to this directory).

Note the word "debug" in the directory name.

This is a bit surprising for a production ISO, since the name implies the ISO is not-production ready.

Nevertheless, I will update you when I find what the issue is.

Your boot configuration files look good

    /boot/grub/grub.cfg
    /isolinux/isolinux.cfg

I noticed that PopOS is using the Elementary Installer (io.elementary.installer), instead of ubiquity.

The error occurs when the installer tries to create a PopOS "recovery" partition. At this point, it is looking for "initrd.gz", but this file does not exist. It should really be looking for "initrd" instead.

(The "gz" extension implies that initrd is compressed using the gzip algorithm. I've seen a few other Distros that arbitrarily append *.gz to the initrd file name, even though gzip is not used. I suspect the Elementary Installer simply expects the file to have this name; in other words, it may be hard-coded to look for "initrd.gz").

I'll continue investigating to see if I can come up with a work-around.

My guess is, your OS installs fine in VirtualBox because the installer does not try to create a PopOS recovery partition.

However, when you try to install it onto actual hardware, the installer is able to detect this, and it tries to create a recovery partition.

Is there a way to tell the installer *not* to create the recovery partition?
(Can you use the option to manually create partitions?)

Yes! manually setting up the partitions, removing the recovery partition enabled a complete install. this is nice progress. i wonder if i can edit the installer in a simple yet meaningful way to get around this?

This is what I was looking for.

The PopOS installer is a fork of the Elementary Installer:

    https://github.com/pop-os/installer

However, I couldn't see any place to configure this.

The io.elementary.installer application seems to be a compiled binary.

i've been mildly poking around the differences. on the original ISO, if written to a USB stick, initrd.gz appears as normal. if i respin that ISO and install it on a USB stick, initrd.gz gets stripped of its gz extension.

i'm not sure how yet. but if i manually rename initrd to initrd.gz, and change some of the scripts that obviously reference it, the change doesn't stick. when i click generate, cubic will rename the file back to initrd, without the gz extension.

Cubic will "strip" the extension if initrd is *not* compressed using gzip compression.

See my explanation in comment #7: The "gz" extension implies that initrd is compressed using the gzip algorithm. I've seen a few other Distros that arbitrarily append *.gz to the initrd file name, even though gzip is not used.

There are a few "bugs" here that are contributing to this problem:

1.
PopOS is using the *.gz extension for initrd, even though it is not gzip compressed.
This is kind of like adding a *.zip extension to a text file without actually zipping the file.
They should either use gzip compression or not arbitrarily add this extension to initrd.

2.
According to Elementary, the elementary installer is currently in development, and is not production ready.
However, PopOS forked it ans are using it their distro.

3.
The forked PopOS installer has hard coded "initrd.gz" when copying files to the recovery partition.
They really should use the correct initrd file, regardless of its name so that different compressions algorythms can be used with initrd (i.e. "initrd", "initrd.gz", "initrd.lz").

.

I think bug reports should be opened against some of these issues.

.

Nevertheless, there may be some ways to work around the issues.
Since the name of "initrd" is hard-coded into a compiled binary, this can not be configured.
However, I am trying to come up with other approaches.

Awesome! thank you so much for investigating.

i tried some more pretty loose attempts at tricking it into working. but i couldn't gzip initrd so that it wouldn't be renamed.

The initrd.* file is a CPIO archive (see https://en.wikipedia.org/wiki/Cpio).
I older versions of Ubuntu (prior to ~18.10) the initrd file was compressed using gzip or lzma.

However, in newer versions of Ubuntu, the initrd file contains multiple binary files.
Many of these files are compressed using different formats each (lzma, gzip, etc).
Note that Ubuntu, since ~18.10, seems to have adopted the convention to leave off the extension on the initrd file, since the extension doesn't really make sense in this situation.

Nevertheless, one of the files in the initrd archive is a compressed Linux file system (containing /etc, /lib, /usr, etc.) that is used during the bootstrap process.

We could assume that the extension applied to the initrd file name reflects the compression algorithm used for these Linux file system files (/etc, /lib, /usr, etc.).

Therefore, it is possible that distros such as PopOS follow a convention where they explicitly append the name of the compression algorithm applied specifically to the filesystem files, even though initrd is a collection of many other files.

HOWEVER, when I checked this, I found that the initd file is actually compressed using the LZMA algorithm, even though PopOS names the file initrd.gz (i.e. GZIP)!!!!

PopOS should have named their inird file without an extension (like Ubuntu), or should have named it with the "lz" extension. Unfortunately neither of these would work with their forked version of the Elementary Installer, which has had coded the name "initrd.gz".

I am going to modify Cubic to:

Add an extension to the initrd file based on the compression algorithm applied to the Linux file system files (/etc, /lib, /usr, etc.) *inside* of the CPIO archive.

This is not the convention Ubuntu is following, but it shouldn't be an issue, as long as the initrd file name is referenced correctly in the ISO Boot configurations, which Cubic already does automatically.

How will this help with your problem?...

Once this change is implemented, you will be able to regenerate the inird file using gzip compression.
(I will provide instructions on how to do this, after I complete implementation of the change and verify it works and does not break with other distros).

After the initrd file is regenerated using gzip compression, Cubic will correctly (automatically) name the bootstrap file on the ISO as "initrd.gz".

This is most excellent! Thank you so much!! :D

[1]

Update Cubic and make sure you have the latest version.

    $ sudo apt update
    $ sudo apt install cubic
    $ dpkg -l cubic
        - - - - - - - - - - - - - - - - - - - - - - - -
        cubic - 2020.09-31-release
        - - - - - - - - - - - - - - - - - - - - - - - -

[2]

Follow the instructions at:

    https://answers.launchpad.net/cubic/+question/693009

excellent, thank you very much. i will try this out tonight.

my schedule got a bit unwieldy. i followed the instructions, but it now does a similar thing on vmlinuz when trying to install to real hardware. i haven't had enough of a chance to see where i went wrong. but i thought i would drop a line and say thank you, i tried it.

This is disappointing!

I see that in addition to hard-coding "initrd.gz", they have also hard-coded "vmlinuz.efi"

SEE:

        https://github.com/pop-os/distinst/blob/master/src/installer/steps/configure/chroot_conf.rs

LINES 390 and 391:

        let efi_initrd = self.chroot.path.join([&efi_recovery, "/initrd.gz"].concat());
        let efi_vmlinuz = self.chroot.path.join([&efi_recovery, "/vmlinuz.efi"].concat());

In comparison, Ubuntu/Canonical just names their files "vmlinuz". Iin my opinion, Pop_OS should follow the convention set by Ubuntu/Canonical.

If there were a clear or consistent rule to check when the "*.efi" extension should be used, I could add that to Cubic.

I'll look into this a bit more. If you come across a rule that can be consistently applied (that won't break other distros) please share.

Jimmy,

Based on the information I have been able to gather, vmlinuz.efi is equivalent to vmlinuz.
(The only difference is the extension).

Therefore, Cubic could create a simlink from vmlinuz.efi to vmlinuz.

This may solve your problem.

Let me know if you will be able to test it, if I make this change?

Fix released in version 2020.10-33.

Reference bug #1898749, "Pop!_OS expects vmlinuz on the iso to have the *.efi extension."

Please test this and let me know if it solves your problem.

awesome! i will test all this very soon. i've been busy with paid projects recently, but i have free time tonight. thank you so much!

heyhey! this is awesome! totally works now. you're a legend. thank you so much for addressing these issues for me.

quick screenshot of a freshly installed cubic made pop-os respin https://ibb.co/6RLS7jd

thank you ^_^