Univention Bugzilla – Bug 31634
Revise ucc-image; among others: handles target-dir incorrectly internally, breaking image generation
Last modified: 2014-06-12 09:19:39 CEST
ucc-image knows the parameter -t to set the directory in which the final image and additional files (spec, md5, initrd, ...) should be placed. But the internal handling of the target dir variable is inconsistent, i.e. [...] image = os.path.join(targetdir, config.get('Image', 'name', 'ucc-image.img')) [...] md5_dest = os.path.join(targetdir, "%s.md5" % image) (there are probably more occurences like this) If a target dir different to '.' is specified this leads to the image beeing placed in $targetdir/image.img and the md5sum file in $targetdir/$targetdir/image.md5 This breaks the image generation as the sub-$targetdir directory is not created, and the file spreading that occurs if the directory is present shows up in the spec file. Workaround: create the preferred target directy, 'cd' into it and call ucc-image with '-t .'
ucc-image-toolkit has been revised: * Handle target dir correctly * Increase logfile readability by logging executed commands * Change default base release to trusty * Always install base ucc packages (and remove ucc option from cfg file) * Create all files in the workingdir and move them at the end * Write compression progress to stdout We have to remove the ucc cfg option from the documentation ucc-image-toolkit 2.0.0-7 changelog entries added
(In reply to Erik Damrose from comment #1) > We have to remove the ucc cfg option from the documentation Removed in revision 49099
OK - ucc-image-toolkit OK - YAML
There are still some issues with image generation: A loop device is still open after desktop image generation. This is caused by services that are (re-)started in the chroot environment
(In reply to Erik Damrose from comment #4) > There are still some issues with image generation: > A loop device is still open after desktop image generation. This is caused > by services that are (re-)started in the chroot environment Specific example: root@imgbuild:~# fuser -m /dev/loop1 /dev/loop1: 18154rce 20837rce 21985rce 27391rce 27392rce 27393rce root@imgbuild:~# ps aux | grep 18154 root 4519 0.0 0.0 3352 744 pts/0 D+ 13:19 0:00 grep 18154 root 18154 0.0 0.0 8320 3148 ? Ss 12:14 0:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf root@imgbuild:~# ps aux | grep 20837 root 4521 0.0 0.0 3368 776 pts/0 S+ 13:19 0:00 grep 20837 ntp 20837 0.0 0.0 6388 696 ? Ss 12:15 0:00 /usr/sbin/kerneloops root@imgbuild:~# ps aux | grep 21985 root 4550 0.0 0.0 3368 780 pts/0 S+ 13:20 0:00 grep 21985 root 21985 0.0 0.0 2196 608 ? Ss 12:15 0:00 /usr/sbin/acpid root@imgbuild:~# ps aux | grep 27391 root 4552 0.0 0.0 3368 776 pts/0 S+ 13:20 0:00 grep 27391 statd 27391 0.0 0.0 2456 712 ? S 12:35 0:01 avahi-autoipd: [eth0] sleeping root@imgbuild:~# ps aux | grep 27392r root 4554 0.0 0.0 3368 776 pts/0 S+ 13:20 0:00 grep 27392r root@imgbuild:~# ps aux | grep 27392 root 4556 0.0 0.0 3368 776 pts/0 S+ 13:20 0:00 grep 27392 root 27392 0.0 0.0 2220 296 ? S 12:35 0:00 avahi-autoipd: [eth0] callout dispatcher root@imgbuild:~# ps aux | grep 27393 root 4558 0.0 0.0 3368 780 pts/0 S+ 13:20 0:00 grep 27393 root 27393 0.0 0.0 5512 2224 ? Ss 12:35 0:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
After a "fuser -k -m /dev/loop1", the stray loopback mount went away.
(In reply to Moritz Muehlenhoff from comment #6) > After a "fuser -k -m /dev/loop1", the stray loopback mount went away. The image builder now issues this command before unmounting the image. In my tests, this works fine, no loopback devices are left after an image build. ucc-image-toolkit 2.0.0-19.163.20140424113 no changelog update necessary
I'll test for the stray loopback devices
(In reply to Erik Damrose from comment #7) > (In reply to Moritz Muehlenhoff from comment #6) > > After a "fuser -k -m /dev/loop1", the stray loopback mount went away. > > The image builder now issues this command before unmounting the image. In my > tests, this works fine, no loopback devices are left after an image build. > > ucc-image-toolkit 2.0.0-19.163.20140424113 > no changelog update necessary The dangling files are properly removed and the loopback devices released
UCC 2.0 has been released: http://docs.univention.de/release-notes-ucc-2.0.html If this error occurs again, please use "Clone This Bug".