This also needs a 1.9 target as well. I just discovered this while
investigating proxy issues on a customer MAAS server and found that they
have an open maas proxy with a ton of external connections to it :/
--
You received this bug notification because you are a member of Ubuntu
Server Team, wh
** Tags added: hwcert-server
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1379567
Title:
maas-proxy is an open proxy with no ACLs; it should add networks
automatically
To manage n
Over a year old, never addressed. Closing.
I think it eventually went away so probably fixed.
** Changed in: chkrootkit (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
http
Old bug
** Changed in: chkrootkit (Ubuntu)
Status: Expired => Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/565578
Title:
chkutmp crashed with SIGSEGV in _Unwind
Maverick is dead. Closing bug properly.
** Changed in: openssh (Ubuntu)
Status: Expired => Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/641657
Title:
SSH connectio
Public bug reported:
Did a general dist-upgrade on saucy. I have TGT installed for some work
with devstack. For some reason, tgt failed to upgrade and that caused
apt to throw an error.
ProblemType: Package
DistroRelease: Ubuntu 13.10
Package: tgt 1:1.0.37-0ubuntu1
ProcVersionSignature: Ubuntu
Why is this still even an issue?
Verified that on the latest Lucid SRU, ipmi_si and ipmi_msghandler load
at boot but ipmi_devintf does not.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/110992
Ok... so further investigation:
Fresh Natty install on an IBM server with BMC using the latest ISOs as
of 8 March.
Looking in /lib/modules/2.6.38-5-generic/kernel/drivers/char/ipmi/ shows that
the drivers are present.
No IPMI packages are installed:
First I install ipmitool:
ubuntu@ubuntu:~$
Also, by "pulling in openipmi" I mean that perhaps the control file for
the ipmitool package could change from suggesting openipmi to
recommending openipmi
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
https://bugs.launchpad.ne
** Changed in: checkbox-certification
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.
https://bugs.launchpad.net/bugs/661591
Title:
checkbox threw an error during a network
Blueprint changed by Jeff Lane:
Whiteboard changed:
Work Items:
- [bladernr] Jeff to list the testing team info so interested parties can sign
up and participate in making this happen: DONE
- Create a list of the tests to be run (a small number of useful tests to
start, we can
Just out of curiosity, this was marked Fix Released on March 19, why is
it now being marked invalid?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/110992
Title:
ipmi modules need to m
Nevermind... I fail at reading comprehension :-) I didn't realize that
the kernel bug was still open.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/110992
Title:
ipmi modules need to
** Tags added: hwcert-server
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1468897
Title:
multipath creates binding for Removable(USB) drives
To manage notifications about
Public bug reported:
I'm investigating lxc-tests and have very little idea what they actually
do. I had hoped to read a man page, or even just pass --help to them to
get some idea of what each is actually doing.
For example, lxc-test-apparmor, I know it does something with apparmor,
but no idea
Public bug reported:
on a default 15.10 installation, I have installed lxc-tests and am
running through them individually.
lxc-test-checkpoint-restore fails to run because the package criu is not
installed
ubuntu@xwing:~$ sudo lxc-test-checkpoint-restore
/usr/bin/lxc-test-checkpoint-restore: 22:
Public bug reported:
I ran lxc-test-checkpoint-restore and it failed. So I decided to try
one additional attempt to verify the failure. However now I am unable
to re-run the test because apparently the container already exists
(previous test did not clean up after itself), however, lxc list does
Public bug reported:
Ran the ste lxc-test-checkpoint-restore and that failed, but there is no
explanation in the output as to why it failed. All the output I was
able to create says it created the container fine, but then just failed
for some reason:
I: Configuring libsemanage1:amd64...
I: Confi
On Fri, May 29, 2015 at 7:32 AM, Mario Splivalo
wrote:
> Hi, Jeff.
>
> Is this still the issue? I just tried deploying maas with ubuntu trusty,
> installing just 'maas' package, which then install everything that was
> needed (incuding maas-dns). The maas version in trusty is 1.5, and I
> had no
Hi,
Not sure this is still an issue, Stephane informed me that those tests
are not meant to be run stand alone and could fail in spectacular ways
when run outside of autopkgtest.
if this is not the case, let me know and when I'm home next week,
I'll dig into this further... otherwise, you can mar
Will this be fixed in the 1.9 release?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1508565
Title:
maas uses 3.13 (hwe-t) kernel which does not work on non-virtual IBM
power
To ma
Removing the blocker tag since this is no longer reproducible.
** Tags removed: blocks-hwcert-server
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1484268
Title:
MAAS not auto-detect
I have seen this issue as well, after being pointed to problems booting
Xen w/ Ubuntu by a colleague.
To recreate this I did the following:
Deployed a server in UEFI mode via MAAS 1.9 using the latest Xenial images from
the MAAS daily image stream.
After deployment, SSH'd to the server and insta
Public bug reported:
Installed a VM with 14.04.3, did a full dist-upgrade and then installed
maas from the Trusty repos.
Since no newer maas has been SRUd yet, 1.7.6 is the only MAAS available
to trusty unless you know about the PPAs. So normal users would end up
with 1.7.6, not 1.9 by default.
Unblocking cert on this since we can now deploy using HWE-V or later via
MAAS
** Tags removed: blocks-hwcert-server
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1508565
Title:
maas
Public bug reported:
Config:
Three MySQL nodes using percona (percona-cluster charm vai juju)
Two Neutron nodes providing network services to an openstack HA deployment (all
done via juju).
Issue:
While testing failover of MySQL, we noticed that we could no longer
create instances of any sort.
Just a follow up, when can we expect to see this resolved in Trusty as
we move users/testers over to MAAS 1.7.1 in Trusty?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to curtin in Ubuntu.
https://bugs.launchpad.net/bugs/1383727
Title:
Other logs (pserv and maas-django) rotate, why not maas.log:
drwxr-xr-x 5 maas maas 4096 Apr 19 07:59 ./
drwxrwxr-x 24 root syslog 4096 Apr 22 07:55 ../
lrwxrwxrwx 1 root root 16 Apr 8 15:01 apache2 -> /var/log/apache2/
-rw-r--r-- 1 maas maas1092531 Apr 22 08:59 m
I'm setting this to High for now... I really think this is critical as
it is gating the PowerNV certification work.
** Changed in: multipath-tools (Ubuntu)
Importance: Undecided => High
** Changed in: curtin (Ubuntu)
Importance: Undecided => High
** Changed in: curtin (Ubuntu)
Importanc
Actually, on advice of Andy C, lets go ahead and consider this
critical... this cert needs to be completed as soon as possible and we
can't do that without multipathing working properly.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to m
Sorry for the vague comment earlier. What I meant was that, from a
certification point of view, I can't certify a system that ships by
default with dual RAID cards in a multipath configuration when
Multipathing in Ubuntu doesn't work. That leads to a scenario where,
out of the box on a fresh inst
Public bug reported:
I have a system with an intel iBMC onboard.
MAAS can successfully create the maas user and add/change the password,
and it also has the correct administrator priviliges.
MAAS also created the user in slot 6, the first available, rather than
choking on slot 4 or 10.
HOWEVER,
I also manually tried using the ipmipower command in addition to
ipmitool:
ubuntu@critical-maas:~$ ipmipower -h 10.0.0.125 -u maas -p TRRnqoEl9ccQy7 --off
10.0.0.125: ok
ubuntu@critical-maas:~$ ipmipower -h 10.0.0.125 -u maas -p TRRnqoEl9ccQy7
--on-if-off --cycle
10.0.0.125: ok
both of these com
Since apport didn't gather any maas logs, here they are...
** Attachment added: "maas-logs.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1294332/+attachment/4031166/+files/maas-logs.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Server Team, whi
Public bug reported:
New to the power management part of node info is this text:
"MAC address - the IP is looked up with ARP and is used if IP address is
empty. This is better when the BMC uses DHCP."
What is better when the BMC uses DHCP? Does using DHCP make using ARP
better? or more accurat
Public bug reported:
by default, there's no way for a node started by maas to talk to the
internet. There is also no way on the maas dashboard that I can see
that allows me to control this sort of network behaviour either.
For now, we are using a shell script to start NAT rules in iptables so
t
Public bug reported:
I have a NUC with the current version of 14.04 and MAAS installed on it.
Today, I completely removed the contents of boot-resources and re-
imported the various boot/image files to remove old daily images and
older versions I didn't need.
If you look at the current image str
I went through and deleted the rc directory from *current, and also
deleted the individual images themselves (had to compare inode numbers
in rc/ to the images in cache and deleted the images individually by
inode.
Then I did an install and it installed the correct image by default:
ubuntu@superm
So it would seem to confirm that MAAS is choosing the older 20140410
images over the 20140416.1 images when installing.
This is my bootresources.yaml: (The only changes I made were commenting
out older versions I didn't want to pull down)
ubuntu@critical-maas:/var/lib/maas/boot-resources$ cat
/e
Julian: THAT makes more sense... perhaps this would be less confusing,
from a user standpoint:
MAC Address - Enter the BMC's MAC Address here if you are NOT using DHCP
to assign BMC IP Addresses
** Changed in: maas
Status: Incomplete => New
--
You received this bug notification because
Hi Julian,
I've got several MAAS servers that seem to suffer the same fate,
depending on what your definition of "Access the internet" is.
We first saw this at the Orange Box sprint in london where nodes could
be deployed via d-i which was pulling packages from MAAS's squid-deb-
proxy, IIRC, howe
Then again, perhaps something as simple as a 'maas-enable-nat' command
for these simple cases would be sufficient so new users don't have to
also understand iptables... and makes it optional on the maas server so
you can or can not enable it... maybe it is a per-cluster-controller
thing, as my und
As for your question about the region... I don't know... that's
operating at scale. The question there is probably one of hierarchy...
for example, would you have multiple, linked region controllers, or more
like a few region controllers and several cluster controllers under
each?
And in that cas
Yeah, that could work.
** Changed in: maas
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304518
Title:
Confusing wording in the IPMI section o
Public bug reported:
Maverick with latest updates as of 17 Sept 2010
I've noticed since upgrading from 10.04.1 to Maverick that SSH sessions
now seem to freeze after a period of time.
I am able to ssh to a remote server (I'm sshing to my personal server
and to some work servers in one of the DCs
** Attachment added: "Dependencies.txt"
https://bugs.launchpad.net/bugs/641657/+attachment/1599958/+files/Dependencies.txt
--
SSH connections freeze after a period of time
https://bugs.launchpad.net/bugs/641657
You received this bug notification because you are a member of Ubuntu
Server Team
Hi Steve,
Actually, I'm seeing it on any remote SSH connection (either to a
Canonical DC or to my own shared server).
I'm in Taipei at the moment so I'll try again here just to see if
there's something wonky on my end (router, or switch maybe) causing the
SSH connection do hang...
As for the res
Undecided
Assignee: Jeff Lane (bladernr)
Status: New
** Affects: ntp (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug checkbox-bug maverick
--
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You receive
** Also affects: checkbox-certification
Importance: Undecided
Status: New
** Changed in: checkbox-certification
Assignee: (unassigned) => Jeff Lane (bladernr)
--
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this
** Changed in: ntp (Ubuntu)
Status: New => Incomplete
** Changed in: ntp (Ubuntu)
Status: Incomplete => Opinion
** Changed in: ntp (Ubuntu)
Status: Opinion => Invalid
--
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this b
** Changed in: checkbox-certification
Importance: Undecided => High
--
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.
--
Ubuntu-serve
Job description was incorrectly calling network_ntp_test script. Fixed
that.
** Changed in: checkbox-certification
Status: New => Fix Committed
--
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a mem
Public bug reported:
Walked away for a while and returned to find my system almost unusable.
Something was causing the DISK I/O to go through the roof, the system
constantly waiting, making it, as I said, almost unusable.
On some investigation, top indicated that egrep was consuming 6.7 GB of
act
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437
Title:
chkrootkit cron job went nuts, spawned 14 instances and consumed
nearly 90% of my ram
To manage notifications about
This is a batch mode output from top, showing the egrep process
consuming 6.7GB of my RAM...
** Attachment added: "top.log"
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+attachment/2287476/+files/top.log
--
You received this bug notification because you are a member of Ub
this is a capture of ps axf before rebooting the system to make it
usable again. Notice the 14 instances of egrep spawned by chkrootkit.
** Attachment added: "ps-axf.log"
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+attachment/2287477/+files/ps-axf.log
--
You received
Also, this might actually be an issue created by tiger, rather than
chkrootkit itself...
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437
Title:
chkrootkit cron job went nut
Serge: at the moment, no. I can't manually reproduce it. However, I
left the machine sitting over night and came back this morning to find
that it was stuck yet again, this time, the egrep process was using
7.1GB of 8GB, but PS only showed 2 instances running...
I'm currently running tiger manual
forgot to reset to new when I added my update.
** Changed in: chkrootkit (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437
Title:
c
* Stopping target framework daemon tgtd ESC[80G
^MESC[74G[ESC[31mfailESC[39;49m]
invoke-rc.d: initscript tgt, action "stop" failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
* Stopping target framework
Public bug reported:
Installed maas packages on a fresh trusty install like so:
$ sudo apt-get install maas maas-region-controller maas-cluster-
controller maas-dhcp maas-dns
Installation proceeded successfully until maas-dns. maas-dns errored
out:
Setting up maas (1.4+bzr1789+dfsg-0ubuntu1) .
Looked into syslog when manually restarting bind9 and it seems to hang on the
maas zone file:
Jan 7 11:28:16 critical-maas named[29464]: starting BIND
9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu2 -u bind
Jan 7 11:28:16 critical-maas named[29464]: built with '--prefix=/usr'
'--mand
Public bug reported:
My setup:
Trusty on an IBM Thinkpad x201.
Onboard Gigabit is static on 10.0.0.0 (The private MAAS lan)
Internet connectivity is via an 802.11n WiFi dongle
My internet connection is a 10Mbit ADSL line
I have installed and configured maas. The next step, per the
instructions h
https://bugs.launchpad.net/maas/+bug/1035998/comments/2
Reading that comment, it suggests that the named.conf.maas file should
be empty by design so I created one like so:
sudo touch /etc/named/maas/named.conf.maas
and restarted bind and apache.
Then, I deleted my node and retried and it su
Public bug reported:
Following the docs, I did the following on a system running the latest
Trusty image with the latest MAAS packages for trusty:
$ maas-cli maas node-groups import-boot-images
On Saucy or earlier (and I believe on earlier versions of Trusty), this
would launch the olders script
Public bug reported:
Using latest trusty bits I manually created a node in the MAAS UI. On
setting the node, MAAS successfully powered the node on via IPMI. The
node booted and got an IP address but then failed to PXE due to PXE
timeout errors. While all this is going on, each retry prompted a
Public bug reported:
I have connected a Cisco UCS C220 M3 system to my MAAS server.
I have tried and succeeded in enlisting the server both automatically by
powering the server on manually, and via the UI by feeding maas the
server CIMC information and have MAAS automatically power the server on
Public bug reported:
On my MAAS box running trusty:
In the MAAS UI, we created a node entry for a server, choosing IPMI and
passing the login credentials, IP for the BMC and the MAC address. On
saving the node, MAAS issued the IPMI command to turn the server on.
The server successfully powered
Yep, that was the workaround I used.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1268795
Title:
unable to automatically commission Cisco UCS server due to BMC user
permissions
To
Public bug reported:
I had three servers connected to my MAAS server. All three were
successfully enlisted, commissioned and in the "Ready" state.
I did a juju bootstrap which grabbed one server, powered it on and
installed and completed Juju's bootstrap bringup. This was confirmed by
running j
FWIW, this does not seem to be universal to UEFI systems. I've
performed enlistment and commissioning on several IBM systems in full
UEFI mode that behaved just fine (and a couple new density systems that
showed the same sort of issue Narninder mentions here).
--
You received this bug notificati
Additionally, do we not also use juju, region and cluster on the same
NUC inside the Orange Box? So it seems like it would be important from
the OB perspective to fix this as well. Just an additional use case.
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Hrmmm... it just bit me while trying to test out the checkbox charm on
bare metal from my private maas server. and it's not just a matter of
juju.
for example, MAAS is successfully updating the zone files:
npdxh IN CNAME 10-0-0-123
and I can't ssh to my node by hostname:
ubuntu@critical-maas:/e
Maybe I misunderstand the "region controller" concept or my
understanding of the MAAS ecosystem is outdated.
AIUI there is a "region controller" that communicates with multiple
"cluster controllers" that further manage multiple "nodes":
/-- cluster foo -> node1.foo, node2.foo, node
Just adding more griping :) would be nice to see this fixed in Trusty
sometime before next February
bladernr@klaatu:~$ ftp transit
Connected to transit.lanes.
220 (vsFTPd 3.0.2)
Name (transit:bladernr): bladernr
331 Please specify the password.
Password:
no talloc stackframe at ../source3/param/lo
So this bit us again when trying to deploy LDS. The process there is:
Install/configure MAAs
Populate MAAS
on MAAS, install juju
Juju bootstrap
juju-deployer install LDS
then go to LDS and it does more stuff.
In this case it really caused pain in several cases where juju would say
bootstrap fail
76 matches
Mail list logo