Exploration of lp 1864787 - "sfdisk --force --append /dev/sda"

[guiverc]

Bug report - https://bugs.launchpad.net/calamares/+bug/1864787 or calamares error " “sfdisk --force --append /dev/sda”" (recorded as impacting four total users, that could get around issue too)

@wxl recently asked for exploration of this issue.
@leok and I have talked about it, and likely best approach forward is (following is cut/pasted from elsewhere, slight editing)

@guiverc

For now I think the best approach is (on box it occurred on)

• I try QA-test install hirsute to partition
• I re-try a focal (I’ll use current daily of 20.04.2) install on it (system is currently focal)

It’s not a test box (except for live tests, as it has installed systems, so I won’t hurry with the install (I want to restore systems to my working state which takes time)

If I get it to re-occur on that box, THEN I can try (again) to re-create that setup on the other d755, and see if I can get it to occur there too (what I mentioned attempting long ago, but didn’t achieve)… As I’ve experienced it, it’d be easier for me to try and re-create on a different box I believe than …

Purpose of this, is to let @wxl see what is intended, it also allows others to provide insight, make comment (flaws/improvements in approaches etc) and have an easy place for documenting what is done.

As users were able to work around the issue (myself included) I don’t consider it a priority task, though with feature freeze on 25 February on hirsute…

[wxl]

@guiverc great idea making this whole conversation public as it will mean others might be able to jump in and offer advise.

At some point, I need to implement our whole email system on Discourse so new topics can be emailed here. That way you can easily echo any message to the mailing list at the same time since there are people there that don’t pay attention to Discourse (and vice versa) but that’s not really relevant to this particular topic.

So I’m not sure you saw the further conversation on IRC but tl;dr Calamares’ philosophy about manual partitioning is that you proceed at your own risk. It won’t prevent you from doing something impossible (meaning here, outside the capabilities of a filesystem or partition table scheme). I think Occam’s Razor would suggest this to be the parsimonious explanation, especially in light of the complex partition scheme and the fact that manually partitioning outside of the installer didn’t seem to be any more successful.

One thing that might be helpful to help us visualize and work through this is screenshots from Calamares of what the initial scheme is like as well as what you’re trying to change it to. Perhaps that might provide some insight.

BTW I agree this is not high priority at all.

[guiverc]

Not of calamares; just booted a recent Lubuntu 20.04.2 (2021-01-07 daily) ISO and what I see in KDE Partition Manager. I just re-use sda8 (/) and sda9 (/home) though both are within an extended partition (sda2).

For anyone else looking, it’ll show something this box has that few these days experience… tools picking up the fd0 or 3.5" floppy device when a floppy is inserted.

[guiverc]

@guiverc

• I try QA-test install hirsute to partition
• I re-try a focal (I’ll use current daily of 20.04.2) install on it (system is currently focal)

• hirsute installed on d755-5 twice without issue (http://iso.qa.ubuntu.com/qatracker/milestones/419/builds/225461/testcases/1701/results/)

• focal installed on d755-5 once successfully without this issue (http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/225460/testcases/1701/results/)

I planned to install focal twice, so may do it again tomorrow, then evaluate & confirm what I did matches the bug report; the only difference I noted was sda8 & sda9 had swapped, but that’s happened before when a partition is formatted. I’m too tired now, but assuming I made no mistakes, I’ve got nowhere in re-creating it today (or thus far).

[guiverc]

I decided to wait for another daily, rather than repeat with the exact same ISO the next day (where zsync showed no update)

• just completing my second focal install on d755-5, again without issue (Install using Calamares (entire disk) in Lubuntu Desktop amd64 in Focal Daily | Ubuntu QA)

I’ll complete the testing (so far only bionic has been confirmed perfect; & it’s a multiple OS system, but I expect all perfect, then I’ll write summary of this on bug report (last two posts here)

Anyway, this minimal testing doesn’t show it impacting hirsute or focal, and we can’t do much about groovy anyway.

I’ll use this d755-5 box now and again for the same type of installation (separate /home is a testcase of ours), so if it pops up again… I can return here.

NOTE: There are 9 references to BTRFS (4 of XFS) in the bug report (some will be repeats), maybe I need to re-try using BTRFS (and/or XFS) next time…

[guiverc]

Doing some QA-testing for focal.2

• install on same d755-5 as per prior tests, using BTFS and no issue

• install on same d755-5 as per prior tests, using XFS and problem 1864787

I don’t think XFS is the cause; I think it’s just a rare occasional issue myself… (though it could be unusual options like XFS/BTRFS/… increase chance of occurrence. If I knew a pattern long ago, I don’t know it anymore)

Install using Calamares (entire disk) in Lubuntu Desktop amd64 in Focal Daily | Ubuntu QA

---

reboot, restart live system & try and repeat the last install, problem 1864787 again)

---

reboot, used KDE partition manager to delete sda9, re-create it (XFS) then repeat install with same parameters (format sda9 as XFS, re-use sda8 as /home) & no issue.