Lubuntu failed install "sfdisk --force --append /dev/sda"

Bug #1864787 reported by Chris Guiver on 2020-02-26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
calamares (Ubuntu)
Simon Quigley

Bug Description

Lubuntu 20.04 install on
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
(not the d755 that gets/got issue 1851188), but still maybe related

I was attempting to replace sda8 (/ with format; was btrfs), and re-use sda9 (ext4 no format)

My drive mapping is SDA1 (ntfs; xp game), SDA2 extended partition
   with SDA2 extended divided into
   - sda5 swap
   - sda6 lubuntu 18.04 system
   - sda7 lubuntu 18.04 data (/home)
   - sda8 (was btrfs, opensuse system)
   - sda9 (ext4, was opensuse data)

My install attempted to re-format SDA8 for /, re-use sda9 as /home

I was suspicious this related to but no longer think so.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: calamares
ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
Uname: Linux 5.4.0-14-generic x86_64
 restartNowMode: user-checked
 restartNowCommand: "systemctl -i reboot"
 efiSystemPartition: "/boot/efi"
 enableLuksAutomatedPartitioning: true
 userSwapChoices: none
 drawNestedPartitions: true
 defaultFileSystemType: "ext4"
 dontChroot: true
 timeout: 30
     - calamares-logs-helper @@ROOT@@
     - source: "/cdrom/casper/filesystem.squashfs"
         sourcefs: "squashfs"
         destination: ""
ApportVersion: 2.20.11-0ubuntu18
Architecture: amd64
CasperVersion: 1.439
CurrentDesktop: LXQt
Date: Wed Feb 26 15:50:23 2020
LiveMediaBuild: Lubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225)
 calamares-settings-ubuntu-common 1:20.04.2
 calamares-settings-lubuntu 1:20.04.2
 xfsprogs 5.2.1-1ubuntu1
 btrfs-progs 5.4.1-2
SourcePackage: calamares
UpgradeStatus: No upgrade log present (probably fresh install)

Chris Guiver (guiverc) wrote :
description: updated
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:

tags: added: iso-testing
Chris Guiver (guiverc) on 2020-02-26
description: updated
Chris Guiver (guiverc) wrote :

I've had the issue again, same box, reboot & another re-try (4th maybe)

The installer failed to create partition on disk 'ST3160815AS'.
Create a new partition (22.00 GiB, ext4) on ‘/dev/sda’
Job: Create new partition on device ‘/dev/sda’
Command: sfdisk --force --append /dev/sda
Job: Create file system ‘ext4’ on partition ‘/dev/sda9’
Command: mkfs.ext4 -qF /dev/sda9

Attached is NEW session.log (single install attempt only)

Chris Guiver (guiverc) wrote :

same dell optiplex d755

same issue, I didn't see anything in dmesg or journalctrl of note

Chris Guiver (guiverc) wrote :

I tried to use KDE Partition Manager to do what I expected `calamares` to do and got

Could not delete file system on ‘/dev/sda9’.
Delete file system on ‘/dev/sda9’: Error
Delete partition ‘/dev/sda9’ (22.00 GiB, unknown): Error

This issue could be HARDWARE related; so I'll have to look at it
I'll mark this incomplete..

Changed in calamares (Ubuntu):
status: New → Incomplete
Chris Guiver (guiverc) wrote :

I booted the Lubuntu 18.04.4 ISO on live, and couldn't see any issues.
I used `gparted` to firstly delete the sda9 partition, clicked apply. Next I created a new ext4 partition using the space without issue & rebooted

Re-ran Lubuntu 20.04 using new daily and Manual partitioning again
  - sda9 set for system (no format; but empty)
  - sda8 set for /home (no format, old non-Ubuntu data)
and install this time worked.

I am tempted to change this bug report back to 'New' but I'll wait, and in a few days (if I remember) will repeat this install and decide then.

Chris Guiver (guiverc) wrote :

