Ubuntu
calamares package

lubuntu focal.2 "sfdisk --force --append /dev/sda"

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

Bug Description

Lubuntu 20.04.2 RC/daily QA-test install on
- dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt)

Testcase: Install Alongside (prior install was a Xubuntu focal.2 I believe)

This was unexpected, as I've only had the 1864787 issue on a different box (an older d755) before, which had a more complex partition layout.

This is 99.9% likely to be marked duplicate of https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1864787

--- Steps to re-produce:

1: full disk install Lubuntu/Xubuntu (occurred after each)
2: reboot & do another install using "Install alongside" of Lubuntu 20.04.2

(no changes made to disk allocation, just use defaults; details entered shouldn't matter but I used "guiverc", "Chris Guiver" & password is usually "please" for QA-test installs.. machine name used varies but usually "d755-8" for box mentioned in this report).

Two outcomes

- 98% of time successful install (expected outcome)
- at most 2% time this failure (the problem)

This issue is not predictable on this box. For some reason the other bug report (1864787) had a far higher failure rate.

---
The installer failed to create partition on disk 'WDC WD800AAJS-60B4A0'.
========================================================================================== Create a new partition (37.01 GiB, ext4) on ‘/dev/sda’ ========================================================================================== ========================================================================================== Job: Create new partition on device ‘/dev/sda’ ========================================================================================== ========================================================================================== Command: sfdisk --force --append /dev/sda ========================================================================================== Failed to add partition ‘New Partition’ to device ‘/dev/sda’. Failed to add partition ‘New Partition’ to device ‘/dev/sda’.
---

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: calamares 3.2.20-0ubuntu1
ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-41-generic x86_64
.etc.calamares.modules.finished.conf:
 ---
 restartNowMode: user-checked
 restartNowCommand: "systemctl -i reboot"
.etc.calamares.modules.partition.conf:
 efiSystemPartition: "/boot/efi"
 enableLuksAutomatedPartitioning: true
 userSwapChoices: none
 drawNestedPartitions: true
 defaultFileSystemType: "ext4"
.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.11-0ubuntu27.16
Architecture: amd64
CasperVersion: 1.445.1
CurrentDesktop: LXQt
Date: Thu Feb 4 13:02:39 2021
LiveMediaBuild: Lubuntu 20.04.2 LTS "Focal Fossa" - Release amd64 (20210202)
RelatedPackageVersions:
 calamares-settings-ubuntu-common 1:20.04.2
 calamares-settings-lubuntu 1:20.04.2
 xfsprogs 5.3.0-1ubuntu2
 btrfs-progs 5.4.1-2
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)
summary: - lubuntu focal.2 force append
+ lubuntu focal.2 "sfdisk --force --append /dev/sda"
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/1914521

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

I need exact steps to reproduce this, starting with required conditions. This has been so elusive because of that.

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

The steps required to re-produce are

1: full disk install Lubuntu/Xubuntu (occurred after each, 20.04.2)
2: reboot & do another install using "Install alongside"

(no changes made to disk allocation, just use defaults; details entered shouldn't matter but I use "guiverc", "Chris Guiver" & password is usually "please" for QA-test installs.. machine name used varied but usually "d755-8" for box mentioned in this report).

Two outcomes

- 98% of time successful install
- at most 2% time this failure

I'm still 99.9% this is a duplicate.. but it doesn't always occur, and when it does, it's the exact same thing as had no issues other times.

This setup is far simpler to create than https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1864787 which had a more complex partition layout. To me the outcome looked the same though.

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

I have not had this issue in hirsute (or ever before using these steps).

I expect to do a number of installs in coming ~week looking for this issue (1914521) & even 1864787 using the hirsute release.

Replicating this setup is easy (standard QA-test install, then a second "install alongside") taking only time.. This system is old and has spinning-rust drive, thus time.

I've not had this issue before; only 1864787 which I assumed related to a complex partition scheme..

Installs using this exact procedure (and thus partition layout) are done maybe 100 times per cycle as easy to do and most efficient way to test for
- full disk install (any non-encrypted testcase)
- install alongside
at least that's how I do those two testcases...

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

Of note..

Last change to calamares is 27-Feb-2020 kc2bez; (http://changelogs.ubuntu.com/changelogs/pool/universe/c/calamares/calamares_3.2.20-0ubuntu1/changelog)

Last release I would have used box to test with SIGNIFICANTLY is 20.04.1 (https://fridge.ubuntu.com/2020/08/06/ubuntu-20-04-1-lts-released/)

thus NO CHANGES WERE MADE to code, yet I had not experienced this before with this COMMON install routine (full disk followed by install alongside).

I've had the opinion that 1864787 would occur on multiple spins of ISO, then stop occurring awhile, before it re-occurred.. (ie. no related code changes, just re-spin of ISO on new daily). When issue occurred (ie. specific daily ISO), it was easy to re-create, on other ISOs (different daily) I couldn't get issue to occur.

The two dailies this occurred on I believe had no meaningful change, http://iso.qa.ubuntu.com/qatracker/reports/bugs/1914521 which I believe was (#ubuntu-flavors)

"<sil2100> We have to fix a rather obscure, but serious (for OEM scenarios) ubuntu-drivers-common bug
<sil2100> Meaning we'll have to eh, respin the desktop isos"

but even for dailies before then (when issue did not occur), I can't see how the lower Ubuntu infrastructure changes could cause it to work flawlessly, then not...

My point is, I'm not convinced this is worth effort, at least with older focal code (3.2.20-0ubuntu1)

If it occurs with hirsute.. then yep as it's later code (two upstream releases later currently).

To post a comment you must log in.