Lunar (daily): bootloader could not be installed

For the packager(s) of Lubuntu Lunar

When I was trying to install 23-04 (to be precise the daily-file downloaded on 21th January) I ran into the problem - at the end of the installation - that ‘‘’’ could not be found on location ‘’/usr/lib/grub/x86_64-efi’‘. However, it exists at ‘’/usr/lib/grub/i386-pc’.

After adding symbolic link ‘’/usr/lib/grub/x86_64-efi’’ pointing to the ‘‘i386-pc’’ directory, I was able to reinstall with success (in the same live session).

I’ve been using and installing the ‘‘21th January’’ version many times already on other machines. I guess the problem is that the laptop I used it on this time works with 64-bit architecture, but is using a 32-bit UEFI bootloader. Not sure about this, however.

Anyway, I know now how to solve this, but it would be nice if it could be fixed before the final 23-04 release is due (if it hasn’t been fixed already).

An alternative to reinstall from the start would have been to ‘‘chroot’’ and continue where Calamares stopped. That would have saved some time, but the result is the same.

As I said, I did not reproduce it, but this is my idea about this.


Thanks, will try to reproduce and find out what’s going on there. Did you check your ISOs SHA256 hash?

1 Like

No, I will check that later today. I forgot to mention that it is not inherited from Calamares perse. I also tested SparkyLinux on the same laptop. That installed without any ado.

If I am able (read: find the means, motive and opportunity), I will reinstall the machine with the latest daily ISO, and pkexec calamares with debugging level set to 8. Perhaps there is a clue in the logging.

1 Like

Sounds like a plan, though do be aware that sometimes putting Calamares into intensive debug mode will actually “fix” whatever it’s doing wrong :stuck_out_tongue: This doesn’t look like a Calamares bug though, so anyway, will work on it.


I’m guessing this problem either was fixed or there’s something weird with your setup - I just downloaded the latest (February 2nd) ISO and it installed it into both a BIOS and an EFI virtual machine. Everything worked just fine as far as the installation process.

I see. Well, I’ve repeated it (just) with the 2nd Febr. ISO (with checked SHA sum). It still persists. Below the relevant last part of calamares session.log.

2023-02-03 - 06:26:59 [6]: virtual void Calamares::JobThread::run()
    Starting job "bootloader" ( 33 / 39 ) 
2023-02-03 - 06:26:59 [6]: virtual Calamares::JobResult Calamares::PythonJob::exec()
    Job file "/usr/lib/x86_64-linux-gnu/calamares/modules/bootloader/" 
2023-02-03 - 06:26:59 [6]: [PYTHON JOB]: Found gettext "en_US" in "/usr/share/locale/en_US" 
2023-02-03 - 06:26:59 [6]:     .. Job description from pretty_name "bootloader" = "Install bootloader." 
2023-02-03 - 06:26:59 [6]: [PYTHON JOB]: "Bootloader: grub (efi)" 
2023-02-03 - 06:26:59 [6]:     .. Running ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=ubuntu", "--force") 
2023-02-03 - 06:27:07 [6]:     .. Target cmd: ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=ubuntu", "--force") Exit code: 1 output:
 Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: Input/output error.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Input/output error.
grub-install: error: failed to register the EFI boot entry: Input/output error.
2023-02-03 - 06:27:07 [2]: WARNING: [PYTHON JOB]: "Command 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --force' returned non-zero exit status 1." 
2023-02-03 - 06:27:07 [6]: [PYTHON JOB]: "stdout:Installing for x86_64-efi platform.\ngrub-install: warning: Cannot set EFI variable Boot0000.\ngrub-install: warning: efivarfs_set_variable: writing to fd 6 failed: Input/output error.\ngrub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Input/output error.\ngrub-install: error: failed to register the EFI boot entry: Input/output error." 
2023-02-03 - 06:27:07 [6]: [PYTHON JOB]: "stderr:None" 
2023-02-03 - 06:27:07 [6]: virtual void Calamares::JobThread::run()
    Skipping non-emergency job "Contextual Processes Job" 