repeat of last test (#7)..
  - / (sda9) partition has lubu system (format),
  - re-use sda8 for /home (no-format)

I was unable to 'select' format for sda9 partition, so I changed format to 'reiser' then accepted; then returned it to ext4 & format was selected..

I have this error again :(

Command: sfdisk --force --append/sda
Command: mkfs.ext4 -qF /dev/sda9

Changed in calamares (Ubuntu):
status: Incomplete → New
Chris Guiver (guiverc) wrote :

Possibly of significance... Post a `calamares` failed install, I cannot use KDE Partition Manager to delete the partition & re-create for another test. ie

- Load KDE Partition Manager
- delete sda9 and click apply
ERROR occurred

If however I reboot and perform the same steps in KDE Partition Manager of deleting the sda9 system partition, apply, then re-create partition using space & no errors occur?!!

In comment #7 I used a 18.04.4 live session to get around repeated failures to delete & re-create partition in 20.04, however I only get the errors AFTER a failed install; KDE Partition manager does it perfectly if calamares hasn't been run.

Walter Lapchynski (wxl) wrote :

This may be this same upstream issue:

Can I get a fresh fail log?

Walter Lapchynski (wxl) wrote :

Actually given that you believe that bug 1864791 is sort of caused by this first occurring, let's try to track this one down further.

The fail log would be especially helpful because there's some new changes to how logging is done. It would be best if you can it with `sudo -E calamares -d` as that will be particularly verbose.

I will also add contrary to my previous message, that *THIS* might actually be the correct upstream issue and it seems it is somehow related to btrfs necessarily adding /home:

Chris Guiver (guiverc) wrote :

Boot daily on d755-5 or box that has been having this issue.

BIOS, no encryption, manual partitioning, internet

Install to replace existing Lubuntu 20.04 with new daily image.

Selected SDA8 - was /home before and will be again, no-format
Selected SDA9 - was / for lubuntu 20.04 before, this had to be selected as new partition 'reiserfs' so I get 'format' to stick, on clicking OK I'd re-enter and change back to 'ext4'

If I select 'format' and let it remain ext4, on re-entry into the area (for validation of entry) it'll be tagged 'keep'. As far as I recall it fails with same issue on keep, but I'm selecting format being what I entered in as purpose of install.

Chris Guiver (guiverc) wrote :

@ Walter/wxl

Attempt to run

lubuntu@lubuntu:~$ sudo -E calamares -d
QStandardPaths: wrong ownership on runtime directory /run/user/999, 999 instead of 0
06:04:35 [6]: Calamares::Settings::Settings(const QString&, bool)
     Using Calamares settings file at "/etc/calamares/settings.conf"
06:04:36 [6]: void Calamares::Module::loadConfigurationFile(const QString&)
     No config file for "umount" found anywhere at
06:04:36 [6]: void Calamares::Module::loadConfigurationFile(const QString&)
     Loaded module configuration "/etc/calamares/modules/finished.conf"
06:04:36 [6]: virtual void Calamares::ViewModule::loadSelf()
     ViewModule "finished@finished" loading complete.
06:04:36 [6]: void CalamaresApplication::initViewSteps()
     STARTUP: loadModules for all modules done
06:04:36 [6]: void Calamares::ModuleManager::checkRequirements()
     Checking module requirements ..
Segmentation fault

lubuntu@lubuntu:~$ ls /var/crash -la
total 4628
drwxrwxrwt 2 root root 4096 Mar 3 06:04 .
drwxr-xr-x 1 root root 120 Mar 2 16:45 ..
-rw-r----- 1 root whoopsie 4734641 Mar 3 06:04 _usr_bin_calamares.0.crash

Chris Guiver (guiverc) wrote :

dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
testcase: BIOS, internet, no encryption, re-use /home thus manual partitioning

I forgot the `sudo -E calamares -d` to cause calamares to get extra debug info, so re-run
boot 'live' system & use KDE partition manager to erase sda9 (prior / which is listed as unknown), apply, then format is ext4 so sda9 again.
deactivate swap then exit KDE partition manager.
open term to use command to run calamares using `sudo -E calamares -d`
Summary - manual partitioning, cause format of sda9 (ext4) for '/" & no-format for sda8 or /home

lubuntu@lubuntu:~$ sudo -E calamares -d

this is session.log from requested command

Walter Lapchynski (wxl) on 2020-03-04
Changed in calamares (Ubuntu):
status: New → Triaged
importance: Undecided → High
MarkF (az2008) wrote :

I encountered this today on two machines.[1] In both cases I was trying to install 20.04 Lubuntu daily image using the "alongside" option. In both cases it failed with the error msg reported for this bug. But, when I restarted the installer, it showed the existing partition resized, and a new partition present. I chose "replace partition" and ended up getting what I was wanting to get from "alongside."

One machine is bios only. The other is "legacy." Both disks were MBR. The first one had two existing partitions which I wanted to install alongside. The other had one existing partition. (Both are 500g drives with at least 90% freespace in the existing partitions.).

[1] i5-4200M 2.5Ghz; 4th gen core processor 4600 gfx; Intel 7260 (Lenovo ThinkPad E440 20C5 laptop). It has a Hitachi 500gb Sata3 hdd, 7200rpm.
i5-560M 2.67Ghz; NVIDIA GeForce GT420M; Intel Centrino 6200 (Dell XPS L501X laptop).

Chris Guiver (guiverc) wrote :

Two installs today on box; following mostly copied/pasted from

** try 1 (NO ISSUES AT ALL)
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
testcase: BIOS, no encryption, internet, manual partitioning, seperate home (sda8), / in sda9

after selecting SDA9 for / and ensuring FORMAT checkbox is ticked, on OK, if I re-enter to confirm value it reports no-format. this is unexpected, and I wanted to 'format' to ensure nothing remains.., I won't force it this time (in past have switched it to reiserfs then back to ext4)

** try 2
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
testcase: BIOS, no encryption, internet, manual partitioning, seperate home (sda8), / in sda9

repeat BUT this time I will FORCE format of / partition, via change to reiserfs then back to ext4
sda8 re-used as /home, format sda9 as /

installation failed; command: sfdisk --force --apend /dev/sda

Could it be my play required to 'force' the FORMAT flag to be set is causing the issue? or at the very least this is possible clue as to where bug is?

I'll now just reboot 'live' system (kde partition manager won't make changes to disk after this error for some reason!??) then manually format sda9 as I want (ext4) and then select it (manual partitioning) and install; which historically works

Chris Guiver (guiverc) wrote :

dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt)
testcase: bios, no encryption, REPLACE PARTITION (sda4) & internet

