[Bug 1964769] Re: ubiquity crashed when installing in an external usb drive
Paul White
1964769 at bugs.launchpad.net
Tue Mar 25 16:04:36 UTC 2025
Thank you for taking the time to report this bug and helping to make
Ubuntu better. We are sorry that we do not always have the capacity to
review all reported bugs in a timely manner.
Ubiquity is now unmaintained as it has been replaced by either the
Ubuntu Desktop Installer or Calamares starting with Ubuntu 24.04 LTS.
Therefore, this bug is being closed as 'Invalid'.
If you believe this was done in error, please feel free to re-open the
bug report.
If you have any general questions about Ubuntu, please open a topic on
the Ubuntu Discourse instance: https://discourse.ubuntu.com/.
** Changed in: ubiquity (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1964769
Title:
ubiquity crashed when installing in an external usb drive
Status in ubiquity package in Ubuntu:
Invalid
Bug description:
The installation happened on a Lenovo T530 (with the internal drive taken out toprevent any damage to it).
It also involved a 4TB Toshiba portable storage Model DTX140 4TB +5V DC 1.0A, P/N: HDTX140ESCCA FAC:L A
I tried to install on the external drive. In order to prevent any
change to my built-in drive, I removed it before booting from the
Xubuntu 20.04.4 amd64-live stick, which was recognized as /dev/sda.
Before the installation, I already had created a partition table for
Xubuntu 20.04 (usual installation with a Linux-Sys partition, a small
swap partition and a home partition), but I left 4MiB free space
before the first partition (just to be sure) instead of the 1Mib which
would normally be used.
I was unsure, if a Boot partition is really necessary, but for sure I
also provided one with the recommended size of ca 150MiB.
Lots of free space were left on the external drive (not et assigned to
any partition, but to be used later when the disk is actually used).
xubuntu at xubuntu:~$ lsblk -oname,size,fstype,partflags,label
NAME SIZE FSTYPE PARTFLAGS LABEL
loop0 1,6G squashfs
sda 15G iso9660 Xubuntu 20.04.4 LTS amd64
├─sda1 1,8G iso9660 0x80 Xubuntu 20.04.4 LTS amd64
├─sda2 3,9M vfat
└─sda3 13,2G ext4 writable
sdb 3,7T
├─sdb1 149,7M ext4
├─sdb2 4G swap
├─sdb3 18,6G ext4
└─sdb4 18,6G ext4
sdc 7,5G
└─sdc1 7,5G vfat 8GB_SANDISK
sr0 1024M
xubuntu at xubuntu:~$ sudo mount /dev/sdb1 /mnt
xubuntu at xubuntu:~$ ls -l /mnt
insgesamt 115532
-rw-r--r-- 1 root root 257734 Feb 7 15:01 config-5.13.0-30-generic
drwxr-xr-x 4 root root 4096 Mär 14 10:31 grub
lrwxrwxrwx 1 root root 28 Mär 14 10:30 initrd.img -> initrd.img-5.13.0-30-generic
-rw-r--r-- 1 root root 101323223 Mär 14 10:30 initrd.img-5.13.0-30-generic
lrwxrwxrwx 1 root root 28 Mär 14 10:24 initrd.img.old -> initrd.img-5.13.0-30-generic
drwx------ 2 root root 16384 Mär 14 10:23 lost+found
-rw-r--r-- 1 root root 182704 Aug 18 2020 memtest86+.bin
-rw-r--r-- 1 root root 184380 Aug 18 2020 memtest86+.elf
-rw-r--r-- 1 root root 184884 Aug 18 2020 memtest86+_multiboot.bin
-rw------- 1 root root 5960334 Feb 7 15:01 System.map-5.13.0-30-generic
lrwxrwxrwx 1 root root 25 Mär 14 10:30 vmlinuz -> vmlinuz-5.13.0-30-generic
-rw-r--r-- 1 root root 10171040 Feb 23 09:58 vmlinuz-5.13.0-30-generic
xubuntu at xubuntu:~$ sudo umount /dev/sdb1
xubuntu at xubuntu:~$ sudo mount /dev/sdb3 /mnt
xubuntu at xubuntu:~$ ls -l /mnt
insgesamt 92
lrwxrwxrwx 1 root root 7 Mär 14 10:24 bin -> usr/bin
drwxr-xr-x 2 root root 4096 Mär 14 10:23 boot
drwxr-xr-x 2 root root 4096 Mär 14 10:26 cdrom
drwxr-xr-x 4 root root 4096 Feb 23 09:47 dev
drwxr-xr-x 137 root root 12288 Mär 14 10:33 etc
drwxr-xr-x 2 root root 4096 Mär 14 10:23 home
lrwxrwxrwx 1 root root 7 Mär 14 10:24 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Mär 14 10:24 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Mär 14 10:24 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Mär 14 10:24 libx32 -> usr/libx32
drwx------ 2 root root 16384 Mär 14 10:23 lost+found
drwxr-xr-x 2 root root 4096 Feb 23 09:47 media
drwxr-xr-x 2 root root 4096 Feb 23 09:47 mnt
drwxr-xr-x 2 root root 4096 Feb 23 09:47 opt
drwxr-xr-x 2 root root 4096 Apr 15 2020 proc
drwx------ 3 root root 4096 Mär 14 10:30 root
drwxr-xr-x 13 root root 4096 Mär 14 10:27 run
lrwxrwxrwx 1 root root 8 Mär 14 10:24 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 Feb 18 22:31 snap
drwxr-xr-x 2 root root 4096 Feb 23 09:47 srv
drwxr-xr-x 2 root root 4096 Apr 15 2020 sys
drwxrwxrwt 2 root root 4096 Mär 14 10:31 tmp
drwxr-xr-x 14 root root 4096 Feb 23 09:48 usr
drwxr-xr-x 14 root root 4096 Feb 23 09:52 var
xubuntu at xubuntu:~$ sudo umount /dev/sdb3
xubuntu at xubuntu:~$ sudo mount /dev/sdb4 /mnt
xubuntu at xubuntu:~$ ls -l /mnt
insgesamt 20
drwx------ 2 root root 16384 Mär 14 10:23 lost+found
drwxr-xr-x 3 1000 1000 4096 Mär 14 10:27 verwalter
xubuntu at xubuntu:~$
It looks like a system has been installed, but to this point I had
noch chance to test, if the computer really boots from it.
If needed, I can provide you with screenshots showing all settings
during the install (it would be nice, if ubiquity automatically could
report all settings made during an install in order to unambiguously
document how an installation was made! I would like to provide you
some more proposals how ubiquity should be improved, some of them will
be easily implemented but have much impact on usability).
Please send me an email if you want more information. Unfortunately I
don't see, if there is any additional information which I might
extract from logfiles and which might be useful to fix this bug. But I
know, that my live stick has a partition "writable" and possibly
(hopefully) other information can be extracted from there, if you
advise me what to extract.
By the way: this partition "writable" should be made useful to add
files, especially *.sh files, in this prtition to be used after
installation or even: during the boot process in order to improve some
really bad default settings of the freshly installed system, e.g. a
colour assigned to "selected text" in a terminal which is in dark
blue, almost unreadable, or letting me change the default format for
date in Thunar, in terminal sessions, letting the default columns in
Thunar be arranged differently (change date first, size second, name,
access rights, user, group: one often has to sort things by one of the
first columns in my preferred setting. With the normal order, these
are somewhere far to the right, so one can not quickly click on the
header of the thre columns mentioned first).
Kind regards
Adalbert Hanßen
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubiquity 20.04.15.19
ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
Uname: Linux 5.13.0-30-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.445.1
Date: Mon Mar 14 11:08:11 2022
InstallCmdLine: file=/cdrom/preseed/xubuntu.seed initrd=/casper/initrd quiet splash --- maybe-ubiquity
LiveMediaBuild: Xubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1964769/+subscriptions
More information about the foundations-bugs
mailing list