2023-02-03 - 06:27:07 [6]:     ..  Skipping non-emergency job "automirror" 
2023-02-03 - 06:27:07 [6]:     ..  Skipping non-emergency job "Shell Processes Job" 
2023-02-03 - 06:27:07 [6]:     ..  Skipping non-emergency job "packages" 
2023-02-03 - 06:27:07 [6]:     ..  Skipping non-emergency job "Shell Processes Job" 
2023-02-03 - 06:27:07 [6]:     ..  Skipping non-emergency job "Unmount file systems." 
2023-02-03 - 06:27:07 [1]: void Calamares::ViewManager::onInstallationFailed(const QString&, const QString&)
    ERROR: Installation failed: "Bootloader installation error" 
2023-02-03 - 06:27:07 [6]:     .. - message: "Bootloader installation error" 
2023-02-03 - 06:27:07 [6]:     .. - details: The bootloader could not be installed. The installation command <pre>grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --force</pre> returned error code 1.
2023-02-03 - 06:27:08 [6]: void Calamares::ViewManager::onInstallationFailed(const QString&, const QString&)
    Calamares will quit when the dialog closes. 
2023-02-03 - 06:27:08 [6]: void Config::doNotify(bool, bool)
    Notification not sent; completion: failed 

Maybe its just a manifestation of an edge case, a peculiarity of the h/w of my great little Toshiba Satellite laptop. I guess there will not be many new users of Lubuntu on this particular machine (great in all its smallness, except for the spacebar on its keyboard which is just about one thumb smaller than other competitors in the mini-netbook range :frowning: ).

Unless someone else complains: don’t spend any more time on it. I know how to fix it :slight_smile:

It may not hurt to quickly describe how you fix it here, in case other users find this thread looking for clues (on their own failures to install bootloader; I see issues on this somewhat regularly on support sites)

Thanks for reporting your problem though, and helping to make Lubuntu better.

(ps: don’t worry about going off-topic on this thread; I can move it if needs be)

1 Like

Thanks for your time. As always I appreciate the effort of you and your team!

The solution is decribed in my first ‘‘installment’’ (a bit obfuscated).

I guess there is a shortcut possible which avoids reinstalling from the start all over again. Lubuntu is already installed (except for the grub part and what follows after that). I could elaborate on that.


Oh, weird. I see input/output errors while trying to write to the NVRAM. I wonder if that’s somehow related. I would say it probably is hardware-specific, but if symlinking a file fixed the problem, maybe that’s worth looking into further (though I do wonder if maybe your symlink made GRUB’s attempted EFI installation actually do a BIOS installation).


Can you please show

cat /sys/firmware/efi/fw_platform_size


The result is 64

How can I tell if its BIOS or EFI?

If the files under /sys/firmware/efi exist, it means that the operating system is booted in UEFI mode.

And your firmware is using 64 bits, so you can use also the 64 bit bootloaders (shimx64.efi and grubx64.efi).

Please make absolutely sure that your installation image is not corrupt (otherwise all kind of errors can happen).

At this stage of the installation, grub is successfully installed on the EFI System Partition. But in the second step it tries to create a boot entry that points to the installed bootloader. And there is an Input/Output error. One possible reason is that any write access to the NVRAM is blocked by the firmware. In this case you can maybe change the UEFI settings.
Another reason is that the space in NVRAM is full.
It is also possible that the firmware is too old (flash newer version) or is following the “it just needs to boot windows and we do not care about specs” philosophy.

1 Like

Interesting to know. Very interesting.

However, to eliminate my current problem due to corrupt image, I’ve downloaded the latest daily again, checked the sha256sum, put it on a stick, and the result is still the same error.

It is specific for at least Lunar, since in the past I could install L22-04 without any problem. SparkyLinux 7 will install as well.

I’ve been doing some emperical testing (not analysing):

  • Lubuntu 22.10 will also not install (with same symptom)
  • Lubuntu 22.04 will install

I’m dying to know the 'root cause, but I’ve spend already a lot of time, and can circumvent the problem.

Perhaps it should be resolved. It is suspicious to say the least, and perhaps that new aspirant Lubuntu users have experienced (or will experience) the same. It would be a pity and a shame to loose new customers.

“We don’t want new users to move on to yet-another-distro”… keeping a bad impression of Lubuntu in their minds, as being rough and unfinished.

The case is closed for me. I am obliged to be of any assistence (‘reinstalling’) might that be requested, now or in the future.

If you have different results with the exactly same steps for different ISO files, then it looks like some bug in the newer release.

The problem is, that other people cannot reproduce this.

There are changes in the calamares and grub packages.

