Install selected time zone city (Seattle) hit next hit back hit next then crash

[Dadovan]

This occurs during install of 18.10 64-bit desktop on VirtualBox 5.2.20.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: ubiquity 18.10.12
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
Uname: Linux 4.18.0-10-generic x86_64
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
CasperVersion: 1.399
CurrentDesktop: ubuntu:GNOME
Date: Sun Oct 21 14:59:32 2018
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd quiet splash --- maybe-ubiquity
LiveMediaBuild: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 LC_NUMERIC=C.UTF-8
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Jean-Baptiste Lallement (jibel)]

Thanks for your report.

Confirmed on Cosmic (release) by going back and forth between the Timezone and the User setup pages.

[Jean-Baptiste Lallement (jibel)]

debug.log in debug mode.

[Iain Lane (laney)]

We probably broke this with the changes for bug #1797579 :(

[Iain Lane (laney)]

Exception caught in process_line:
Traceback (most recent call last):
  File "/usr/lib/ubiquity/ubiquity/filteredcommand.py", line 145, in process_line
    return self.dbfilter.process_line()
  File "/usr/lib/ubiquity/ubiquity/debconffilter.py", line 343, in process_line
    progress_title)
  File "/usr/lib/ubiquity/ubiquity/filteredcommand.py", line 440, in progress_start
    progress_min, progress_max, self.description(progress_title))
  File "/usr/lib/ubiquity/ubiquity/filteredcommand.py", line 324, in description
    return misc.utf8(self.db.metaget(question, 'description'),
  File "/usr/lib/python3/dist-packages/debconf.py", line 83, in <lambda>
    lambda *args, **kw: self.command(command, *args, **kw))
  File "/usr/lib/python3/dist-packages/debconf.py", line 87, in command
    self.write.write("%s %s\n" % (command, ' '.join(map(str, params))))
ValueError: I/O operation on closed file.

[Iain Lane (laney)]

I can see two ways to fix this, both of which have some small downsides:

  https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/357618

Fixes this bug because you can't run the timezone step a second time. Obvious downside is that if you make a mistake at that step you can't correct it.

  https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/357619

Fixes this bug because we only start the actual installation once. Downside is that this would suffer from bug #1797579 for the non-first choice.

If another installer developer could weigh in that would be helpful.

[Iain Lane (laney)]

I asked xnox whether he could help look at this.

23/10 09:50:30 <xnox> i believe there is a distinct code-path, that if paritioning fails for some reason, it shows a pop-up with what went wrong.
23/10 09:50:52 <xnox> and i don't remember if it throws the user back to partitioning, or if tells the user to "click back" to partitioning.
23/10 09:50:54 <xnox> =/
23/10 09:51:07 <xnox> also not sure how to simulate that.
23/10 09:53:50 <Laney> there's a codepath for that
23/10 09:55:36 <Laney> return_to_partitioning?
23/10 09:57:59 <Laney> try making partman-commit always return false or something
23/10 10:01:53 <Laney> it's possible that we should set self.partitioned = False, self.timezone_set = False unconditionally after ubi-partman
23/10 10:02:19 <Laney> if you'd like to check that out and add an extra commit if so, that would be welcomed by me

hopefully something will be forthcoming!

[Mathieu Trudel-Lapierre (cyphermox)]

Both these options seem pretty bad to me.

IMO the least worse is to block going back, but that's still really poor UX.

I think we should get to know more about why this fails, because it seems to me like these steps should mostly just be shuffling debconf, recording all that is a database than we can then push on the system, and reconfigure the relevant packages at the end of the installation.

OTOH, the issue is fairly clearly a regression from the fix for bug #1797579, which isn't a much better solution than the two here. I'm sure there's another way to go about fixing it if we knew better why it's broken now, and used to work fine...

[Iain Lane (laney)]

Previously we started installation (restarted debconf and so on) after committing the partition changes to disk. We changed that to be after both the timezone step and partitions were committed, because installation needs to have debconf answers from the timezone stuff.

This bug happens because we do that multiple times if you go between the step after timezone (user setup) back to timezone itself, and then forward again. We didn't do anything to prevent installation happening multiple times. You can't go back to partition committing once you've been past it (unless it fails), so this bug couldn't happen with the previous logic.

Another thing could be to move timezone before partitioning, which would solve the initial bug and not be prone to this regression - in that case you would lose the parallelisation of doing partitioning while selecting the timezone. That's why we didn't do it first off. I'm not sure what "which isn't a much better solution than the two here" is meant to mean in that sense I'm afraid. Sounds like you're criticising what we did to fix that bug?

Anyway, if you have smarter ideas, let's hear them. Hopefully you can understand what the problem is now.

[Iain Lane (laney)]

No response for a long time so I went ahead and uploaded the 'no going back' fix a couple of weeks ago.

ubiquity 19.04.6.