We have now that documented in the Debian Wiki:
https://wiki.debian.org/Vagrant#Vagrant_from_Debian_11_or_previous_versions_hang_on_.22default:_Waiting_for_SSH_to_become_available22
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian
Thanks Andrew for the time you took investigating this.
So I understood right, this was a problem in the way Vagrant ruby
library did ssh connection, as in presence of a ssh-rsa key it would
always try to connect using a SHA-1 signature algorithm (the algo which
was dropped by newer OpenSSH)
On 2/3/22 22:58, Hans-Christoph Steiner wrote:
> - you add to your pull request a change of the virtualized disk
> controller from virtio-blk to virtio-scsi and to the default libvirt
> vagrantfile the "unmap" option so that deletion of blocks in the guest
> are propagated om host storage
I
I did some testing around
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/tree/1TBv2
(not merged in master yet) and I am still reluctant to merge the branch.
I am OK to bump the default disk size to something like 40GB but not to 1TB.
The problem with the disk size of 1TB is as such:
Hi all
I am following the
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/11
and wanted to remark something that did not come to my mind earlier.
If the build you're using inside the Vagrant box needed need so much
room in the filsystem, what about doing this build
Hi Hans
I had a look at the fai-disk-image, and it seems that nothing in the
toolchain prevents us from using a disk image with a larger virtual size
for VirtualBox *and* libvirt,
as currently:
- we create a sparse file of raw format using fai-disk-image
- then we convert this disk image to a
Package: cloud.debian.org
The Vagrant guidelines say:
"you should create a dynamically resizing drive with a large maximum
size. This causes the actual footprint of the drive to be small
initially, but to dynamically grow towards the max size as disk space is
needed, providing the most
Le 12/04/2021 à 13:14, Christopher Huhn a écrit :
> Package: cloud.debian.org
> Severity: serious
>
> The latest Buster libvirt image for vagrant gives me a 404, `vagrant box
> update` fails.
>
> λ > curl
>
On 3/2/21 10:03 PM, Henning Sprang wrote:
Hi Emmanuel,
Thanks for your quick and helpful response.
On Fri, Feb 26, 2021 at 9:31 AM Emmanuel Kasper <mailto:m...@debian.org>> wrote:
> ...
> Actually, you don't need anymore the vagrant-vbguest pluging for testing
> box
Le 26/02/2021 à 22:54, Lucas Nussbaum a écrit :
> On 26/02/21 at 20:07 +0100, Lucas Nussbaum wrote:
>> On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
>>> On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
IMO we cannot know which device name is used by the users virtualisation
On 2/26/21 3:13 AM, Henning Sprang wrote:
Package: cloud.debian.org
Severity: normal
X-Debbugs-Cc: henning.spr...@gmail.com
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I am setting up a system with the
I think this bug is due to the switch to fai for testing/bullseye.
IIRC with fai, we run a dhcp client for each interface, which would
cause the double IP adresses you see (one set up by DHCP, one set up by
Vagrant directly over ssh when booting the VM)
Hi
This behaviour causes a number of problem when building disk images for
hypervisors / cloud providers where you don't know beforehand the device
name of the grub device on which grub will re install.
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982591 )
For instance I can build
Le 12/02/2021 à 19:14, Evgeni Golov a écrit :
> On Fri, Feb 12, 2021 at 06:55:35PM +0100, Emmanuel Kasper wrote:
>> Le 12/02/2021 à 12:36, Evgeni Golov a écrit :
>>> On Fri, Feb 12, 2021 at 10:03:08AM +0100, Thomas Lange wrote:
>>>> This behaviour was also reported
Le 12/02/2021 à 12:36, Evgeni Golov a écrit :
> On Fri, Feb 12, 2021 at 10:03:08AM +0100, Thomas Lange wrote:
>> This behaviour was also reported as #982182
>
> Interesting, thanks!
>
> To me the GRUB change seems reasonable, even if a tad unexpected in a
> point release.
>
> You change to FAI
Le 11/02/2021 à 19:26, Francesco P. Lovergine a écrit :
> On Thu, Feb 11, 2021 at 06:15:24PM +0100, Emmanuel Kasper wrote:
>> if testing64 is working so far, including with the kernel of your
>> choice, should we close this bug report ?
>>
>
> Well, in any case I
Hi Uros
Thanks for your interest for the Vagrant boxes.
There are two ways you can solve this:
- either you use the box debian/contrib-buster64 which comes with the
guest additions preinstall, and you remove the vbguest plugin so that it
does not try to reinstall the extensions
- or you simply
if testing64 is working so far, including with the kernel of your
choice, should we close this bug report ?
$ vagrant plugin uninstall vagrant-vbguest
Uninstalling the 'vagrant-vbguest' plugin...
Successfully uninstalled micromachine-3.0.0
Successfully uninstalled vagrant-vbguest-0.29.0
frankie@legolas:~/vagrant
$ vagrant plugin list
No plugins installed.
frankie@legolas:~/vagrant
$ vagrant destroy
Le 10/02/2021 à 10:22, Francesco P. Lovergine a écrit :
> On Wed, Feb 10, 2021 at 10:13:02AM +0100, Francesco P. Lovergine wrote:
>> Well, it is automagically done by vagrant at provisioning time for
>> the debian/testing64, maybe because the local Virtualbox installation
>> has the extension
config.vm.provider "virtualbox" do |v|
v.customize ["modifyvm", :id, "--graphicscontroller", "vmsvga"]
end
That could probably considered a vagrant issue. I found that it is a
non-issue with 4.x up to 5.9, but 5.10+ is not compatible with the
default choice. Not sure if the suggested
Hi Frankie
Thanks for you interest for the Vagrant Boxes.
Can you reproduce the issue with
https://app.vagrantup.com/debian/boxes/testing64 ?
contrib boxes are going the way of the doodo for bullseyes, as the dkms
kernel drivers needed for the guest extensions are now in the mainline
kernel
Thank you for your interest for the Vagrant Boxes.
This problem did not appear in the test suite, so I suppose it is a
local file corruption of the base box.
Can you try to destroy the vagrant environment, delete the base box and
reprovision ?
You should be able to do that with:
vagrant
Package: wnpp
Severity: wishlist
* Package name: cri-o
Version : 1.20
Upstream Author : Multiple Authors
* URL : https://cri-o.io/
* License : Apache 2.0
Programming Lang: Golang
Description : Lightweight container runtime for Kubernetes
cri-o provides
Hi Laurent
You can install the crun package to fix the service error ( I suppose
you found that out already)
You can find an intro about podman and varlink here:
https://podman.io/blogs/2019/01/16/podman-varlink.html
I think there is a problem in the Depends of podman:
Hi Andrew
That you for your interest in Debian and Vagrant Boxes.
I read you mail it details, and it seems that you have rather a problem
with the debian installer, rather than with the existing Debian boxes.
If you want to have a debian sid system in Vagrant, you should use one
of the testing
Hi Kurt
Thank you for reviving the vagrant-lxc boxes, I wanted to ask, what do
you think we should do about
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951347 ?
The bug is critical as it prevents doing anywork with the vagrant-lxc,
so I think we should remove the boxes from the vagrant
Hi Nicolas
Sorry I missed your mail here.
The Virtualbox default for Buster is ifupdown, and that will remain the
case as long as Debian uses it as the default.
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Le 25/11/2019 à 11:40, Jonas Meurer a écrit :
> Hi Emmanuel,
>
> Emmanuel Kasper:
>> Le 23/11/2019 à 14:17, Jonas Meurer a écrit :
>>> Package: cloud.debian.org
>>> Severity: important
>>>
>>> Hello,
>>>
>>> for so
Le 24/11/2019 à 17:12, Emmanuel Kasper a écrit :
> The package cache for Base Boxes is anyway always updated,
I meant here always OUTDATED ...
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Le 23/11/2019 à 14:17, Jonas Meurer a écrit :
> Package: cloud.debian.org
> Severity: important
>
> Hello,
>
> for some reason, boxes for providers 'libvirt' and 'virtualbox' are missing
> for
> buster64 tag 'v10.1.0' from https://app.vagrantup.com/debian/boxes/buster64.
>
> Unfortunately,
Am 18.09.2019 um 21:08 schrieb Geert Stappers:
On Wed, Sep 18:
On 2019-09-18 1:36 a.m., Geert Stappers wrote:
On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
vagrant boxes images that would have puppet/ansible pre-installed
Hello Gabriel !
Thanks for your interest for
Le 23/07/2019 à 12:28, Jörg Sachse a écrit :
> Package: cloud.debian.org
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> I tried to provision a new VM using Ansible/Molecule, Vagrant and VirtualBox.
> molecule/default/molecule.yml
> (...)
> platforms:
> -
I have problems uploading boxes at the momment via the vagrant cloud api.
If the problem persist, I will upload the boxes manually. ( +I was on
holiday the last weeks )
Users have not been forgotten :)
Am 18.07.2019 um 09:42 schrieb Nicolas Quiniou-Briand:
Hello,
I got the same on my side.
Le 17/06/2019 à 15:03, Nicolas Quiniou-Briand a écrit :
> Package: cloud.debian.org
> Severity: important
>
> Hello,
>
> Since upgrade to debian/stretch64 9.9.1 image, I noticed that virtual
> machines share
> the same client ID in libvirtd. Consequently, libvirtd override old DHCP
> lease by
I removed the libvirt provider for the latest uploads which introduced
the regression
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Le 11/06/2019 à 17:07, Antonio Terceiro a écrit :
> Control: retitle -1 vagrant images: network setup in libvirt images are not
> consistent with Debian defaults
>
> On Tue, Jun 11, 2019 at 04:15:12PM +0200, Nicolas Quiniou-Briand wrote:
>> Package: cloud.debian.org
>> Severity: normal
>>
>>
I rebuilt and uploaded the 12 boxes concerned by this bug, should be OK now.
For virtualbox vagrant boxes, please find new box releases at
https://app.vagrantup.com/debian
Libvirt boxes are pending.
Extending the disk image to 20GB slows the build process a bit, as we need to
zero free a bigger filesystem, but it is still acceptable.
--
Diese Nachricht wurde von
>
> At this point, I think it'd be worth revisiting, at the project level,
> the historical tradition of leaving the sbin directories out of non-root
> paths. Setting aside all the single user desktop and laptop systems,
> there are enough alternative ways to grant restricted root (file ACLs,
>
I had a the same problem flashing a bbb black, and it looks like the
problem is caused by a wrong memory address for initrd and dt.
Using U-Boot 2018.09-2-g0b54a51eee
you need to set the following memory addresses in uEnv.txt
( values taken from
> Vagrant base boxes apparently use a maximum disk size of 10G.
OTOH the chosen format of the virtual disks does not allow to increase
the size (VBoxManage refuses to do so).
yes true. The reason is that during the build process, we convert the
raw disk image produced by packer to vmdk. Vmdk is
Ok i can reproduce the issue using the pc6.mbr posted by bouke:
cp pc6.mbr disk.img
# otherwise parted complains "Can't have a partition outside the disk"
truncate -s 600GB disk.img
# fdisk correctly detects the msdos partition table
fdisk -l disk.img
Disk disk.img: 600 GiB, 644245094400 bytes,
Le 28/08/2018 à 14:46, Franz Simader a écrit :
> Hello,
>
> I have the same problem as described in the Bug #896171.
>
> A valid *msdos *partition table with 3 partitions is shown with parted
> (3.2-17) as '*atari*' and only the first partition is visible.
>
> Is there a solution for this known
Hi bouke
I am a not GNU parted maintainer, but I am a both a Debian Developper
and Atari 16/32 bits user so I can help digging the Atari specific
problems here.
Could you please share the sfdisk sda-pt.sf you used to create the
partition table or the MBR of the disk having the problem ?
There
>> I am also on the libguestfs mailing list, should I mention the issue
>> there, or do you prefer to report this upstream yourself ?
>
> Please do mention it there, too.
Discussed upstream starting at
https://www.redhat.com/archives/libguestfs/2017-December/thread.html
I am also on the libguestfs mailing list, should I mention the issue
there, or do you prefer to report this upstream yourself ?
On 12/11/2017 03:37 PM, Hilko Bengen wrote:
> * Emmanuel Kasper:
>
>> After upgrading libguestfs0 to 1.36, the sub routine disk_virtual_size
>> fails with a qemu-img error.
>
> I assume that you mean the error below, am I correct?
Yes.
> ,
> | qemu-img: Coul
Package: libguestfs-perl
Version: 1:1.36.11-1
Severity: normal
Dear Package maintainer
After upgrading libguestfs0 to 1.36, the sub routine disk_virtual_size fails
with a qemu-img error.
Here is a small perl script which reproduces the issue:
#!/usr/bin/perl
use warnings;
use strict;
use
I reported the issue upstream in the vagrant cloud google group
https://groups.google.com/forum/#!topic/vagrant-up/V0E4PAajM-g
> Vagrant base box debian/stretch64 (and debian/jessie64) includes a home
> directory /home/vagrant containing only the .ssh directory: none of
> .bashrc,
> .profile and .bash_logout are present (i.e. files normally copied from
> /etc/skel). This makes the Vagrant user behaviour slightly different
have you tried to contact the upstream developers about this issue ?
I have used
http://forums.bannister.org/ubbthreads.php?ubb=postlist=8=1
in the past as a way to contact them, and they have been mostly responsive
Le 25/08/2017 à 14:39, Lucas Nussbaum a écrit :
> On 16/08/17 at 18:45 +0200, Lucas Nussbaum wrote:
>> Remaining action items are:
>> - fix the cleanup in the script that installs the guest additions
>
> I've done that, and pushed my code to master.
>
> Emmanuel, at this point, I think that the
Le 23/08/2017 à 10:12, Cyril Brulebois a écrit :
> Ansgar Burchardt <ans...@debian.org> (2017-08-23):
>> Emmanuel Kasper <m...@debian.org> writes:
>>> The default base system installed by debootstrap includes all packages
>>> with Pr
5e18585594bf93a1bec5e9f4f2496e016084805c
Author: Emmanuel Kasper <m...@debian.org>
Date: Tue Aug 22 22:12:21 2017 +0200
Document which packages are installed by a default variant
The default base system installed by debootstrap includes all packages with
Pritority ess
On 07/26/2017 01:45 PM, Lucas Nussbaum wrote:
> Hi,
>
> On 21/06/17 at 17:00 +0200, Emmanuel Kasper wrote:
>>> Debian has provided official vagrant base boxes in 2 flavors - one without
>>> the VirtualBox guest additions
>>> and the other with the guest
I commited the fix above in
git.debian.org:/git/cloud/debian-vm-templates.git
the next box rebuild will have this included.
This is needed for systemd-networkd dhcp client sending a unique id to the
dhcp server. Fixes: #868679
---
helpers/vagrant-setup | 5 +
1 file changed, 5 insertions(+)
diff --git a/helpers/vagrant-setup b/helpers/vagrant-setup
index 05fb74f..3f14406 100755
--- a/helpers/vagrant-setup
+++
On 07/17/2017 05:16 PM, Jan Grant wrote:
> The box image should not include those files (it suffices to delete them prior
> to packaging the image). This causes each instance to mint its own new
> UUID, which in turn results in distinct client-ids being supplied by
> systemd.
It does not seem to
> Debian has provided official vagrant base boxes in 2 flavors - one without
> the VirtualBox guest additions
> and the other with the guest additions, since the Jessie release. With
> Stretch released a few days back,
> only the base box without the guest additions is available. Please provide
On 06/08/2017 12:46 PM, Emmanuel Kasper wrote:
> I have uploaded a bug with the fix for contrib-jessie64 at
it was meant a vagrant *box* with the fix
I have uploaded a bug with the fix for contrib-jessie64 at
https://atlas.hashicorp.com/debian/boxes/contrib-jessie64
keeping the bug open until all boxes are rebuilt and uploaded
I uploaded a 8.8 contrib image where each VirtualBox is defined as type
82540EM (intel e1000)
can you check it if that fixes the problem for you ?
the box is available at
https://atlas.hashicorp.com/debian/boxes/sandbox/versions/8.8
I did a cycle of 10 vagrant up / vagrant destroy and could not
Le 30/05/2017 à 21:46, Branko Majic a écrit :
> On Tue, 30 May 2017 21:23:58 +0200
> Emmanuel Kasper <m...@debian.org> wrote:
>
>> Than you for the detailed bug report.
>>
>> I understand the unstable network card ordering can perturbate the
>> network conf
> After comparing the files in two boxes, turned out that
> debian/contrib-jessie64 defines different network adapter type for
> first network adapter and remaining ones (82540EM vs Am79C973). This
> probably results in somewhat random ordering in the VM itself when
> adapters are being named.
I can confirm the behaviour is mentioning.
@JD:
does the commits from pull requests 4900 and 4910 apply cleanly on
0.10.2 ? can you build a working packer passing the build tests with the
patches applied ?
Le 03/02/2017 à 23:55, Cyril Brulebois a écrit :
> Ian Campbell <i...@hellion.org.uk> (2017-02-03):
>> On Fri, 2017-02-03 at 15:51 +0100, Emmanuel Kasper wrote:
>>> Actually on further research, net.ifnames and most dot-containing
>>> parameters are not here
Actually on further research, net.ifnames and most dot-containing
parameters are not here for the kernel, but to configure on boot various
systemd components, the list of which can be found in
systemd-232/man/kernel-command-line.xml
or online in
Le 03/02/2017 à 12:38, Ian Campbell a écrit :
> On Fri, 2017-02-03 at 12:22 +0100, Emmanuel Kasper wrote:
>>>> A kernel boot param like net.ifnames=0 will be skipped when the
>>>> installer parses the boot option for setting the bootloader.
>> A kernel boot param like net.ifnames=0 will be skipped when the
>> installer parses the boot option for setting the bootloader.
>>
>> Found in di-utils:
>>
>> # Skip module-specific variables
>> varnodot="${var##*.*}"
>> if [ "$varnodot" = "" ];
Package: di-utils
Version: 1.117
Severity: minor
Tags: d-i
A kernel boot param like net.ifnames=0 will be skipped when the installer
parses the boot option for setting the bootloader.
Found in di-utils:
# Skip module-specific variables
varnodot="${var##*.*}"
I was hit by this bug when building Virtual Machines for Vagrant.
Not sure if it's a qemu bug or a Debian Networking problem, because if I
stop
the network with
service networking stop
and then request a new configuration with
dhclient eth0
then I get this time a IPv4 DNS entry from the qemu
changes since v1:
* do not fallback on dangerous read only kernel mounts if grub-mount is
missing, just exit with error
>From 34a2c247fa08d4e01aa08b5b75977c66d71df4f8 Mon Sep 17 00:00:00 2001
From: Emmanuel Kasper <emman...@libera.cc>
Date: Tue, 15 Nov 2016 14:52:23 +0100
Subject:
goes back as far as 2011.
>From 58c2cbf7660e93f52e43bdf076a5db9bc95d9889 Mon Sep 17 00:00:00 2001
From: Emmanuel Kasper <e.kas...@proxmox.com>
Date: Tue, 15 Nov 2016 14:52:23 +0100
Subject: [PATCH] do not mount partitions via 'mount' if grub-mount fails on a
block device closes: #8062
>> Since version 1.45, os-prober instead uses grub-mount when it's
available
>> -- and if grub is installed to use os-prober, it will pull it in.
>
>> So unless another bootloader is also using os-prober, or someone
>> installs and uses it by hand, this won't happen in unstable/testing.
> It's
I assume is on the vagrant-libvirt image on atlas.
The vagrant-libvirt boxes are made with vmdeboostrap.
Most probably the problem here is because vmdebootstrap was run in a
stretch host, and used ext4 tools which are newer than
the ext4 tools of jessie.
So we could rebuild the image on a jessie
I've pushed a new box with version 8.6.1 who should fix the bug ( I
tested it in a Virtualbox 5.0.* env and the network works properly)
@lukasz: since you were the original bug reporter, feel free to close
the bug if it works for you too
after reading the virtualbox forums
especially
https://forums.virtualbox.org/viewtopic.php?f=7=78840#p368748
it is clear that the problem is on the virtualbox side
Virtualbox 5.1 exports cannot be direclty mported in 5.0
Łukasz, I am under the impression that the bug comes from VirtualBox 5.1
from my build environment exporting its OVA under a format which is not
backwards compatible with 5.0
Can you check if updgrading to Virtualbox 5.1 allows you to use the
8.6.0 box without problems ?
Le 27/09/2016 à 17:34, Emmanuel Kasper a écrit :
> On 09/27/2016 04:49 PM, Laurentiu Pancescu wrote:
>> Control: merge 838936 838999
>> thanks
>>
>> Apparently already filed, didn't see that before submitting. Could you
>> please upload fixed images to
On 09/27/2016 04:49 PM, Laurentiu Pancescu wrote:
> Control: merge 838936 838999
> thanks
>
> Apparently already filed, didn't see that before submitting. Could you
> please upload fixed images to Atlas?
I've revoked on Atlas the problematic box.
I plan to upload a fixed box this weeks ( NB:
reported upstream at
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/451#issuecomment-249133463
Package: vagrant-libvirt
Version: 0.0.33-1
Severity: important
Tags: upstream
vmdebootstrap switched to systemd-networkd for newly created images, some time
ago
( could not find a changelog entry for that but it's mentionned in #831025)
switching to systemd-networkd from ifupdown means the OS
ll
window, vagrant will start a background rsync process who watchers via
inotify the changes to your current dir and push them to the vagrant guest
it is only one way sync though
but yes NFS works better becaure of the two way sync
commit e434330d46f473e9bc6f5888c3bb260afb87f887
Author: Emman
Le 16/09/2016 à 10:17, Emmanuel Kasper a écrit :
> Package: cloud.debian.org
> Severity: normal
>
> The libvirt box has problem with the default shared mode (NFS)
>
> A fresh vagrant up from the atlas box brings:
>
> mount -o vers=3,udp
> 192.168.121.1:/home/manu/Pro
inital bug discussion happpened via email, but we prefer to have this in
the BTS, so move the relevant part of the discussions here
> I see three possibility fo fix this:
> A) switch to NFSv4 by default via a Vagrant configuration option
> NFSv4 does not requires the rpc.statd service to run
Package: cloud.debian.org
Severity: normal
The libvirt box has problem with the default shared mode (NFS)
A fresh vagrant up from the atlas box brings:
mount -o vers=3,udp
192.168.121.1:/home/manu/Projects/vagrenvs/jatlavirtdef /vagrant
if command -v /sbin/init && /sbin/init --version | grep
On 07/14/2016 03:04 PM, Felix Dreissig wrote:
> Package: cloud.debian.org
> Severity: normal
> Tags: security
>
> Dear Debian cloud maintainers,
>
> in the "jessie64" Vagrant box (and presumably the other Vagrant boxes as
> well), the insecure Vagrant default SSH key is installed as authorized
Package: kpartx
Version: 0.6.1-3
Severity: normal
Hi
Since the 0.6.1-* version of kpartx, the '-d' option does not work anymore.
Simple test case:
# add loopdevice and partition mappings, freedos.raw is here a disk image
kpartx -av freedos.raw
add map loop0p1 (253:0): 0 262017 linear 7:0 63
#
Package: tar
Version: 1.27.1-2+b1
Severity: important
Tags: patch
When extracting an archive with the --acls flag, tar will create a default ACL
even when the
tarball had none. This results in subtle bugs when restoring a root file
system, as applications who
did not expect having acls are
Le 21/10/2015 09:27, Luca Favatella a écrit :
> Package: cloud.debian.org
> Tags: patch
>
> [Not sure this is the correct way to report this kind of small issues,
> please let me know.]
>
> Running `make stable-test` on master 577ff13 creates debian-jessie.box
> but script expects
> Eye-balling the configuration file for building the jessie image I
> noticed the "d-i mirror/suite string wheezy". It looked strange to me
> so I patched it locally to "jessie" because I thought it made more
> sense and I am filing this ticket hoping it is useful. I am not sure
> this is a
Hi Guruprasad
I had a look at the vagrant-vbguest code, and it looks like it should be
able to install the kernel headers by itself.
Looking at
https://github.com/dotless-de/vagrant-vbguest/blob/master/lib/vagrant-vbguest/installers/debian.rb,
I see:
def dependencies
packages =
Package: debian-maintainers
Severity: normal
Hi
This is my annual ping
Emmanuel
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.1.3-1-pve (SMP w/8 CPU cores)
Locale:
Packer has the following depencies:
It depends on gox which is used as a compilation tool on top of Go:
github.com/mitchellh/gox
For packer itself:
go list -f '{{ join .Deps \n }}' github.com/mitchellh/packer
github.com/hashicorp/atlas-go/archive
github.com/hashicorp/atlas-go/v1
The other point is that including (either) provisioner takes us further
from the standard Debian image.
BTW, Was is actually a standard Debian image ?
To the best of my knowledge, I would define it as all the packages with
Priority: required and important.
According to the Debian Jessie
Ognyan,
Can you please post a a process list of the getty processes you see in
the Amazon hvm ?
I am not aware of all the modifications made to the Debian AWS but
according to http://0pointer.de/blog/projects/serial-console.html:
Two VTs are handled specially by the auto-spawning logic: firstly
The issue is now fixed upstream, see
https://bugzilla.gnome.org/show_bug.cgi?id=748667
Would it be possible to cherry-pick the two commits who resolved the
problem ?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
gnome-video-arcade recommends no packages.
Versions of packages gnome-video-arcade suggests:
pn devhelp none
-- no debconf information
Description: Fix common line arguments of spawned mame process
Author: Emmanuel Kasper emman...@libera.cc
Bug: https://bugzilla.gnome.org/show_bug.cgi?id
hello tanguy
I've just installed the Debian Dokuwiki package and did some research
concerning CVE-2014-8763/CVE-2014-8764
I have read againg the message of the initial upstream reporter of the
issue
1 - 100 of 177 matches
Mail list logo
