Ubuntu
calamares package

19.04 Lubuntu BIOS full-disk install with encryption failed to boot (grub-rescue)

Bug #1822237 reported by Chris Guiver
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calamares (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Lubuntu 19.04 full-disk encrypted install (BIOS)

Install went perfectly, rebooted on request however resulted in finding myself in grub-rescue

error: no such device: 969bff21-1ee3-490a-8922-6fc36941da6f
error: unknown filesystem
Entering rescue mode..
grub rescue >

// please note the ^ messages were written down & later transcribed here; no guarantee on being letter perfect

I rebooted the install-media, and mounted the disk (using my passphrase) and a cursory glance showed no issues. /boot & a few other folders looked like I expected.

(This is the third install on this box last couple of hours as I work down Lubuntu 19.04 checklist so I doubt I did anything wrong, but I have done wrong or in error. I have not re-attempted an encrypted install, but I have re-attempted booting this box since install).

first line of /etc/apt/sources.list
deb cdrom:[Lubuntu 19.04 _Disco Dingo_ - Alpha amd64 (20190326.1)]/ disco main multiverse restricted universe

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: calamares 3.2.4-0ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0
Uname: Linux 5.0.0-7-generic x86_64
.etc.calamares.modules.automirror.conf:
 ---
 baseUrl: archive.ubuntu.com
 distribution: Lubuntu
 geoIpUrl: https://ipapi.co/json
.etc.calamares.modules.finished.conf:
 ---
 restartNowChecked: true
 restartNowEnabled: true
 restartNowCommand: "systemctl -i reboot"
.etc.calamares.modules.partition.conf:
 efiSystemPartition: "/boot/efi"
 enableLuksAutomatedPartitioning: true
 neverCreateSwap: true
 drawNestedPartitions: true
.etc.calamares.modules.shellprocess_logs.conf:
 ---
 dontChroot: true
 timeout: 30
 script:
     - calamares-logs-helper @@ROOT@@
.etc.calamares.modules.unpackfs.conf:
 ---
 unpack:
     - source: "/cdrom/casper/filesystem.squashfs"
         sourcefs: "squashfs"
         destination: ""
ApportVersion: 2.20.10-0ubuntu23
Architecture: amd64
CasperVersion: 1.402
CurrentDesktop: LXQt
Date: Fri Mar 29 05:24:53 2019
LiveMediaBuild: Lubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190326.1)
RelatedPackageVersions:
 calamares-settings-ubuntu-common 1:19.04.3
 calamares-settings-lubuntu 1:19.04.3
 xfsprogs 4.15.1-1ubuntu1
 btrfs-progs 4.20.2-1
SourcePackage: calamares
UpgradeStatus: No upgrade log present (probably fresh install)

See original description
Revision history for this message
Chris Guiver (guiverc) wrote :
description: updated
Chris Guiver (guiverc)
description: updated
Revision history for this message
Chris Guiver (guiverc) wrote :

I just re-tried this on a virtual box VM & it failed too

Host system: hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
Host OS: Fedora 29 x86_64
Virtual Box : 5.2.26 r128414 (Qt 5.6.1)
Lubuntu 19.04 ISO : 20190326.1

Install no issues, i okay reboot and pressed <enter> to remove ISO, rebooted to

error: no such device: f6a33e96-6ae8-4f26-b729-5738e1d447b2
error: unknown filesystem.
Entering rescue mode...
grub rescue>

// the error message was typed by me; may include typos

Revision history for this message
Chris Guiver (guiverc) wrote :

changing to 'confirmed' due to second installation (VM) on different box having same result

Changed in calamares (Ubuntu):
status: New → Confirmed
Revision history for this message
Chris Guiver (guiverc) wrote :

booted 19.04 daily (yesterday's as I checked it too late) and

sudo add-apt-repository ppa:lubuntu-ci/unstable-ci
sudo apt full-upgrade

logout, login back in & install again.

same result; with only UUID value being different.

Revision history for this message
Chris Guiver (guiverc) wrote :

my last comment related to attempt on d780 box or the original box
dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

I retried using 20190330 19.04 Lubuntu daily x86_64 with
sudo add-apt-repository ppa:lubuntu-ci/unstable-ci
sudo apt full-upgrade
logout, login again then install

same result, with different UUID on message.

I did however note that the BOOT-LOADER-LOCATION field which starts as my only hdd, goes blank as Encryption-Passphrases are evaluated (or you get loops). For this (failed) install I ensured it pointed the my HDD.

I'm re-trying these steps, but will leave (boot-loader-location) field blank as it becomes during what I assume is passphrase-validation.

Result is the same :( with only the UUID changing each time (as expected)

Chris Guiver (guiverc)
summary: - 19.04 BIOS full-disk install with encryption failed to boot (grub-
- rescue)
+ 19.04 Lubuntu BIOS full-disk install with encryption failed to boot
+ (grub-rescue)
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1822237

tags: added: iso-testing
Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote :

As it turns out, this was a double-whammy. The new Calamares used a cryptsetup that defaulted to luks2, which grub2 does not support. Ubiquity gets around this by using an unencrypted /boot (ewww). However, you can get cryptsetup to explicitly use one version or the other of luks rather than relying on whatever the default version is. The library used to partition, kpmcore, was modified to do exactly this. Problem fixed:

kpmcore (3.3.0-5) unstable; urgency=medium

  * Use luks1 format only

 -- Jonathan Carter <email address hidden> Sat, 06 Apr 2019 12:40:05 +0200

ԜаӀtеr Ⅼарсһуnѕkі (wxl)
Changed in calamares (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Julian Reith (julz224) wrote :

same error on dell notebook (i686) BIOS, full-disk install, without encryption, with lubuntu 19.04, installed via pxe (2019-07-10)
grub-rescue after reboot
any suggestions?

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote :

Julian, please file a new bug. Those critieria don't fit this one. Please clarify whether or not you checked the disc for defects and how I might reproduce the issue.

To post a comment you must log in.