I remembered yesterday that I’d ran into the problem with a pre-release version of 22.10 last fall, and then I did not bother, and just installed 22.04. Anticipating that it was a daily-glitch, and would be observed by others, and fixed. Well, I forgot all about that, and ran into the same problem with pre-23.04.

Or…maybe the same error. Last night I saved session.log files from both attempts, but I have not had the time to inspect them.

It is a bit time consuming that the ‘mother-OS’ is destroyed every time. So, after reinstalling, seeing the error again, adding the symbolic link, and reinstalling again (from the start), easily one hour passes. The Toshiba mini-netbook is not the quickest. This way, adding ‘breakpoints’ or adequate extra logging in Calamares module(s) is absolute out of the question.

I am now working on a hopefully more productive way that keeps the mother OS intact, and installs on an external USB-SSD. To speed up things, I will also try to run Calamares from the stable (23.04) OS (with the configuration and squash copied from the live system).

Another strange thing for me is, that if I add the symlink before I start the first install, it will also fail. Tested it a few times. The symlink really needs to be constructed after the first try.

Calamares has mysterious ways…

Calamares is a great tool, with a beautiful user interface, and a good backend system.

A nice piece of software. Millions, perhaps even already billions of machines have been set up using it.

My ‘calle’, the way I want to go with it as described above, is perhaps not what it is designed for (or maybe it is). As usual with declarative systems, you should honour and know unwritten conventions, and clearly I am not (yet) good at that :stuck_out_tongue:

I think I will manage in the end to be able to generate a Linux system from inside another running Linux machine, while both machines are not necessarily related to each other (like you distribution guys do all the time). Apropo… in my native language such a generative system is often called a “straatje” (literal: a little street, yeah it is a metaphor).

When I’ve reached that point, I will first try to find a shortcut that enables me to use Calamares without having to wait while the whole squashed filesystem is written to disk again.

And then to think that I’ve only revived the particular laptop with this ‘bug’ because I wanted to check if its bluetooth still functions well for doing some Qt development with LXQt 1.2.0+. And only because an old USB dongle turned out to be faulty. As you may have deduced already, I have lots of idle time while Calamares is running…

1 Like

What a week it has been!

I’ve read a lot, about chroot-ing, Calamares, GRUB, subsystem mounting, bind-mounts, and much more.

This week I’ve crafted a tiny script that enables me to repeat the mounting of an ISO file to a stable OS, and next, chroot into it. The result is almost as if the live-environment was started from an USB stick.

Almost… the actual kernel of the host and the kernel the live system requires should be compatible. Besides, the chroot-ed environment has no D-Bus and systemd, but it will run several graphical applications (on the screen of the host), including Calamares. And that matters.

Using this method I am able to persist the “live”-environment (of an ISO delivering itself in statu nascendi). I am able to play with its Calamares setting and provided configurations, persist its logfiles, etc. And… important for me, install the OS to an external SSD (and not wipe away the host OS).

If tried it first on decent hardware, and not on ye olde laptop that made me do all this.

Gaining speed throughout means gaining momentum, not spending (or loosing) a lot of time on outdated and minimal hardware, and foremost not ruining the target disk.

I’ve succeeded in the end. Done development and testing with a specimen of Lubuntu 23.04 OS, and it installs without problem on hardware where it already would install from USB.

When I tried the procedure on the troubled laptop with an (recent, but not too recent) ISO of Lubuntu 23.04 the result was as expected: failure to install. This is what I’d been expecting.

So, I am now all set and done to figure out the why of my problem with Lubuntu 23.04 on my little laptop. I also found out how to compile Calamares from source in my live environment (just in case debugging of its Python scripts would not suffice).

However…before diving into the configuration and greasy details of Calamares (being able to do this was the reason I have been doing this excercise in the first place), I’ve tried my script one more time with an absolute recent daily ISO of Lubuntu 23.04 (and not one from January 20th).

To my surprise: this daily will install on my troublesome laptop. Autonomously (from stick) and also with the help of my script.

So, most likely I’ve escaped from another week of reading and debugging Calamares Python code, and who knows what more. This case is now definitively closed for me.

What a week it has been :grinning:

PS: Calamares is not intended to be used like I’ve been doing, and there where a few small glitches at the end of the whole processing, after the bootloader step. I did not bother about them, and worked around them.

PS2: I saw that the calamares software as packaged by Ubuntu (I guess) differs a bit in version numbering between around January 20th and yesterday.