In case of DHCP server is being used, and system was rebooted
with new IP, network.yml still has old IP and SSH will listen old IP only.
Vagrant cannot connect VM using old IP to change it to new one.
In case of CE with one network interface (common case)
ngcp-eadresss will update network.yml and apply new config.
PRO should not be installed using DHCP (at least in production).
Vagrant VMs has two interfaces, so ngcp-eadresss does nothing,
so we add option to config.yml which overwrites ssh_ext types in
network.yml.
We have an error "reset: standard error: Invalid argument" in header of
CE install CD, so replated reset with clear which worked well for long time
during the nightly builds.
Also removed all the additional calls for logo() function.
(I have no ideas what can be the reason of broken layout MT#4697,
spent a lot of time trying to catch it, it comes time-2-time,
so currently minimised amount of any functions calls during printing logo).
I hope to catch this one day and fix it in prtoper way.
Debian's BTS has all the details in #750212 which I just reported.
lvm2 version 2.02.106-1 includes a check for present signatures,
and without "--yes" option fai-setup-storage is hanging when
executing lvcreate on a device which includes such a (swap) signature.
We don't want to use the sources.list generation which
grml-debootstrap does, as we want to control 100% of
what we use/deploy, so provide sources.list as needed.
I think we finally tracked down the problem to its roots (oh boy… ٩(͡๏̯͡๏)۶)):
The problem exists only for PRO systems, where we ship the
heartbeat-2 package, which still uses and provides the /usr/lib64
directory (that's what you get for running antique software
*cough*). As soon as this directory exists the
VBoxLinuxAdditions.run script of virtualbox-guest-additions-iso
detects and uses this directory as library path. It installs the
mount.vboxsf symlink using this library path.
The symlink /sbin/mount.vboxsf points to the non-existing
/usr/lib64/VBoxGuestAdditions/mount.vboxsf file instead of
pointing to
/usr/lib/x86_64-linux-gnu/VBoxGuestAdditions/mount.vboxsf.
It works for CE systems, because we don't ship the heartbeat-2
package there. Without heartbeat-2 /usr/lib64 doesn't exist and
VBoxLinuxAdditions.run does the right™ thing by detecting
and using /usr/lib/x86_64-linux-gnu instead.
If that's finally working as expected™ I'll be able to sleep much
better again… ☻
We're still facing:
| root@sp1:~# mount -t vboxsf -o uid=`id -u sipwise`,gid=`getent group sipwise | cut -d: -f3` /vagrant /vagrant
| mount: Protocol error
on some VMs (noticed on e.g. 3.1 PRO system with 3.13-0.bpo.1-amd64).
The /sbin/mount.vboxsf file is missing for some reason we're not
aware of yet.
Let's get rid of unneeded AllowUnauthenticated usages with apt.
It would be even better if we could ship our own key with the
official Grml-Sipwise ISO (which would technically be no problem,
but we need a way for PXE boot for builder.mgm anyway).
Always writing to /etc/apt/sources.list is stupid
because it makes tracking changes harder, so let's
try to move debian specifica into debian.list and
sipwise specifica to sipwise.list instead.
Even if our own key is already installed the package list might
not be up2date yet (e.g. for wheezy-backports):
| The following NEW packages will be installed:
| linux-compiler-gcc-4.6-x86 linux-headers-3.13-0.bpo.1-amd64
| linux-headers-3.13-0.bpo.1-common linux-kbuild-3.13
| The following packages will be upgraded:
| linux-headers-amd64
| 1 upgraded, 4 newly installed, 0 to remove and 1 not upgraded.
| Need to get 5187 kB of archives.
| After this operation, 32.9 MB of additional disk space will be used.
| WARNING: The following packages cannot be authenticated!
| linux-compiler-gcc-4.6-x86 linux-headers-3.13-0.bpo.1-common
| linux-kbuild-3.13 linux-headers-3.13-0.bpo.1-amd64 linux-headers-amd64
This is an urgency bugfix to address the failing
libssl1.0.0 1.0.1e-2+deb7u6 upgrade which is prompting
via debconf and causing our builds to fail because of that.
On plain Debian installations we don't have the ngcp-keyring
package present, so we run into:
| WARNING: The following packages cannot be authenticated!
Using debian.sipwise.com which is a CNAME record pointing to
deb.sipwise.com prevents us from getting higher apt-pinning
for official Debian packages which are mirrored on our own
server.
Related commit history: 8832daa7ea1b3eb0fd8400101b6
The "Install sip:provider CE" boot entry in the Grml-Sipwise ISO
which doesn't provide a ngcpvers kernel cmdline option doesn't
work, this change is supposed to address that.
Alexander Lutay
Michael Prokop
Kirill Solomko