ntfsresize hang and call traces in syslog

[Dan Bungert]

Attempting to boot the impish final iso on my kvm VM setup with a windows 10 install on the virtual disk. The install process hangs at the "updates and other software" screen, apparently on a ntfsresize call. Mind you, this is before I have chosen disks to partition - I'm at the step where I can choose a Normal or Minimal installation.

While this is not a 100% reproduction rate issue, the rate seems high - above 50% I would guess. If I try to quickly click thru the installer on boot it might be a little more likely.

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: linux-image-5.13.0-19-generic 5.13.0-19.19
ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
Uname: Linux 5.13.0-19-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu70
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 4609 F.... pulseaudio
CasperMD5CheckResult: pass
CasperVersion: 1.465
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 13 02:40:56 2021
IwConfig:
 lo no wireless extensions.

 enp1s0 no wireless extensions.
LiveMediaBuild: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
 /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 5000M
 /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
     |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M
MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 qxldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash ---
RelatedPackageVersions:
 linux-restricted-modules-5.13.0-19-generic N/A
 linux-backports-modules-5.13.0-19-generic N/A
 linux-firmware 1.201
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/06/2015
dmi.bios.release: 0.0
dmi.bios.vendor: EFI Development Kit II / OVMF
dmi.bios.version: 0.0.0
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-q35-5.2
dmi.modalias: dmi:bvnEFIDevelopmentKitII/OVMF:bvr0.0.0:bd02/06/2015:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-5.2:sku:cvnQEMU:ct1:cvrpc-q35-5.2:
dmi.product.name: Standard PC (Q35 + ICH9, 2009)
dmi.product.version: pc-q35-5.2
dmi.sys.vendor: QEMU

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Ubuntu QA Website (ubuntuqa)]

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/1946828

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Etienne URBAH (eurbah)]

This bug is probably a duplicate of bug #1945011

[jeremyszu (os369510)]

Hi Dan,

In this case, does it able to be reproduced if you resize it using ntfresize in live session (impish)?

[Jean-Pierre (jean-pierre-andre)]

Please report what is hinting at ntfsresize and in what conditions it is started (such as the file system state) ?
Also please start ntfsresize from command line.

[Dan Bungert (dbungert)]

@Etienne - agree, probably a dupe

@Jeremy - I ran "ntfsresize -f -i /dev/sda4" manually before the installer ran and ntfsresize had no issue. Later during this same run, I saw the hang when ntfsresize was run by Ubiquity.

@Jean-Pierre - I suspect this is a kernel bug more than I suspect a ntfsresize one.

Here's a sample process tree:
   5991 S sh -c ubiquity gtk_ui
   5992 S /bin/sh /usr/lib/udisks2/udisks2-inhibit /usr/lib/ubiquit
   6002 Sl /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity gtk_ui
   6411 Ss+ /bin/busybox tail -f /var/log/installer/debug -f /var/log
   8639 S /usr/bin/perl -w /usr/bin/debconf-communicate -fnonintera
   9107 S /usr/share/ubiquity/activate-dmraid && /bin/partman
   9108 S /usr/share/ubiquity/activate-dmraid && /bin/partman
   9114 S /bin/sh /bin/partman
  10014 S /bin/sh /lib/partman/display.d/10initial_auto
  10060 S /bin/sh /lib/partman/display.d/10initial_auto
  10062 S /bin/sh /lib/partman/automatically_partition/10resize_use
  10131 D [ntfsresize]

ntfsresize has been invoked as "ntfsresize -f -i /dev/sda4", where this sda4 is a partition created by Windows 10, is NTFS, and is 508MiB. Also, if I kill parent process of ntfsresize (pid 10062 in this case), the install is able to continue.

[Jean-Pierre (jean-pierre-andre)]

When started with option -i, ntfsresize only evaluates the minimal size needed for the stored data. There may be a subsequent ntfsresize to actually do some resizing, which might not be run when you kill the parent process.

[Thomas Hebb (tchebb)]

This looks like the same issue as #1945011

[Beyil (rjbgolding)]

for issue #1966544 I can recreate it 100% of the time with secure boot on, unable to recreate at all with secure boot disabled. also unable to recreate at all with Jammy builds dated 29 mar 2022 and 19 apr 2022...

[Dan Bungert (dbungert)]

I retested this today using my same failing VM.

Test scenario:
* hardware: kvm with windows 10 on disk, UEFI
* boot Ubiquity ISO
* "try ubuntu"
* launch installer
* press the "continue" button until one of the following happens:
  * "installation type" screen shows
  or
  * hang at the "updates and other software screen" -
    wait 1 minute and look for ntfsresize in process state 'D'

Results:
* Impish: 3/10 success rate ("installation type" screen reached)
* Jammy: 10/10 success rate

Based on this I consider this fixed in Jammy.