this has not worked; no errors, it's just stopped... Checked `dmesg` for 'squashfs' and no issues (didn't see message but I ran 'check disk for defects' as I always do, but i can miss result as it doesn't wait for key..)

box let to sit there awhile
i eventually killed calamares, ran kde partition manager to ensure any 'swap' wasn't mounted (don't think there is a swap), then re-ran install with `sudo -E calamares -d`

it didn't get lost this time, failed to add partition..

Chris Guiver (guiverc) wrote :

Hours later & after full disk install, another install alongside to setup the same conditions as in comment #17 on

I re-ran

dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt)
testcase: bios, no encryption, REPLACE PARTITION (sda4) & internet

and it worked perfectly?? The only difference I'm aware of was I'm only approximate with disk sizing, ie. sometimes it's 3/5ths, other times 2/3rd or 5/8ths and larger usually for existing install... If this issue relates to the size of partitions, I've never recorded that.

Simon Quigley (tsimonq2) on 2020-04-16
Changed in calamares (Ubuntu):
assignee: nobody → Simon Quigley (tsimonq2)
status: Triaged → In Progress
Chris Guiver (guiverc) wrote :

As requested (tsimonq2), attempt to install using current daily focal daily (2020-04-16) on

dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
NOT A CHECKLIST INSTALL; replace sda9 as /, re-use sda8 as home

using ppa:lubuntu-dev/util-linux-patch; update & full-upgrade first
10 or 55 packages are from PPA

This was attempted twice; reboots in between.
First time sda9 was ext4 (prior focal install), second time sda9 was UNKNOWN due to first failure.

The second time the installer was run via `sudo -E calamares -d` (this log is attached)
Both time fails with failed to create partition sfdisk --force --append /dev/sda

Chris Guiver (guiverc) wrote :

Another requested try by tsimonq2, my daily ISO was still latest so same one used as in #19

dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
NOT A CHECKLIST INSTALL; replace sda9 as /, re-use sda8 as home

using ppa:lubuntu-dev/util-linux-patch; update & full-upgrade first

add-apt-repository ppa:lubuntu-dev/util-linux-patch
sudo apt update; sudo apt full-upgrade (12 or more were from ppa if 72)

