We have no apt source lists configured at that moment,
so we have to install it through temporary apt database
Change-Id: Ia8dc8c9a9fa37ac92f84d78739ad7f8bea7e34a4
Noticed the following errors during Carrier mr4.3 installation:
> Installing apt-transport-https
> ...
> Err http://web01:9998 wheezy/main amd64 Packages
> 404 Not Found
> Err http://web01:9998 wheezy/contrib amd64 Packages
> 404 Not Found
> Err http://web01:9998 wheezy/non-free amd64 Packages
> 404 Not Found
> WReading package lists...: Failed to fetch http://web01:9998/debian/dists/wheezy/main/binary-amd64/Packages 404 Not Found
> W: Failed to fetch http://web01:9998/debian/dists/wheezy/contrib/binary-amd64/Packages 404 Not Found
> W: Failed to fetch http://web01:9998/debian/dists/wheezy/non-free/binary-amd64/Packages 404 Not Found
Which is correct as there is no wheezy repository in Approx.
We should use appropriate ${DEBIAN_RELEASE} repository.
Notes:
* apt-transport-https from jessie repo is good enough,
switch from wheezy to jessie
* fai-setup-storage liblinux-lvm-perl from jessie repo is good enough,
cleanup the update code here
* virtualbox-guest-additions-iso from jessie repo is good enough,
switch from wheezy-backports to jessie
* augeas-tools from jessie is good enough,
switch from wheezy to jessie
Change-Id: I0de23b673da61b332af9fd9cfbcb36fb9b99d0d6
We're hitting "Error: File not found" GRUB errors during wheezy->jessie
upgrades. While this doesn't cause any hard problems since the boot
still continues automatically we should ensure that the grub-pc
package knows where to install the bootloader.
grml-debootstrap >=0.74 provides the according grub-pc/install_devices
debconf support.
Change-Id: I6062888a132389b279c0ce4987334866da98a689
Label is limited to 11 symbols for FAT (type 'vfat'),
default for USB drives nowadays to mount it easily.
So we need to change the defaults here to support both
CDROM and USB flash cards.
Also it is not recommended using spaces here.
So, SIPWRESCUE0 - test drive with fake rescue data
SIPWRESCUE[1-x] - real rescue drives, where x is a version.
Change-Id: I21abd08b01023f9ac6c63258027d515dd093def5
New mode 'auto' is introduced, we are trying to find any device with
label "Sipwise Hiera Rescue *" and mount it using appropriate device type.
Also switch to function die() on error to set set_deploy_status=error
properly (otherwise jenkins doesn't detect error on autotests).
Change-Id: I0a9900b0e8edcb1e12f09caaf66e94a49b8ac863
In some cases puppet should be restarted in order to catch up with
system changes it did itself. For instance if ldap is installed in
puppet session new users won't be available for puppet in the same
session. With this change we have flexibility to run puppet first just
to insall core utils and then do a second normal run.
Change-Id: I7f8d9a7cb45ddcf6c32fd836a4cc488f572092c8
parted supports the "-a optimal" option to get better alignment during partition table setup.
We should use that by default, since it:
a) shouldn't cause any harm on VMs anyway and
b) might improve performance especially on SSDs with non-standard
optimal_io_size settings (as observed on a Samsung EVA 850
with a setting of 33553920, so the partition should start
at 33.6MB and not 1MiB/2048s)
NOTE: fai-setup-storage doesn't support setting the parted options
like "-a optimal" yet, reported as #812712 in Debian's BTS.
Change-Id: Ib1c49d4f2b405697f0dcac5f164473ea9f87557c
NOTE: puppet success exit codes are different for different actions:
- 'puppet agent -t' exit code is '2' if no errors happen,
- 'puppet agent --enable' exit code is '0' if no errors happen.
Jenkins should detect puppet error exit codes and fail the test job.
Change-Id: I8df33897bd647e53a4f895c79c82749b97c7313c
The "--yes" workaround for LVM2 is needed for LVM versions
newer than >=2.02.106 to avoid a hanging prompt during
partition setup. Starting with FAI 5.0 the workaround
for this is included in FAI's setup-storage and therefore
we don't need our workaround any longer, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750212
So ensure that fai-setup-storage is new enough, and only
if not then check the lvm2 package version and apply the
workaround as needed.
Fixes:
| Executing: lvcreate --yes --yes -n swap -L 1002.755859375 vg0
| (STDERR) Option -y/--yes may not be repeated.
Change-Id: Ic4445e0add5aab8da0ef87b77b08e23fc0d1c9ab
The latter is a transitional dummy package that will be going away in
the near future. Switch to it now, instead of waiting for the inevitable.
Also this way we get less cruft on the installed system.
Change-Id: I6679d3eafed07548dfebf0dc8a5b2fe75a5ef58d
Sipwise systems/VMs works well because we rebuild /etc/ssh/sshd_config
from templates and enable supporting /root/.ssh/sipwise_vagrant_key
while for plain VMs we do nothing, so we have to handle it here.
Change-Id: Ib7eccda1a8b9692da6e581aef47c3ccddeb229f6
When we install a fresh squeeze system we want to avoid the
occasional "Hash Sum mismatch" errors during apt-get runs,
so let's not only cover that via upgrades but also in the
initial installation.
Also cover it for Debian lenny, since it very probably might
be affected as well (unverified though).
Change-Id: I01dbeec5ef2a727e5749be5db3ebea47818ed3b5
With the according SSL setup in place nothing should prevent
us to enable HTTPS by default.
The only issues left here are the usage of https for
our internal management web service on port 3000 and
the usage of HTTPS with approx.
Change-Id: I7c9c3d947c6b880b9145ca83a31c832049c6573a
puppet in jessie depends on ca-certificates/openssl which
cant' be removed therefore. We actually want to have
ca-certificates/openssl on all our systems anyway and
nowadays debootstrap doesn't install tcpd and xauth any longer,
so we can safely skip those package removals for jessie and newer.
The templatedir doesn't need to be set in recent puppet versions
and older versions use a sane default anyway, therefore dropping it.
puppet as present in jessie (and newer) expects 'puppet agent --enable'
to be executed to actually be enabled.
Change-Id: Iae70eaeec6a56bef0e67171aab74482aebb24181
Since lvm2 v2.02.106 its udev rule creates a
/dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for PVs:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=417e52c13a8156b11c25c411d44bda8b32bf87e4
When debootstrapping Debian/wheezy to a virtio disk from a system
using lvm2 >=v2.02.106 (as present in Grml >=2014.11) this causes
the resulting GRUB installation to look like that
(`/media/ngcp-root` is the mounted logical volume with the rootfs
which also includes /boot):
| root@grml ~ # cat /media/ngcp-root/boot/grub/device.map
| (hd0) /dev/disk/by-id/lvm-pv-uuid-RNZHr8-hLlc-nles-X9Gs-RYSp-Mqo7-uZTk6N
| (hd1) /dev/vda
and failing to boot with:
> error: no such disk
> Entering rescue mode...
> grub rescue>
When manually removing the lvm-pv-uuid* symlink from the
Debian/jessie system before installing GRUB it works fine:
| root@grml ~ # rm /dev/disk/by-id/lvm-pv-uuid-RNZHr8-hLlc-nles-X9Gs-RYSp-Mqo7-uZTk6N
| root@grml ~ # ls /dev/disk/by-id
| ata-QEMU_DVD-ROM_QM00003@ dm-name-ngcp-swap@ dm-uuid-LVM-lQhnvLyYmhESObLrZcnJs4FTZq9usVDzRex3ImRtrmqhpDH9xKBj22St82lHDADh@
| dm-name-ngcp-root@ dm-uuid-LVM-lQhnvLyYmhESObLrZcnJs4FTZq9usVDzrcMaDfk8O0RionEYRxdjnYxsY6eb0Esi@
| root@grml ~ # grml-chroot /media/ngcp-root/ grub-install --recheck /dev/vda # `grml-chroot` makes sure /proc, /sysfs and /dev are properly mounted in the chroot
| Writing /etc/debian_chroot ...
| Installation finished. No error reported.
| root@grml ~ # cat /media/ngcp-root/boot/grub/device.map
| (hd0) /dev/vda
NOTE: This problem seems to exist only for virtio disks, when
using a disk on the SATA bus the resulting device.map of the
Debian/wheezy system looks like that and boots fine:
| root@grml ~ # cat /media/vg0-root/boot/grub/device.map
| (hd0) /dev/disk/by-id/ata-QEMU_HARDDISK_QM00005
| (hd1) /dev/disk/by-id/lvm-pv-uuid-lJJr4E-M96R-3eIS-b6YO-5usn-bH5o-osQV2B
As a result check for Debian wheezy (or older) and if the disk is
a virtio one (AKA /dev/vda), if so then remove the symlink of the
live system before installing Debian incl. GRUB via
grml-debootstrap.
Reported as https://bugs.debian.org/782998 in Debian's BTS.
Change-Id: I4b2cf9e39c88521ab7eac7799531508e658cc30d
During the refactoring in 43c9f159 we missed the point that
/etc/debootstrap/pre-scripts/install-sipwise-key.sh should be
executed on CE install CD too even if we do NOT download key.
Otherwise we are getting:
> Reading package lists...
> W: GPG error: http://debian.sipwise.com wheezy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4EB7765DA42C4F2A
> W: GPG error: http://debian.sipwise.com wheezy-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4EB7765DA42C4F2A
> W: GPG error: http://debian.sipwise.com wheezy-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4EB7765DA42C4F2A
and CE installation failed as unauthorized packages cannot be installed.
Change-Id: I3ccc8b8801ba2be829c4eea84507f11c841b7658
It allows to test scenarios where ngcp-installer is comming from one PPA
while other packages (like ngcp-templates) are comming from another PPA.
By default NGCP_PPA_INSTALLER is equal to NGCP_PPA,
so we still can define one boot option only:
> ngcpppa=gerrit_MT12345_review777
while for some cases it is useful to define:
> ngcpppa=gerrit_MT12345_review777 ngcpppainstaller=gerrit_MT54321_review778
Change-Id: Icf2fee70db1beaae08e9d9c3eba87c5a836661b7
Also removed sipwise user from 'plain' VM boxes,
it is not necessary there as we use user root in Vagrant.
Change-Id: I84c8ab6b1cd6e9dd7ba94f6871b79bafb153bd4e
Also, we did s/RETRIEVE_MGMT_CONFIG/CARRIER_EDITION/g because /etc/hosts
and /etc/network/interfaces are fully configured for Carrier by ngcp-installer.
So, no need to touch them for Carrier at all now
(see commits to installer.git through this ticket).
Change-Id: Ie16038d1f6c194564bb91c52faab75e86e3a0c11
Jenkins User
Alexander Lutay
Michael Prokop
Sergii Kipot
Guillem Jover
Victor Seva