package update

Issue #779 closed
Frank Löffler created an issue

Please run an package update and update the machine (apt-get update;apt-get upgrade). This probably needs to be done regularly - ideally every time some package needs an update, in practice once a day should be sufficient.

Keyword:

Comments (8)

  1. Roland Haas
    • removed comment

    The command (from the secure-delete package)

    sfill -l -l -z -v / # two -l might be useful to fill empty blocks on the hard disk with zeroes to improve compressability. Using this lets me compress a (used, with some extra packages like atlas-base-dev, scite, VisIt [which is 400MB], maybe others) virtual machine disk down to 1.2GB which is not that much larger than the original size of 1.1GB. My raw hard disk image is 8GB so I guess I must have increased it at one point to make room for eg. VisIt.

    It might also help (while we are all testing this), to just put the uncompressed file at a file system location at LSU so that those who have LSU accounts (all of us I think) can use rsync to do an efficient update of our "local copy".

  2. Frank Löffler reporter
    • removed comment

    We should try to keep the uncompressed size below DVD size to be able to burn it uncompressed and not rely on some host-uncompression...

  3. Roland Haas
    • removed comment

    That will be hard to do I think. Currently I seem to be using 3.9GB of '/' (with only atlas-dev, network-manager, scite installed). My (compiled) Cactus tree is 1.7GB and visit (the next largest directory) is 400GB. That leaves 1.8GB for the system. Large but apparently what it takes these days to install an operating system. Given how horrendously slow compilation (Core2 Duo Laptop without virtualization extensions in CPU) was it is probably a good idea to ship with Cactus precompiled (and strongly advise against -realclean).

    If we compress with just zip (not lzma) we should be able to have everyone being able to decompress it, shouldn't we? Do we also put VirtualBox itself on the disk (if so: for which OS)?

  4. Frank Löffler reporter
    • removed comment

    We thought about compressing the Cactus tree inside the VM, which should save a bit. zip might be plan B, I agree.

  5. anonymous
    • removed comment

    Replying to [comment:1 rhaas]:

    The command (from the secure-delete package) ` sfill -l -l -z -v / # two -l ` might be useful to fill empty blocks on the hard disk with zeroes to improve compressability. Using this lets me compress a (used, with some extra packages like atlas-base-dev, scite, VisIt [which is 400MB], maybe others) virtual machine disk down to 1.2GB which is not that much larger than the original size of 1.1GB. My raw hard disk image is 8GB so I guess I must have increased it at one point to make room for eg. VisIt.

    That's a neat command... I'll be sure to use it next time I compress the disk image. I also created an internal swap partition of about 768MB which I could overwrite internally with 0s then re-create swapfs before compression.

    8GB is the fixed upper size limit of the VM disk. I had configured the disk image for dynamically-expanding storage albeit with an 8GB limit. Is that the internal size according to the guest OS (df -h)? If not then you might have the 'Fixed-sized storage' option selected for the disk, in which case it will always occupy 8GB on the host OS.

    It might also help (while we are all testing this), to just put the uncompressed file at a file system location at LSU so that those who have LSU accounts (all of us I think) can use rsync to do an efficient update of our "local copy".

    I had thought about doing this. It likely would be more efficient now that most of the packages are installed. I'll rsync to one of our servers when I finalize my updates this evening.

  6. Roland Haas
    • removed comment

    Replying to [comment:5 anonymous]:

    That's a neat command... I'll be sure to use it next time I compress the disk image. I also created an internal swap partition of about 768MB which I could overwrite internally with 0s then re-create swapfs before compression.

    That might make sense yes. Filling it with something easily compressible (dd from /dev/zero should do the trick after turning off swap).

    8GB is the fixed upper size limit of the VM disk. I had configured the disk image for dynamically-expanding storage albeit with an 8GB limit. Is that the internal size according to the guest OS (df -h)? If not then you might have the 'Fixed-sized storage' option selected for the disk, in which case it will always occupy 8GB on the host OS.

    Well the sfill command writes zeroes everywhere so it will make the disk grow to its maximum size. I don't know how to shrink the disk again or to fill with zeros without growing.

  7. Log in to comment