opening calamares using desktop icon/link
selected sda8 for /home
selected sda9 for reiserfs (so it'll format), then re-edit & change back to ext4 (format remains)
overview looks good, next...
installer failed to create partition on disk .. sfdisk --force append /dev/sda

-- updates include
Get:5 focal/main amd64 libblkid1 amd64 2.34-0.1ubuntu10~ppa1 [198 kB]
Get:18 focal/main amd64 libuuid1 amd64 2.34-0.1ubuntu10~ppa1 [81.5 kB]
Get:19 focal/main amd64 libfdisk1 amd64 2.34-0.1ubuntu10~ppa1 [238 kB]
Get:23 focal/main amd64 libmount1 amd64 2.34-0.1ubuntu10~ppa1 [213 kB]
Get:24 focal/main amd64 libsmartcols1 amd64 2.34-0.1ubuntu10~ppa1 [162 kB]
Get:25 focal/main amd64 gsettings-desktop-schemas all 3.36.0-1ubuntu1 [29.0 kB]
Get:33 focal/main amd64 fdisk amd64 2.34-0.1ubuntu10~ppa1 [182 kB]
Get:34 focal/main amd64 util-linux amd64 2.34-0.1ubuntu10~ppa1 [1084 kB]
Get:35 focal/main amd64 mount amd64 2.34-0.1ubuntu10~ppa1 [179 kB]
Get:37 focal/main amd64 uuid-runtime amd64 2.34-0.1ubuntu10~ppa1 [98.3 kB]
Get:48 focal/main amd64 libkpmcore9 amd64 4.1.0-2build1~ppa1 [578 kB]
Get:63 focal/main amd64 calamares amd64 3.2.20-0ubuntu2~build1~ppa1 [2928 kB]
Get:72 focal/main amd64 rfkill amd64 2.34-0.1ubuntu10~ppa1 [86.1 kB]
(assuming I didn't miss any)

Chris Guiver (guiverc) wrote :

reboot and re-try on comment #20 (to get verbose report)

dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
NOT A CHECKLIST INSTALL; replace ?? which was sda9 as /, re-use sda8 as home
reboot so clean this time
using ppa:lubuntu-dev/util-linux-patch; update & full-upgrade first
(tsimonq2 requested re-test with updated packages..)
add-apt-repository ppa:lubuntu-dev/util-linux-patch
sudo apt update; sudo apt full-upgrade (12 or more were from ppa if 72; counted 13 this time)
this is a re-try after failures; sda9 was listed as unknown, deleted using kde partition manager
running `sudo -E calamares -d` form qterm
selected sda8 for /home
failed with

Note: if looking at session.log, I hadn't exited KDE partition manager & swap wasn't deactivated, thus the segfault, I closed KDE partition manager & re-started calamares.

Chris Guiver (guiverc) wrote :

This comment was ~suggested by Walter/wxl, it's intention is to go upstream.

All testing here is on existing system
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
using sda9 as /, and an sda8 as /home

sda8 is never formatted, just re-used. sda9 is formatted
logs created as done can be viewed at

Following include a reboot between each test

re-use sda8, format sda9 reiserf (comment #20 log)
re-use sda8, format sda9 ext4 (comment #21 verbose log)

re-use sda8, format sda9 ext4 using updated packages (log)

re-use sda8, format sda9 ext4 using updated packages-2 (log)
re-use sda8, format sda9 ext4 using updated packages-2 (verbose log)

re-use sda8, format sda9 reiserfs
re-use sda8, format sda9 xfs
re-use sda8, format sda9 btrfs

On the following failures, sda9 was deleted using KDE partition manager so sda9 didn't exist except as unallocated space before test

re-use sda8, format xfs
re-use sda8, format btrfs

refer to for real results though & more details.

To get it working, I reboot, use KDE Partition Manager to delete the 'unknown' partition that exists after all aforementioned FAILED tests, and create it in whichever format I want (ext4, btrfs were tested today & worked), deactivate swap & exit KDE Partition Manager. Calamares can then use the prepared sa9; and it'll install perfectly.

Chris Guiver (guiverc) wrote :

I wanted 20.04 on the dc7700 to investigate a support issue, so attempted install (install alongside) and got hit by this which I didn't expect on this box

hp dc7700 (c2d-6320, 5gb, nvidia quadro nvs 290)

Marcin Wojdyr (wojdyr) wrote :

I had the same problem. I got message:

Job: Create new partition on device '/dev/sda'
  Command: sfdisk --force --append /dev/sda
  Failed to add partition ...

Both Lubuntu installer and KDE Partition Manager failed to create partition.
I tried gparted - it worked fine.

So I used gparted first to create a partition and selected that partition in Lubuntu installer.
Unfortunately, the installer deleted and tried to re-create the partition, failing again.

So once more, I used gparted to create a partition and in the Lubuntu installer I used "Manual partitioning", avoiding partition changes. Finally it worked.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.