johnsonm / flimage Goto Github PK

It might work to use setarch and/or use an explicitly 32-bit flavor in the system model, but I have never tested it.

It does nothing to avoid using the conary configuration from the
host system. This means that if, for example, you have different
excludeTroves in the system on which you run it from excludeTroves
in the configuration within the image, running conary sync in the
images might add/remove components. (I tend to see this with
:supdoc components. when I build a non-devel system on a
devel system)

If one day we decide to port flimage to python3, it will probably make the porting process less painful if we have the foresight to begin adopting forward compatible py2.x syntax and idioms.

A simple example would be print() and string substitution:

# forward compatible from 2.6 -> 3.x (note the extra parentheses)
print("There are %s types of people in the world; those who understand binary and those who don't." %
      (bin(2)[2:]))

Additional resources:

• http://wiki.python.org/moin/PortingPythonToPy3k
• http://python3porting.com/
• http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/

On 64-bit systems running under setarch, 64-bit python needs to use the 64-bit syscalls even when setarch is set to a 32-bit machine architecture.

I can't believe I even run this script without one...

66fb782 introduced a regression where if there is no process left over to kill from tag/script troves the image generation fails and jumps to the inspection shell.

the simple test model bellow triggers it.

search group-world=foresight.rpath.org@fl:2-devel
install group-core
update foresight-conary-config=foresight.rpath.org@fl:2-devel/2-0.3-1
erase libata-migrate

When flimage was originally written, kpartx -d was successfully removing the device-mapper targets for the partitions when building a hard drive image.

Recently, it is at least sometimes failing doing so, which is leaving loop devices allocated.

It does work to run dmsetup remove /dev/mapper/loopNp1 and losetup -d /dev/loopN so we can do that if kpartx fails.

If tag or trove scripts leave running processes, or possibly in other situations, you will be left with a partitioned loopback-mounted image file and will have to clean up by hand.

You will need to look at the output to know which loopback devices need to be cleaned up. Cleanup will have to be done as root. This example assumes loop0 is the base:

fuser -mkv path/to/mki.something
fuser -k 9 -mv path/to/mki.something
umount path/to/mki.something
dmsetup remove /dev/mapper/loop0p1
losetup -d /dev/loop0

It's too hard to find the right logfiles, especially after lots of runs,
because they are not renamed after running.

When the root password is not set, a literal empty string "" is written to the /etc/passwd file (and thence put in the /etc/shadow file), which does not match any real password.

There should be an option (off by default) for the size of swap to allocate.

If it is a swap file, it should be /var/swap and should have 0600 permissions.

Image swap should never be used during the image build process. The data written to swap would both be extra data to compress and an information security vulnerability if the images are provided to others.

For some use cases, there is no need to include the conary database on the installed system. We could add an option to skip copying the conary database into the installed image. We could even (mostly) separate whether to copy in the modelcache, conarydb/rollbacks, and manifest.

The modelcache is trivially rebuilt; including it makes an initial "conary install" operation faster.

The conarydb can be rebuilt from the manifest with recreatedb or from the system model (more expensively) with --just-db if the manifest is not included.

There is no point in the modelcache without the conarydb so eliminating the conarydb should also eliminate the modelcache.

Currently, "progress" output for some commands overwrites printing previous commands, but not others, making the steps taken to create the image less transparent (though they are all recorded in the log file).

The progress should simply be printed without hiding completed commands.

Hard drives images currently always have 2048 sectors reserved, and then a single ext4 partition which takes up all the rest of the disk. It would be good to be able to provide a list of partitions to use. Particularly useful would be putting swap at the front, since that's generally the fastest part of the disk.

When developing images, it would sometimes be convenient to drop into a shell session in the image chroot in order to inspect the contents of the image without separately mounting and booting it, especially when it's a partitioned image that takes a few extra steps to mount again.

In /etc/sysconfig consider creating: keyboard clock mouse i18n

set /etc/localtime to UTC if it doesn't already exist?

The workaround for failing kpartx -d fails tearing down loop devices if they are already torn down.

After installation is not complete, if /etc/shadow does not exist, run:

/usr/sbin/authconfig --kickstart --enablemd5 --enableshadow --disablecache

When partitioning GPT disks, in the recent GPT-support commit we leave room for one default stride (64KiB) at the end of the disk. However, we do so with the assumption that one sector is always 512 bytes and that, hence, 128 sectors will equal 64KiB.

Would it make sense to be able to support creating images for modern high-capacity hard drives with native 4K sectors (firmware and physical media both use 4K sectors) by supplying a --4kn argument (implying that 512 byte sectors is the default)?

For 512e drives (firmware reports 512 bytes per sector, physical media uses 4K sectors), we already do the right thing.

See http://en.wikipedia.org/wiki/Advanced_Format for the nitty gritty details and references

In multiple tests (all conducted with the image and logfile being written to an otherwise idle ext4 file system), sparse images were never measurably slower (even when the image was sized to have minimal empty space) and normally faster (whenever the amount of free space was significant).

Therefore, sparse images should be the default.

The name of the error log file is not interpolated into the error message string, so it prints out a literal %s where the file name should go.

The flimage script should probably modify sys.path based on the
executable path rather than assuming that the user has set
PYTHONPATH to point to the directory containing the
imagebuilder module.

needed to support larger than 2TB installs and / or 4k sector hdds.
afaict we 'd need to
a) create partition with parted or gdisk
b) flash syslinux' gptmbr.bin on the MBR instead of mbr.bin

No other compression or archive format is currently supported

raiseErrors tries to write a list instead of a string to sys.stderr

/etc/bootloader.d/root.conf has no trailing newline