- 09 May, 2014 9 commits
-
-
Mike Hibler authored
This should be run whenever an image is created or updated and possibly periodically over existing images. It makes sure that various image metadata fields are up to date: * hash: the SHA1 hash of the image. This field has been around for awhile and was previously maintained by "imagehash". * size: the size of the image file. * range: the sector range covered by the uncompressed image data. * mtime: modification time of the image. This is the "updated" datetime field in the DB. Its intent was always to track the update time of the image, but it wasn't always exact (create-image would update this with the current time at the start of the image capture process). Documentation? Umm...the usage message is comprehensive! It sports a variety of useful options, but the basics are: * imagevalidate -p <image> ... Print current DB metadata for indicated images. <image> can either be a <pid>/<imagename> string or the numeric imageid. * imagevalidate <image> ... Check the mtime, size, hash, and image range of the image file and compare them to the values in the DB. Whine for ones which are out of date. * imagevalidate -u <image> ... Compare and then update DB metadata fields that are out of date. Fixed a variety of scripts that either used imagehash or computed the SHA1 hash directly to now use imagevalidate.
-
Mike Hibler authored
-
Mike Hibler authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
the vlan devices on it (inherits MTU).
-
- 08 May, 2014 2 commits
-
-
Mike Hibler authored
XEN_CORES and XEN_MEMSIZE, which default to 1 and 1000 for backward compat.
-
Mike Hibler authored
If the Xen dom0 base image is properly (1M) aligned and the VM images are properly aligned as well, we should avoid or at least minimize any anomolous effects due to mismatches along the path involving the guest OS, guest disk layout, LVM LVs, LVM PVs, and the underlying physical disks. Also, random change to add a min size parameter to the findSpareDisks function. I was going to use this to avoid sucking up the little 3GB unused partition in MBR 3, but then decided against it.
-
- 07 May, 2014 4 commits
-
-
Mike Hibler authored
-
Mike Hibler authored
Ironic. After all that hoo-haw about dynamically-created MBRs in the previous commit, we introduce a new hardcoded static MBR... Goals: * Single OS partition, in the fast area of rotating disks * Proper alignment for 4k sector drives and SSDs (1MB alignment) * Still works on 40GB disk (aka, pc850s) * P1 16 GiB: goldilocks FS: not too small (> 10GB), but not too big (< 30GB) * P2 3 GiB: can hold a co-loaded MBR 1 image (e.g., FBSD410 delay node OS) * P3 3 GiB: at least as much swap at currently (>= 1GB) The partition table: P1: 2048 33554432 FS, 16GiB P2: 33556480 6291456 possible delay-node OS or additional swap, 3GiB P3: 39847936 6291456 swap, 3GiB P4: 46139392 34278848+ extrafs, 16+GB The larger size and partition alignment are why I pushed this through despite my noble intentions.
-
Mike Hibler authored
New loadinfo returns: IMAGELOW, IMAGEHIGH: range of sectors covered by the image. This is NOT the same as what imageinfo or imagedump will show. For partition images, these low and high values are adjusted for the MBR offset of the partition in question. So when loading a Linux image, expect values like 6G and 12G. The intent here (not yet realized) is that these values will be used to construct an MBR/GPT on the fly, rather than using hardcode magic MBR versions. You can get the uncompressed size of the image with (high - low + 1). IMAGESSIZE: the units of the low/high values. Always 512 right now, may be 4096 someday. IMAGERELOC: non-zero if the image can be placed at an offset other than IMAGELOW (i.e., it can be relocated). This may or may not prove useful for dynamic MBR construction...we will see. Probably didn't need to bump the version here, but I am playing it safe.
-
Kirk Webb authored
-
- 06 May, 2014 23 commits
-
-
Kirk Webb authored
-
Mike Hibler authored
Looks like this has been the case since at least FreeBSD 7.x, so this should not be a problem. I also merged the suidperl checks into this to make a more general "perl" phase file (replacing "sperl").
-
Kirk Webb authored
-
Kirk Webb authored
Also clean up some commented out stuff from the pnet index page.
-
Kirk Webb authored
-
Kirk Webb authored
-
Kirk Webb authored
And a couple of minor fixes.
-
Kirk Webb authored
-
Kirk Webb authored
-
Kirk Webb authored
... Boy do I suck at this color choosing stuff.
-
Kirk Webb authored
-
Kirk Webb authored
And a couple of fixes.
-
Kirk Webb authored
Specifically, this was done to support the PhantomNet alternate view. Several blocks of code were factored out of WRITESIDEBAR() and moved into their own functions so that they could be reused in a PhantomNet-specific version of WRITESIDEBAR().
-
Kirk Webb authored
-
Kirk Webb authored
Don't use separate directory for PhantomNet files.
-
Kirk Webb authored
If an alternate_domans_THISHOMEBASE.php file is present, include it. This file should contain alternate page view options and global variable overrides (see code for SetDomainDefs() in defs.php3).
-
Kirk Webb authored
Base variables off of requested virtual server name instead of hard coding them.
-
Kirk Webb authored
-
Kirk Webb authored
A changed look and some cases feel for the Emulab UI for when users come in through a PhantomNet domain. This commit contains a very spare conversion attempt, just to see if I can get things moving in the right direction.
-
Kirk Webb authored
-
Kirk Webb authored
-
Mike Hibler authored
-
Mike Hibler authored
Hopefully, my last schema change related to images. If relocatable is not set then an image must be loaded at the lba_low offset. If set, then the image can be loaded at other offsets. Currently, all FBSD images are relocatable courtesy of the relocation mechanism in imagezip (which can fix up otherwise absolute offsets in an image). Sadly, Linux images are not relocatable due to absolute block numbers in the grub partition bootblock that we require. Ryan "taught" imagezip to relocate these, but I need to find his changes.
-
- 05 May, 2014 2 commits
-
-
Jonathon Duerig authored
-
Mike Hibler authored
The old way worked...sorta. When we deleted the old partition and then recreated it with gpart, it would create the new one at the end of the disk, not likely where the old partition was previously. In elabinelab setup the combo: mkextrafs -s 2 ... /usr/testbed mkextrafs -s 4 ... /q resulted in slice 2 getting created at the end of the disk (where slice 4 would normally be) and then slice 4 getting created in the only remaining available space (where slice 2 would normally be). Very confusing to my Monday morning brain...
-