Stuck at "Saving installed packages..." when using a custom /var

Can you please reproduce this with the installer in debug mode, then reattach the logs (`sudo apport-collect 875343`)? To get ubiquity in debug mode, press the "Try Ubuntu" button, then open a terminal and type `ubiquity -d`

Thanks!

apport information

apport information

apport information

apport information

apport information

I'm experiencing the same issue attempting an 11.10 install via the Live CD image over a PXE/NFS boot. It affects x86 and amd64 installs.

The system's hard disk is configured with 4 primary partitions:

/dev/sda1 Vaio Recovery environment
/dev/sda2 Microsoft Windows Vista
/dev/sda3 /boot
/dev/sda4 LVM

/dev/sda4 is the PV, it contains one VG "Ubuntu". The VG contains several LVs. Some LVs are encrypted. I unlocked them via a terminal prior to starting Ubiquity using:

"sudo cryptsetup --key-file /media/USB/somefile.key luksOpen /dev/Ubuntu/Oneiric_var_encrypted Oneiric_var"

For the install I chose "Something Else" for the partitioning scheme and selected recently created and ext4-formatted LVs for:

/dev/Ubuntu/Oneiric == "/"
/dev/Ubuntu/Oneiric_var_encrypted -> /dev/mapper/Oneiric_var == "/var"

and existing LVs (from the Lucid installation) for /home, /usr/local/.

The installer reports "Saving installed packages..." but there is no further installation activity although the taster panels continue to be active. The "Skip" button does not respond and the cursor has the 'busy' icon.

From trawling "/var/log/installer/debug" I think this is the pertinent problem:

Nov 10 00:47:25 debconf (filter): <-- PROGRESS INFO ubiquity/install/apt_clone_save
Nov 10 00:47:25 debconf (filter): widget found for ubiquity/install/title
debconf (developer): <-- METAGET ubiquity/install/apt_clone_save description
debconf (developer): --> 1 Saving installed packages...
Nov 10 00:47:25 debconf (filter): --> 0 OK
Nov 10 00:47:25 ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/bin/partman-commit'] exited with code 32

Looking further into the /lib/partmain/* scripts I found that "ubiquity/install/apt_clone_save" comes from /lib/partman/finish.d/01apt_clone_save and the exit code "32" is returned from mount when doing:

[ -n "$var" ] && mount "$var" "$mountpoint/var"

which fails since the /var directory has not been created in the root file-system as a mount-point:

sudo mount /dev/mapper/Oneiric_var /tmp/tmp.WVwIJqLzQe/var
mount: mount point /tmp/tmp.WVwIJqLzQe/var does not exist
echo $?
32

This line should be:

[ -n "$var" ] && mkdir -p "$mountpoint/var" && mount "$var" "$mountpoint/var"

This is not a permanent solution but just a workaround for anyone wishing to upgrade without formatting target partition.

I was trying to set up 12.04 Beta 1 without formatting my /-mounted partition and got stuck at this.
My 11.10 setup was going to be a pain to upgrade anyway - had troublesome upgrade earlier when using .

I booted with an alternate cd and removed everything I did not need (/var /lib /opt e.t.c) except /home.
For good measure, I also renamed /home and then installed 12.04 beta 1 without formatting target partition - went smoothly.

Hope this is useful.

How long is forever? It appears to freeze for me on 12.04 beta 1 (x86, atom based netbook), and will not respond to clicks on the skip button, but unfreezes after an hour or so. Top reports it spends a lot of time switching between 100% CPU for dpkg-deb and dpkg-repack.

How log? It just took overnight .. so I gave up and will try something else.

Hit the same problem on 12.04, both Ubuntu and Kubuntu.

My /var is not custom, my old install uses two partitions - "/" and swap. The new install adds an extra partition for /home. Didn't want to format "/" to save time after the install. Out of luck I guess.

Seriously, this is still a problem.
I just tried it now and I have to format my partitions. This really sucks.

I can still confirm the bug. I gave a very detailed description and reproducable steps. It is a shame that there is not even a comment on this.

This bug still exists as of 13.04. I'm simply installing to / on a hard drive that hard a partial 13.04 install and many applications so I don't want to format.

Never mind it just suddenly jumped to 91% while is was looking through the logs

For the record, I had this same problem installing 13.04 over a previous installation. After letting it run for 10 minutes I decided to go online to read about it. After reaching the end of this post, it suddenly began working. It took at least 20 minutes.

I guess time does heal all wounds?

This problem still affects the 12.04 LTS distribution - with entirely blank filesystems (formatted with custom options) the installer did not progress past "Saving installed packages" when left over the weekend.

Dropping to the shell and creating a 'var' directory on the intended root filesystem by hand and restarting the process allowed the installer to progress past this stage.

It still happens in Saucy, I have one HDD and a SSD, I tried it:

HDD:
/dev/sda1
/dev/sda2 - linux-swap
/dev/sda3 - /var
/dev/sda4 -
/dev/sda5 -
/dev/sda7 - /home

SSD:
/dev/sdb1 - EFI
/dev/sdb2 - /boot
/dev/sdb3 - /

And the install hangs... then, I did use /var in a separate partition, and ubuntu did the install, normally.

Is this problem still happen in Trusty?

This is a serious problem, if one person has 2 hard disk, and one of them is SSD, it's a good idea to use /var in HDD, to try increase the lifetime of the SSD.

I can reproduce this in xubuntu daily 2013/12/16.

If Canonical wants to improve SSD support (like i saw with Trim stuffs), I think it is a good idea to see that problem.

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

The problem in Trusty, take a look at the picture.

Critical seems higher than necessary, given that some changes to a default install are necessary to encounter this bug.

I had this problem when installing 14.04 desktop amd64.

I had configured LVM as per
http://ubuntuforums.org/showthread.php?t=1782296
and had not marked any partitions apart from /boot for formatting (because I'd already formatted them with mkfs.ext4)

It did warn me that it would overwrite any system directories like /etc, /lib etc - which is no problem. But it hung at the "Saving installed packages..." step.

I rebooted and told the installer to format all partitions, and then it was OK.

I've just been able to reconfirm the problem with both the server and desktop installs. Interestingly on the server install I get an actual failure, but on the desktop install it hangs as per the bug description.

My setup was / on /dev/sdb1 (part of a pre-created btrfs raid1 array) and /var on /dev/sdb3 (part of a second array). I indicated that /dev/sda1 and /dev/sda3 were / and /var, respectively. I asked the partitioner not to format the drives.

Mounting / and creating /var, worked fine for me as a workaround.

So, from what I can deduce from this thread is that there is an issue with the installer... The developers at Ubuntu are fully aware of it... Yet they chose to do nothing to rectify it. Are they competing with Microsoft to drop the ball now?

Just to note, still occurring in utopic. I left the installer overnight with no progress. I have existing RAID partitions and two LVM containers, home and var.

After killing the first installer, I tried mounting the root partition and simply created a /var directory in it, unmounted it and restarted the install, which worked fine after that.

I experienced this problem today on a re-installation of Mint 17.2, over existing, separated \var and other partitions, without checking the "format partition" check-boxes. It is a re-installation of Mint on SDB (hard drive 1) after a clean installation of Windows 10 on SDA (hard drive 0).

I tried "ubiquity -d" but "Ubitquity is already running!"
sudo apport-collect 875343 -- apport-collect was not found.

- Installer hangs forever
+ Stuck at "Saving installed packages..." when using a custom /var

Also seeing 100% CPU for tens of seconds (E.g. I just saw it run for over 2 minutes) in dpkg-deb, followed by a few seconds in dpkg-recheck.

I have none of the separate partitions people talk about. One single root partition. Couldn't be simpler.

This only seemed to happen after reinstalling over a previous failed installation, when the installer crashed on me. First install ran fast but crashed at the end. Second attempt is slow to the point that it isn't clear if any progress is being made.

Unlike other people, my installation did eventually complete. It just took several hours (around 5 hours, I think) to get past the "Saving installed packages" stage. Kubuntu 14.04.3.

15.10 here, same bug, trying to install preserving /home.

Still the same trying to install
 Ubuntu 16.04 LTS "Xenial Xerus"
 over
Ubuntu 14.04 LTS 'Trusty"

as the upgrade failed ( would only do partial )

Allowing it to format the /Var partition it started installing system , minor losses

/boot
/
/Home
/Var
/Tmp

partitions used

Five years later, perhaps Canonical should look into this?

...and, I guess I'm joining the list of despondent users hoping that this issue had been resolved in the five years since the original post only to scroll down to disappointment.

It's just incredible isn't it.

Something that someone could probably solve in 30 minutes, and it cost me another hour.

Multiply that with all the people being affected by this, and you will realize how inefficient this system is.

I'm using the Live CD install. Has anyone run the installer in debug mode? I'm attaching files from /var/log/syslog
/var/log/partman
/var/log/installer

Tom

By the way, I tried to log in using Links, but it kept telling me I was a bot. I guess it can't do the verification (no Javascript?).

I was stuck here, too. I delete all these old directories like '/usr /lib /var...' except '/home' on the target partition, then it works.

Hi Guys,

I would just like to say that although its annoying that a bug has been going for so long and i have just come across it, but thanks to people posting workarounds im finally updating my 12.04 laptop to 16.04.

Wow, still happens in 17.04

I apologize if this is off topic, my intent is to help, and offer something that may be a work around.

During an upgrade from 18.1 Mate to 18.2 Mate, I got caught in “Saving installed packages” too.

Pixy Yuan (pixy-bupt) #41 is right, delete everything but /home by way of sudo’ed file browser. I also delete most .xxx files - if you keep .remmina and the like - you don’t have to re-invent the wheel, but get rid of the standard system hidden files in /home/username/

Install shifted into copying files directly. No wait. Full Mate install in under 10 minutes on a Dell Lattitude D610 - Pentium M single core 1.1 gig CPU

I thank my friend Jason for showing me this, many years ago, and wanted to share. NOTE - I did not have /var in a custom spot, thus the apology in the first line.

Brad

after 7 years... problem still exists in 18.10...

what is problem for fixing this? already is found problem:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/875343/comments/8

only is need add: mkdir -p "$mountpoint/var"

Installing from scratch Ubuntu 18.10, with a customised full disk encryption partitioning scheme.
After setting up separate encrypted volumes with new filesystems for these mountpoints:
   / /boot /home swap
I started
   ubiquity
and forgot -b so it completed fast but crashed at end (it is a known bug: on a FDE setup -b is needed, grub must be installed after configuring GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub).
So, I restarted with the switch
   ubiquity -b
and met this "bug". Which isn't, at least in one, my, case. It's a "feature": finding an existing installation, ubiquity uses dpkg-repack to save the customisations and transport them to the new installation; this takes very long time, enough to find and read the preceding 45 posts...
In case of a new installation, kill ubiquity and restart recreating empty filesystems is quicker than waiting the repacking of the whole release.

OTOH, there seems to be also real bug described here: when /var is a mountpoint.

Rethinking, there are 2 bugs. One is in front of the keyboard. Those who want to keep the existing customised configuration should not reinstall, but should should perform a
   do-release-upgrade
Catering for those who reinstall but want to keep previous settings is a bug, I say.