Bug#1086338: ipmitool: "lan6" subcommand is not documented

[Andy Smith]

Package: ipmitool
Version: 1.8.19-4+deb12u1
Severity: minor

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I tried to get IPv6 details out of "ipmitool lan print"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I typed "ipmitool lan print" and saw only IPv4 information despite
knowing that IPv6 addresses were set. I read the man page for how to
retrieve these details and found nothing.

I searched the web and found that since v1.8.18 (2016) there has been a
"lan6" sub-command which gives this information. I tried "ipmitool lan6
print" and this worked. I have no idea what else "lan6" can do as it is
undocumented.

   * What was the outcome of this action?

I was able to get the information I needed with an undocumented command.

   * What outcome did you expect instead?

For documentation of "lan6" to appeat in the mean page after that for
"lan".

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-26-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ipmitool depends on:
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u8
ii  libfreeipmi17  1.6.10-1+b1
ii  libreadline8   8.2-1.3
ii  libssl33.0.14-1~deb12u2
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages ipmitool recommends:
ii  openipmi  2.0.33-1+b1

ipmitool suggests no packages.

-- no debconf information

Bug#958311: cloud kernel 5.5.0-2 does not boot under xen

[Andy Smith]

Hi Samuel,

On Thu, Feb 16, 2023 at 03:59:09PM +0100, Samuel Thibault wrote:
> Andy Smith, le jeu. 09 juin 2022 15:32:38 +, a ecrit:
> > If you're using pvgrub2 to boot PV mode then the bad news is that it
> > seems to be largely abandoned as nobody wants to alter it to support
> > different kernel compression methods.
> 
> Uh... I wonder how it is that it's not just orthogonal to whether
> booting in native/PV/PVH...

It's because:

- "native" booting is the xen hypervisor itself booting your Debian
  kernel from out of its own filesystem, so the hypervisor needs to
  understand all kernel compression methods and historically it has
  lagged behind upstream kernel compression types. Grub is not
  involved here.

- PV grub and PVH grub are both grub binaries that are booted by the
  hypervisor, so the hypervisor just needs to know how to boot that
  grub image, which is (a) a slower-moving target and (b) something
  that admin of the bare metal host can recompile easily without
  interfering with guests.

  HOWEVER

  - The PV part of grub is quite old and from what I understand
implemented in a strange way that no one wants to maintain any
more, so this part of grub is stuck without ability to
understand the newer kernel compressions.

  - The PVH part of grub is more modern and uses grub's own
facilities for loading the kernel file, so as long as grub
understands a compression for normal Linux, it works with the
PVH part of grub too, which is obviously a lot more
maintainable.

So in summary:

For Xen there's two different places for implementing the
understanding of loading a Linux kernel, that being the hypervisor
or the grub bootloader. The hypervisor is slower upstream to support
new kernel compressions so there has been times when for example
Ubuntu or Fedora has by default been unbootable directly without
getting a pre-release version of Xen hypervisor (or un/repacking
the guest kernel compression).

The grub method is preferred so that guests can manage their own
kernels, and that has two different code paths in grub depending
upon PV mode or PVH mode. The PV mode part doesn't seem to be
maintained. The PVH part uses more of core grub functionality so is
easier to maintain.

I would recommend defaulting to PVH mode for guests these days,
unless you are doing HVM. There are still people who want to use
old kernels that don't support PVH mode, though. I don't think any of
those old kernels are supported by Debian at this stage, but still…

Cheers,
Andy

Bug#997666: flufl.bounce: please update to 4.0

[Andy Smith]

Hi Pierre-Elliott,

On Thu, Jan 27, 2022 at 11:25:39PM +0100, Pierre-Elliott Bécue wrote:
> I've not put a close statement in my upload because I wanted to make
> sure that you are aware that uploading 4.0 in stable is probably not an
> option.
> 
> Would you like me to backport this package?

I experienced this problem myself the last few months with mailman3
on bullseye. Regrettably I bothered mailman3 upstream about it and
they told me the same; that it was this known problem in
python3-flufl.bounce. I should've checked here first. 🙁

Anyway, I see this is fixed in 4.0-2 that is in testing but I don't
know the best way to have it fixed in bullseye. Should I just
install the package from testing since we are so close to the freeze
(I tested and this does work)?

Otherwise, a fixed package in bullseye-backports would be good.

Upstream patch that fixes this:

https://gitlab.com/warsaw/flufl.bounce/-/merge_requests/19

https://gitlab.com/warsaw/flufl.bounce/-/commit/ad700469c502f145ebfb4b62d8e23cd588fbf619

Thanks,
Andy

Bug#1020787: [Pkg-xen-devel] Bug#1020787: linux-image-5.19.0-2-amd64: After updating to 5.19 kernel the VMs are started without XSAVE CPU flags

[Andy Smith]

Hi,

On Tue, Sep 27, 2022 at 01:59:42PM +0200, Diederik de Haas wrote:
> http://xenbits.xen.org/gitweb/?
> p=xen.git;a=commit;h=c3bd0b83ea5b7c0da6542687436042eeea1e7909 is where it's 
> committed in Xen's master branch. I haven't seen a backport to 4.16 (yet?)

Does this mean that all versions of hypervisor need this patch
backported in order to support Linux kernel 5.19+ as dom0 or domU?

Cheers,
Andy

Bug#939170: "Discrete TPM" seems to have fixed it for me too

[Andy Smith]

I just installed Debian 11 on a 4th gen Thinkpad X1 Carbon and it
failed to resume from suspend. This was working in Debian 10.

Setting the "TPM Mode" to "Discrete TPM" as mentioned by Uwe
Steinmann also appears to have fixed things for me.

Thanks,
Andy

Bug#1014037: mailman3-web: Possible memory leak: uwsgi OOMs after a few weeks

[Andy Smith]

Hi,

I'm pretty sure I'm seeing this too. I'm running it under apache2
and with mariadb.

After a week or so uwsgi was using about 7% RAM on an 8G machine. I
restarted mailman3-web and that went back to 1%. One day later it is
up to 1.2%; I guess it will keep growing and I will also have to
regularly restart mailman3-web.

Is it easy to switch the mailman3-web package to run under
gunicorn?

Cheers,
Andy

Bug#958311: cloud kernel 5.5.0-2 does not boot under xen

[Andy Smith]

Hi,

On Thu, Jun 09, 2022 at 02:00:30PM +0300, Aleksi Suhonen wrote:
> The underlying problem is that the cloud kernel is compressed with an
> algorithm that grub can't uncompress. What I've been doing as a workaround
> is that I decompress the kernel myself in a kernel install hook.

Can you show us your xen domu config file? I'm interested in what
method you are using to boot these.

If you're using pvgrub2 to boot PV mode then the bad news is that it
seems to be largely abandoned as nobody wants to alter it to support
different kernel compression methods.

The good news is that you should be able to easily switch to PVH
mode with pvhgrub which uses grub's core routines to decompress the
kernel and therefore supports whatever compression methods that grub
normally does.

Cheers,
Andy

Bug#1001714: update 1

[Andy Smith]

Hi Detlev,

On Thu, Dec 16, 2021 at 09:05:07AM +0100, detlev schmidtke wrote:
> I read in the Debian Wiki
> (https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition): 
> 
> "But for software RAID systems there is currently no support for
> putting the ESP on two separate disks in RAID."
> 
> I interpret that as "it cannot work", so, the Debian Installer should
> refuse to install EFI on a Software RAID with an appropriate message,
> instead of running into this error.

It's a bit more complicated than that.

By default, md uses version 1.2 superblock which lives near the start
of the device. Software with no concept of md RAID will read a
member device and see an MD superblock at the start instead of the
filesystem format they expect. So, this will not work and I would
tend to agree that the installer should not allow a device with such
a superblock to be used as an ESP.

Metadata versions 0.9 and 1.0 can instead be used; these have the
data near the end of the device. As a consequence, the beginning of
RAID-1 member devices are indistinguishable from the below
filesystem being directly on the device. This trick was used to get
grub to boot RAID-1 before it had support for md RAID: grub couldn't
tell that it wasn't just reading a normal filesystem.

An MD RAID-1 array with superblock version 0.9 or 1.0 will very
likely work as an ESP and many people do this. The installer should
probably not prohibit it.

This strategy can still fail. It relies upon nothing except the OS
itself writing to that member device. I have not seen it but some
people say that there are firmwares and bootloaders that will write
to the ESP. Since they would not be aware of md, they would change
one member device and not another. When you booted with such a setup
MD would complain and not assemble the array. You'd have to choose
which member device "won" and have the other overwrite it.

Due to that, some people instead have multiple ESPs and come up with
elaborate schemes to sync them in user space.

That was the state of things when I last asked on debian-user in
November 2020:

https://lists.debian.org/debian-user/2020/11/msg00455.html

Here's a script I use to sync ESPs:

https://gist.github.com/grifferz/f262591f59e4f8c199a8b0619bc6a667

But again, I don't think it's a good idea to ban ESP on MD array as
this is a working configuration for many.

Cheers,
Andy

Bug#995397: Dropped support for 32-bit Xen PV guests should be mentioned in i386 release notes

[Andy Smith]

Hi Paul,

On Thu, Sep 30, 2021 at 10:21:42PM +0200, Paul Gevers wrote:
> This indeed sounds like something that could be mentioned under the
> "issues to be aware of" section. A proposal text would help the process
> forward.

Thanks. I am not sure whether it fits in "Items not limited to the
upgrade process" or under "Obsolescence and deprecation", but how
about:

The Linux kernel no longer provides support for 32-bit Xen
guests in PV mode.

Users of 32-bit Xen guests should check that they are running in
either PVH or HVM mode before upgrading to bullseye, since as of
v5.9 the Linux kernel will not boot as a 32-bit Xen PV mode
guest.

You can check which type of Xen guest you are running as
follows:


$ cat /sys/hypervisor/guest_type
PV


If you see PVH or HVM here then you should be safe
to upgrade to bullseye.

If it is a requirement to continue using PV mode, the least
disruptive option may be to https://wiki.debian.org/CrossGrading";>switch to an amd64
(64-bit) kernel. It is not necessary to cross-grade the
entire system to amd64.

Not sure if the last paragraph is appropriate as I'm not sure if
cross-grading like that is considered supported, even though I
suppose multiarch is considered supported, so why not?

Anyway, all of this is only for the i386 release notes as amd64
support has not been dropped.

Thanks!
Andy

Bug#995397: Dropped support for 32-bit Xen PV guests should be mentioned in i386 release notes

[Andy Smith]

Package: release-notes

As of Linux kernel version 5.9, support for 32-bit Xen guests
running in PV mode was dropped:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a13f2ef168cb2a033a284eb841bcc481ffbc90cf

Since bullseye comes with a 5.10 kernel, a 32-bit Xen PV guest may
be running fine under buster, do a dist-upgrade to bullseye which
completes without issue and then on reboot the kernel can't be
booted.

This has just happened to two of my customers, once last night and
once this morning, despite many years of us advising customers to
switch to 64-bit and/or PVH mode.

These 32-bit Xen guests can continue to run as 32-bit if they are
run as PVH mode guests instead, or they can continue to run as
64-bit PV mode guests (with 32-bit userland) if the guest admin
installs the amd64 kernel as per:

https://wiki.debian.org/CrossGrading

I think this issue should be mentioned in the i386 release notes in
the upgrading from buster part. I am happy to propose some text for
that if it is agreed.

Thanks,
Andy

Bug#994870: [Pkg-xen-devel] Bug#994870: Bug#994870: Bug#994870: Memory allocation problem for VM after xen security update

[Andy Smith]

Hi Alex,

On Thu, Sep 30, 2021 at 12:10:32AM +0200, Alexander Dahl wrote:
> Am 22.09.21 um 20:54 schrieb Hans van Kranenburg:
> > At this point I would really recommend to not wait for a fix to arrive
> > which makes it start again, but change your VM to use a 64-bit kernel.
> 
> How?

This was answered in earlier comments on this bug; please see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994870#15
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994870#20

The brief summary is, "start out like a crossgrade, but only do the
kernel". Very simple and quite safe.

You haven't said how you boot your guest though (show us your
/etc/xen/guest.cfg file). If it's pvgrub, that has a 32-bit and a
64-bit version so you'll need to change those as well. If it's
pygrub you probably don't need to do anything, though pygrub has its
own issues outside the scope of this bug.

> FWIW, Debian 10 VMs with 32 bit running with PVH work fine. My important VM
> is still Debian 9 however due to a software I can not simply upgrade.

I've found PVH needs at least 4.19 guest kernel to work, which can
be achieved in Debian 9 (stretch) today by using kernel from
stretch-backports, so perhaps that is an option for you.

Cheers,
Andy

Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Andy Smith]

Hi Diederik,

On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote:
> On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote:
> > We agree about reverse order, I think we only disagree about when to
> > shut down domains that don't have a preference set. 
> 
> Indeed.

Okay, well I am satisfied by the lesser idea of having to specify
order of all domains but if the implementer of the solution isn't
and decides to implement it so not-specified domains shut down first
then that works for me too so have no objection to it.

The idea of the domid controlling/influencing order of shutdown
would not work for me as to me that is not much different to how we
have things now - domains shut down in increasing order of domid. I
can't control it so I just would continue using my own shutdown
script.

> I really agree with the 'upstream' tag as not only should it be 
> fixed/adjusted 
> there, but it also engages a (much) larger audience who think of scenarios we 
> likely didn't think about.

Should we move discussion to xen-us...@lists.xen.org then?

Cheers,
Andy

Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Andy Smith]

Hi Diederik,

On Tue, Sep 28, 2021 at 11:45:08AM +0200, Diederik de Haas wrote:
> On Monday, 27 September 2021 19:13:04 CEST Andy Smith wrote:
> > I think the "auto" directory is a pretty good and simple interface,
> > so how about using it for save/shutdown as well? So, instead of just
> > enumerating all running domids, enumerate all files in
> > /etc/xen/auto/ in REVERSE order, parsing the name of the domain out
> > of each one and doing the action on that name. When all files have
> > been exhausted, THEN do the action on any remaining running domains.
> 
> I'm not familiar with the "auto" directory('s functionality), but I _assume_ 
> that it's a directory which contains Xen domain config files which are 
> automatically started up at boot time (in alphabetical sequence).
> The user can choose to start other VMs if (s)he so chooses.

Yes; you typically symlink for example /etc/xen/foo.cfg to
/etc/xen/auto/100-foo.cfg so as to enforce some order of automatic startup.

Currently shutdown just goes in order of running domain id though.

> If that's correct, then I find it more logical to do *everything* in reverse.
> The VM that was started first, should be saved/shutdown last and IIUC your 
> proposal would not do that.

No, that's what I am suggesting too: again walk the "auto" directory
but in reverse order.

> Once all the "remaining" ones have been saved/shutdown, THEN do
> the auto ones in reverse order.

A problem here would be excluding the domains that have a specified
order from the initial round of shutdowns, which is why I suggested
doing it in reverse order by the "auto" directory and THEN shutting
down anything that's left as normal, since that way you don't need
to check anything.

As you've pointed out, this does mean that if you had linked say
/etc/xen/auto/010-important.cfg with the intention that it be
started first and shut down last, you would have to also link in
every other domain in its correct order otherwise the not-mentioned
ones would be shut down after 010-important.

However, I feel like people who use the /etc/xen/auto directory do
already link all or the majority of their domains in there - I
certainly do. I don't find it onerous to say that if you want to
specify shutdown order then you must link all of the domains in
/etc/xen/auto not just some of them.

Otherwise, if you wanted to say that all non-mentioned domains must
be shutdown first then I guess you'd have to parse the list of
domain names from the "suto" directory first, then get the list of
running domains from /usr/lib/xen-common/bin/xen-init-list and
exclude one from the other for the initial round of shutdowns.

> Could the domain ID be used for that?

I don't like it because it only says how recent a domain was
started relative to others, not any intention about start/stop
order. Shut one down manually (or crash) and start it again and it
gets a new domid higher than all existing.

> But my main point is that I think the proposed sequence should be adjusted.

We agree about reverse order, I think we only disagree about when to
shut down domains that don't have a preference set. I am all for
keeping it simple by saying ordering must be set for all domains
otherwise ordering for remaining ones is not defined.

Cheers,
Andy

Bug#452721: [Pkg-xen-devel] Bug#452721: #452721 moreinfo?

[Andy Smith]

Hi Elliott,

On Sun, Sep 26, 2021 at 08:07:58PM -0700, Elliott Mitchell wrote:
> During a full downtime when all VMs were fully shut down, this effect
> can be achieved by including numbers in the filename.  Say
> /etc/xen/auto/0_ldap.cfg, /etc/xen/auto/1_fileserver.cfg,
> /etc/xen/auto/9_everything_else.cfg.

I also do this to control start up order, though I use a prefix of
NNN-.

The main missing functionality from my point of view is not being
able to control the order of save/shutdown. As you say the script
for saving everything or shutting everything down just does a read
of all existing domids and does the action on them one by one in
increasing order.

I think the "auto" directory is a pretty good and simple interface,
so how about using it for save/shutdown as well? So, instead of just
enumerating all running domids, enumerate all files in
/etc/xen/auto/ in REVERSE order, parsing the name of the domain out
of each one and doing the action on that name. When all files have
been exhausted, THEN do the action on any remaining running domains.

This has the advantages of:

- still working even if administrator does not use ordering in
  /etc/xen/auto. Filename format there does not change from what it
  is now, where ordering is already possible but is optional.

- being quite obvious behaviour - save/shutdown order is reverse of
  start order.

That seems like a good minimal improvement, but if one wanted to
explicitly control save/shutdown order then perhaps the next
enhancement could be an /etc/xen/shutdown/ directory with similar
purpose to the "auto" one? i.e.:

1. Enumerate files in "shutdown" directory in reverse order, getting
   name from each and doing shutdown action on it

2. If there were no files there, instead use "auto" directory for
   this purpose

3. Then do shutdown action on every remaining running domain as
   usual

Again this still results in everything getting a shutdown action if
administrator does not want to do any of this.

It's an open question for me whether step 2 (falling back to
enumerating "auto" directory) only happens when "shutdown" directory
is empty or if it should happen all of the time.

If you had a dom0 with 100 domains on it but only wanted to control
the order of a few of them, without fallback you would need to copy
ALL the links from auto to shutdown and then change their ordering
because otherwise this would shut down the ones you specified and
then do all the rest in domid order like it does right now.

WITH fallback, you'd get the few you wanted to control done in the
order you expect and then you'd get the order from "auto", which is
appealing but does mean it's going to try to shut down again some
that are already shut down. If there is a relatively quick "is a
domain by this name still running?" check then maybe that's
workable.

> If the hypervisor is rebooted and VMs are saved to /var/lib/xen/save;
> they will be paused in identifier order, but saved by domain name.  When
> scanning /var/lib/xen/save, `xendomains` goes by filename which means VMs
> are restored in a distinct (and often problematic) order.
> 
> A minimal solution would be for `xendomains` to save VMs in
> /var/lib/xen/save - and then use `sort -n` during restore.

If by this you mean it would be good if the "save all" action picked
the filename from the filename in the "auto" directory, to replicate
that directory's ordering, then I agree.

If however you mean the actual Xen domid of the running domain then
I'm not sure what that would buy us. If I had a domain with a
filename of 010-ldap0.cfg it might get strted first and have domid
1, but then I reboot it and it has domid 99, I wouldn't want it
saved as /var/lib/xen/save/99-ladp0, I'd still want it saved as
/var/lib/xen/save/010-ladp0,

> A better approach would be to have a LSB style header specifying
> dependencies to flag VMs which should be saved or shutdown late,
> and VMs which should be saved or shutdown early.
> 
> A ridiculous overkill solution might be to turn the /etc/xen/*.cfg
> files into full init scripts.

I don't think that we should be proposing to change the config
language of upstream Xen or diverge from how domains are usually
configured with upstream Xen. I think that we can get a lot of
improvement without modifying the format of the config files and
only by changing how the start and shutdown scripts work.

At the moment domain start and shutdown is serial in nature and can
take a long time. I don't know if there is any scope for improving
that in scripts, or whether it's an upstream conversation, either
way not for this bug. But because of the lengthy process I do have
an interest in starting my important domains first and shutting them
down last.

Presently I am handling this by numbering the links in the auto
directory, and using my own script that saves or shuts things down
in the order I want.

I can see how this could be improved but I'm not sure it's worth
spending a large amount of effort on it and

Bug#994870: [Pkg-xen-devel] Bug#994870: Memory allocation problem for VM after xen security update

[Andy Smith]

Hello,

On Fri, Sep 24, 2021 at 03:33:21PM +0200, Hans van Kranenburg wrote:
> The smallest amount of work to initially get your VM going again is to
> only install the 64 bit kernel and keep running a 32 bit user land.

Yep, I have a few 32-bit PV domUs that I run as 64-bit just the
kernel, works great.

> The process to fully change from a 32 to 64 system (in place) is called
> 'cross grading'. I found instructions at
> https://wiki.debian.org/CrossGrading
> 
> I never did this myself, though.

I've done it lots of times but for any non-trivial host you have to
pretty much be a Debian expert to know how to handle the many
problems that dpkg will encounter. It takes longer than
reinstalling and a mistake breaks everything. Not recommended.

> It should be as simple as changing type="pv" to type="pvh" in the config
> file. In Debian, using PVH this is possible since Buster. Also, using
> the xen variant of grub2 (grub-xen and grub-xen-host) is possible.

I can confirm that I have a lot of Debian stretch domUs running PVH
but you do need to install backports kernel in the domU. The 4.9.x
stretch kernelis too old. You need the 4.19.x one from
stretch-backports. They boot fine for me with pvhgrub.

Cheers,
Andy

Bug#950324: question

[Andy Smith]

Hello,

On Mon, Aug 16, 2021 at 01:49:24PM +, Claessen, V.I. (Victor) wrote:
> Would it be an option to compress the kernel with a stronger compression 
> algorithm, like xz?

Debian has to pick the kernel compression type that works best for
the majority of users, bearing in mind that some machine types are
particularly sensitive to how much memory is required to decompress.
If you want to change it I think you'll need to build your own
kernels.

When it comes to the initramfs however, you can choose compression:

# echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
# update-initramfs -u

Cheers,
Andy

Bug#989656: [Pkg-xen-devel] Bug#989656: Bug#989656: Xen misusing syslog

[Andy Smith]

Hello,

On Fri, Aug 06, 2021 at 12:04:07AM +0200, Hans van Kranenburg wrote:
> On 6/9/21 5:04 PM, Phillip Susi wrote:
> > My syslog has entries that look like this:
> > 
> > Jun 09 10:54:26 hyper1 root[621]: /etc/xen/scripts/block: add
> > XENBUS_PATH=backend/vbd/1/768
> > 
> > The third field is supposed to be the program name, which I would expect
> > to either be xen or xl or something, but instead it appears to be
> > passing $USER.
> 
> Yeah, that's a bit weird yes.

I think it's a consequence of using logger(1) for logging. If you
don't use --tag then:

   -t, --tag tag
 Mark every line to be logged with the specified
 tag.  The default tag is the name of the user
 logged in on the terminal (or a user name based
 on effective user ID).

But yeah, one for upstream.

Cheers,
Andy

Bug#990717: [Pkg-xen-devel] Bug#990717: xen-system-amd64: Microcode isn't loaded when booting in xen mode

[Andy Smith]

Hello,

On Mon, Jul 05, 2021 at 03:13:17PM +0200, José L. Fernández Jambrina wrote:
> When booting in Xen mode my system doen't load microcode,

It is my understanding that when booting the hypervisor it is the
hypervisor's job to load microcode, and it won't do so unless you
have something like:

ucode=scan

in your hypervisor command line, e.g. by putting:

GRUB_CMDLINE_XEN="ucode=scan"

in /etc/default/grub.

Do you have something like that?

That will cause the hypervisor to scan the other boot files (kernel
and initramfs) for microcode to apply, like the kernel itself would
otherwise do.

It works for me, anyway.

Cheers,
Andy

Bug#975417: Fails to parse /sys/dev/block links for NVMe devices, fixed upstream

[Andy Smith]

Hi Steve,

On Sun, Nov 22, 2020 at 12:20:06AM +, Steve McIntyre wrote:
> Could I ask you to please try the package versions from
> 
>   https://people.debian.org/~93sam/efivar/
> 
> and confirm that they're good for you?

Yes, that works.

# grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
grub-install: warning: efivarfs_get_variable: 
open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b): No 
such file or directory.
grub-install: warning: efi_get_variable: ops->get_variable failed: No such file 
or directory.
grub-install: warning: device_get: readlink of /sys/block/(null)/device failed: 
No such file or directory.
grub-install: warning: open_disk: could not open disk: No such file or 
directory.
grub-install: warning: efi_va_generate_file_device_path_from_esp: could not 
open disk: No such file or directory.
grub-install: warning: efi_generate_file_device_path_from_esp: could not 
generate File DP from ESP: No such file or directory.
grub-install: error: failed to register the EFI boot entry: No such file or 
directory.
# wget 
https://people.debian.org/~93sam/efivar/libefiboot1_37-2+deb10u1_amd64.deb
# apt install ./libefiboot1_37-2+deb10u1_amd64.deb
# grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
Installation finished. No error reported.
# efibootmgr -v
BootCurrent: 000B
Timeout: 5 seconds
BootOrder: 000B,000C,0009,000A,0003
Boot0003* UEFI: Built-in EFI Shell  
VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot0009* (B1/D0/F0) UEFI: PXE IPv4 Intel(R) I350 Gigabit Network 
Connection(MAC:3cecef2221e8)  
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(3cecef2221e8,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot000A* (B1/D0/F1) UEFI: PXE IPv4 Intel(R) I350 Gigabit Network 
Connection(MAC:3cecef2221e9)  
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(3cecef2221e9,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot000B* debian
HD(1,GPT,684729d1-2765-4651-9376-909a41d833e0,0x800,0x106000)/File(\EFI\debian\shimx64.efi)

(libefiboot1 update is enough for me, but I did check that it still
works with your libefivar1 installed as well. Out of your updated
packages I only have libefiboot1 and libefivar1.)

Cheers,
Andy

Bug#975417: Fails to parse /sys/dev/block links for NVMe devices, fixed upstream

[Andy Smith]

Package: libefiboot1
Version: 37-2
Severity: important

Dear Maintainer,

libefiboot in stable and testing fails to parse symlinks such as:

/sys/dev/block/259:1 -> 
../../devices/virtual/nvme-subsystem/nvme-subsys0/nvme0n1

which prevents tools such as grub-install and efibootmgr from working on
my system that has only NVMe drives, thus also preventing a successful
install of buster at the "install bootloader" stage of d-i.

The problem is fixed upstream here:

https://github.com/rhboot/efivar/pull/139

and that fix is already present in the version of libefiboot1 from
unstable (37-6). I have verified this by forcibly installing the .deb
from unstable on a buster system; this allows tools such as grub-install
and efibootmgr to work successfully.

Please can this fix be backported to buster so that an install is
possible?

Thanks,
Andy

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-11-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libefiboot1 depends on:
ii  libc6   2.28-10
ii  libefivar1  37-2

libefiboot1 recommends no packages.

libefiboot1 suggests no packages.

-- no debconf information

Bug#968921: ITP: dotnet-core-3.1 -- Microsoft .NET Core SDK 3.0.100

[Andy Smith]

Hello,

On Sun, Aug 23, 2020 at 06:06:10PM -0500, Alistair Young wrote:
> As Microsoft themselves point out, packaging this for main is
> useful because it lowers the barrier to use of .NET Core to one
> equivalent to other in-distro languages without requiring the
> use of third-party repositories, especially when the runtime is
> needed as a dependency of another package.

Any comments on the privacy issues mentioned here?:

http://dgl.cx/2020/08/dotnet-sdk-gdpr

Should this be a concern for inclusion into Debian main?

Would there be a way for Debian users to opt out of the telemetry by
default, before any information is sent?

Cheers,
Andy

Bug#920118: sponge: preverses permissions but not ownership

[Andy Smith]

Hi,

On Thu, Apr 18, 2019 at 10:42:54PM +0200, Nicolas Schier wrote:
> Why do you think that sponge ought to preserve the owner?  Did the man
> page induce that somehow?

I was caught out by this just now, and got as far as "bugreport
moreutils" before I found this existing bug.

When I read "preserves permissions" in the man page, my brain just
went on auto-pilot and assumed this meant ownership as well. I think
this is encouraged along by a common use-case of sponge as a
replacement for IO redirection, which as Hamish already noted does
preserve ownership.

I appreciate there is room for difference of opinion here over what
behaviour is surprising or not, but I don't think it is just Hamish
and I who would get surprised. So if preserving ownership is
considered not the job of sponge then perhaps this could be called
out in the man page near where it currently says that permissions
are preserved?

Thanks,
Andy

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Andy Smith]

Hello,

On Sun, Sep 08, 2019 at 05:08:12PM +0200, Thorsten Glaser wrote:
> On Sun, 8 Sep 2019, Markku Leiniö wrote:
> > On Buster, "lsb_release -d" does not show the point release:
> > 
> > $ lsb_release -d
> > Description:Debian GNU/Linux 10 (buster)
> 
> Isn’t that a feature?
> 
> The x.y there was a remnant from Debian sarge times.

Up until squeeze I have seen it show x.y.z, then from wheezy to
stretch I see only x.y, but it does seem new behaviour in buster to
only show x.

$ ansible '*' -i inventories/testing -a 'lsb_release -d' | grep ^Descr | sort -u
Description:Debian GNU/Linux 10 (buster)
Description:Debian GNU/Linux 8.11 (jessie)
Description:Debian GNU/Linux 9.10 (stretch)

Cheers,
Andy

Bug#931644: Buster kernel entropy pool too low on VM boot

[Andy Smith]

Hi Michael,

On Mon, Jul 08, 2019 at 12:59:29PM -0400, Michael J. Redd wrote:
> After upgrading to Debian Buster, Xen PV guests' entropy pool is too
> low to start cryptographic services in a timely manner. This results in
> 30+ second delays in the startup of services such as SSH.

The release notes for buster do mention this issue and provide a
link to:

https://wiki.debian.org/BoottimeEntropyStarvation

which has your Haveged solution as one of its suggestions.

Cheers,
Andy

Bug#821254: systemd[1]: xendomains.service start operation timed out.

[Andy Smith]

Hi Hans,

On Sat, Feb 02, 2019 at 11:24:36PM +0100, Hans van Kranenburg wrote:
> When working on actually shipping systemd units we'd really need
> to have a group of users that want to actively help testing
> everything. Downgrade, upgrade, try to break it etc...

I actually ended up going from Debian-packaged 4.4.x to Mark Pryor's
Debian packages because I needed to upgrade version and patch some
XSAs during embargo. At the time there wasn't much going on with the
Debian packaging and I didn't feel confident to do it myself, so I
based things off of Mark's work.

I used that as a basis for 4.8.x and now 4.10.x packages. Now that
you are helping with Debian packaging I would like to come back to
Debian's packages, probably along with an upgrade to buster.

The systemd stuff from those packages of Mark's did solve this
problem though. I assume this is upstream content. I think in 4.4 it
was generating a systemd service from an init script, whereas now
it's a native systemd service. Here's /lib/systemd/system/xendomains.service:

[Unit]
Description=Xendomains - start and stop guests on boot and shutdown
Requires=proc-xen.mount xenstored.service
After=proc-xen.mount xenstored.service xenconsoled.service
xen-init-dom0.service
After=network-online.target
After=remote-fs.target
ConditionPathExists=/proc/xen/capabilities
Conflicts=libvirtd.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStart=-/usr/lib/xen-4.10/bin/xendomains start
ExecStop=/usr/lib/xen-4.10/bin/xendomains stop
ExecReload=/usr/lib/xen-4.10/bin/xendomains restart

[Install]
WantedBy=multi-user.target

Those packages came from:

http://107.185.106.30/xen/debian/stretch-nmu/4ax/

(plus the XSAs published since then)

Would it be helpful if I installed buster and
xen-hypervisor-4.11-amd64 and checked how the systemd unit files
cope with trying to start 75 or so domains? If so I will try to find
some time to try that,

Cheers,
Andy

Bug#912592: [Pkg-xen-devel] Bug#912592: Xen stuck at boot "device-mapper: ioctl: …"

[Andy Smith]

Hi,

Could it possibly be entropy starvation?

See:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916690
https://lists.debian.org/debian-devel/2018/12/msg00184.html

Can you try things like:

- attaching a mouse and moving it during boot

- installing haveged

- Use random.trust_cpu=on on kernel command line

- Include tpm-rng module in initramfs and allow kernel to use it by
  setting command line: rng_core.default_quality=1000

?

Cheers,
Andy

Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start

[Andy Smith]

On Tue, Nov 27, 2018 at 05:19:51PM +, Andy Smith wrote:
> +ExecReload="/bin/sh -c "/usr/sbin/exportfs -r || true"

I just noticed the stray double quote there (the first one). But,
you get the idea.

Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start

[Andy Smith]

Package: nfs-kernel-server
Version: 1:1.3.4-2.1
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?

Upgrading a Debian jessie host to stretch and using systemd unit file
/lib/systemd/system/nfs-server.service instead of SysV init script
/etc/init.d/nfs-kernel-server

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Started nfs-server unit while having paths in the /etc/exports that do
not exist locally.

   * What was the outcome of this action?

The exportfs exit status was propagated to the unit due to direct use of
exportfs in ExecStartPre, so the unit failed to start.

   * What outcome did you expect instead?

To see the exportfs errors as usual, but for the NFS server to still
start up. This was the behaviour with the previous release's SysV init
script.

While I can see that it might be bad practice to have paths in the
/etc/exports file that don't exist locally, I thought these were more
like warnings from exportfs, not something that should prevent the whole
NFS server from working.

I have multiple NFS servers and I regarded it as harmless to have one
common /etc/exports file for all of them. Now I need to make them
host-specific. Also it seems like a bit of a surprise that you can
cripple a whole NFS server's next start just by deleting a directory
that is in /etc/exports.

While I do make them host-specific, and make sure they are altered when
any of their entries get removed (which will require changes to my
configuration management), I deployed this hack:

$ diff -Naur /{lib,etc}/systemd/system/nfs-server.service
--- /lib/systemd/system/nfs-server.service  2017-03-20 15:07:55.0 
+
+++ /etc/systemd/system/nfs-server.service  2018-11-20 20:41:51.185660347 
+
@@ -26,13 +26,13 @@
 
 Type=oneshot
 RemainAfterExit=yes
-ExecStartPre=/usr/sbin/exportfs -r
+ExecStartPre=/bin/sh -c "/usr/sbin/exportfs -r || true"
 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
 ExecStop=/usr/sbin/rpc.nfsd 0
-ExecStopPost=/usr/sbin/exportfs -au
-ExecStopPost=/usr/sbin/exportfs -f
+ExecStopPost=/bin/sh -c "/usr/sbin/exportfs -au || true"
+ExecStopPost=/bin/sh -c "/usr/sbin/exportfs -f || true"
 
-ExecReload=/usr/sbin/exportfs -r
+ExecReload="/bin/sh -c "/usr/sbin/exportfs -r || true"
 
 [Install]
 WantedBy=multi-user.target


-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
151   udp  32766  mountd
151   tcp  32766  mountd
152   udp  32766  mountd
152   tcp  32766  mountd
153   udp  32766  mountd
153   tcp  32766  mountd
133   tcp   2049  nfs
134   tcp   2049  nfs
1002273   tcp   2049
133   udp   2049  nfs
134   udp   2049  nfs
1002273   udp   2049
1000211   udp  59762  nlockmgr
1000213   udp  59762  nlockmgr
1000214   udp  59762  nlockmgr
1000211   tcp  37581  nlockmgr
1000213   tcp  37581  nlockmgr
1000214   tcp  37581  nlockmgr
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids --port 32766"
NEED_SVCGSSD=
RPCSVCGSSDOPTS=
-- /etc/exports --
/data/backup/rsnapshot/hourly.0/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.1/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.2/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.3/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.4/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.5/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.0/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.1/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.2/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.3/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.4/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.5/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.6/192.168.82.121 
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/weekly.0/192.168.82.121
192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/weekly.1/192.16

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

[Andy Smith]

Also same symptoms in a PV guest under Xen 4.10. Works if booted on
previous kernel. Also prevents installation of stable using the
netboot image at e.g.




Cheers,
Andy

Bug#895878: intel-microcode: MCU Rev 0x3C not found for Haswell E5-1680, finds 0xb000021 instead

[Andy Smith]

Package: intel-microcode
Version: 3.20180312.1~bpo8+1
Severity: normal

Dear Maintainer,

I've installed intel-microcode from jessie-backports-sloppy and booted
under Xen with the Xen commandline parameter "ucode=scan". This is
supposed to scan the initramfs for a microcode update and apply it.

Before doing this, the microcode revision on this machine was 0xb1d.
Xen does find an update and applies it during early boot:

(XEN) microcode: CPU0 updated from revision 0xb1d to 0xb21, date = 
2017-03-01

According to Intel's Microcode Update Guidance
()
however, the expected revision for this CPU is 0x3C.

/proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 79
model name  : Intel(R) Xeon(R) CPU E5-1680 v4 @ 3.40GHz
stepping: 1
microcode   : 0xb21
cpu MHz : 3400.028
cache size  : 20480 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi 
mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc 
eagerfpu pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt 
aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch xsaveopt 
fsgsbase bmi1 hle avx2 bmi2 erms rtm rdseed adx
bogomips: 6800.05
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 79
model name  : Intel(R) Xeon(R) CPU E5-1680 v4 @ 3.40GHz
stepping: 1
microcode   : 0xb21
cpu MHz : 3400.028
cache size  : 20480 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi 
mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc 
eagerfpu pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt 
aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch xsaveopt 
fsgsbase bmi1 hle avx2 bmi2 erms rtm rdseed adx
bogomips: 6800.05
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

Were microcode updates pulled for this CPU (thus Intel's document is
wrong) or is it a bug that the intel-microcode package doesn't include
this updated revision?

Or possibly it does contain it but the Xen hypervisor is doing something
wrong?

Thanks,
Andy

-- System Information:
Debian Release: 8.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages intel-microcode depends on:
ii  iucode-tool  1.1.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.120+deb8u3

intel-microcode suggests no packages.

-- no debconf information

Bug#850425: linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andy Smith]

On Fri, Jan 06, 2017 at 11:37:11AM +, Andy Smith wrote:
> Andrew Cooper suggested trying two patches:
> > https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614

[…]

> Using a kernel built with those patches the problem has gone away for
> me and has been stable for about a month of production load.

Sarah Newman pointed me at another message from David Vrabel:

https://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03033.html

> > As a workaround, you can give dom0 more than 4 GiB and then the
> > driver will set a 64-bit DMA mask.  I don't think the memory needs
> > to populated so something like dom0_mem=2GiB,max:4GiB might work.

I've booted the stock jessie kernel with hypervisor command line
containing "dom0_mem=2GiB,max:4GiB" and have not yet been able to
induce a crash, whereas without this I can do so within seconds by
triggering a full-speed md array check. Normally I just have
"dom0_mem=2GiB".

This has been running less than 24hrs but is looking good so far.

Thanks,
Andy

Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen

[Andy Smith]

Hi Ian,

On Mon, Jan 16, 2017 at 11:47:54AM +, Ian Jackson wrote:
> Right.  Well, you need to post to linux-kernel saying "this patch
> fixes such-and-such".  You should:

[…]

I see. This is not something I've done before, but I'd be willing to
give it a go.

But, I am not the author of these two patches. That's David Vrabel,
and they're from something Andrew Cooper referred to as "the
XenServer Patch queue", here:


https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614

At the present time I don't actually know in detail what these
patches do, nor how they have been tested, etc.; I only know that
they fix the problem I was seeing.

Is it appropriate for me to be the one presenting them to
linux-kernel and the maintainers and so on?

Thanks,
Andy

Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen

[Andy Smith]

Hi Ian,

On Mon, Jan 09, 2017 at 06:01:14PM +, Ian Jackson wrote:
> Patches only make it into Linux upstream stable releases if someone
> pushes to get them in.

Do you have any advice how I could push to get this to happen?

Obviously I need this in order for Xen to be usable on my hardware
but we're talking mpt3sas driver here which is pretty common, so I
think it is quite desirable.

Cheers,
Andy

Bug#850425: linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andy Smith]

Package: src:linux
Version: 3.16.36-1+deb8u2
Severity: normal

Dear Maintainer,

This machine has an LSI SAS controller using the mpt3sas drive.

When running as a Xen dom0 and hitting the drives attached to the
SAS controller with significant IO (e.g.e the mdadm periodic scrub),
kernel errors happen within a few seconds, sometimes to the point of
panic and reboot. If not reboot then IO crawls to an unusably slow
speed.

As this only happens when running as a Xen dom0, I reported this to the
xen-devel list:

https://lists.xen.org/archives/html/xen-devel/2016-12/msg00287.html

In this response:

https://lists.xen.org/archives/html/xen-devel/2016-12/msg00294.html

Andrew Cooper suggested trying two patches:
> Can you try these two patches from the XenServer Patch queue?
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614
> 
> There are bugs with some device drivers in choosing the correct DMA
> mask, which cause them incorrectly to believe that they need
> bounce-buffering.  Once you hit bounce buffering, everything grinds
> to a halt.

Using a kernel built with those patches the problem has gone away for
me and has been stable for about a month of production load.

I tried a backports kernel and it still has the problem. I don't think
this is fixed in stretch or sid either from a quick look but I may be
mistaken.

I don't know the timescale at which the patches Andrew Cooper linked to
will make it into upstream but I thought it best to report this bug as
it seems likely that others will be affected.

Some logs of the problem happening are appended below.

Thanks,
Andy

Dec  4 07:06:00 elephant kernel: [22019.373653] mpt3sas :01:00.0: swiotlb 
buffer is full (sz: 57344 bytes)
Dec  4 07:06:00 elephant kernel: [22019.374707] mpt3sas :01:00.0: swiotlb 
buffer is full
Dec  4 07:06:00 elephant kernel: [22019.375754] BUG: unable to handle kernel 
NULL pointer dereference at 0010
Dec  4 07:06:00 elephant kernel: [22019.376430] IP: [] 
_base_build_sg_scmd_ieee+0x1f9/0x2d0 [mpt3sas]
Dec  4 07:06:00 elephant kernel: [22019.377122] PGD 0
Dec  4 07:06:00 elephant kernel: [22019.377825] Oops:  [#1] SMP
Dec  4 07:06:00 elephant kernel: [22019.378494] Modules linked in: binfmt_misc 
xen_gntdev xen_evtchn xenfs xen_privcmd nfsd auth_rpcgss oid_registry nfs_acl 
nfs lockd fscache sunrpc ipt_REJECT xt_LOG xt_limit xt_NFLOG nfnetlink_log 
nfnetlink xt_multiport xt_tcpudp iptable_filter ip_tables x_tables bonding 
joydev hid_generic usbhid hid x86_pkg_temp_thermal coretemp crc32_pclmul 
crc32c_intel iTCO_wdt iTCO_vendor_support evdev aesni_intel aes_x86_64 lrw 
gf128mul glue_helper ablk_helper cryptd pcspkr i2c_i801 ast ttm drm_kms_helper 
xhci_hcd ehci_pci ehci_hcd drm lpc_ich mfd_core mei_me usbcore mei usb_common 
igb ptp pps_core dca sg i2c_algo_bit i2c_core shpchp tpm_tis tpm button wmi 
ipmi_si ipmi_msghandler processor thermal_sys acpi_power_meter fuse autofs4 
ext4 crc16 mbcache jbd2 dm_mod raid10 raid1 md_mod sd_mod crc_t10dif 
crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci libata mpt3sas 
raid_class scsi_transport_sas scsi_mod
Dec  4 07:06:00 elephant kernel: [22019.384778] CPU: 0 PID: 29516 Comm: 
md5_resync Not tainted 3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u2
Dec  4 07:06:00 elephant kernel: [22019.385574] Hardware name: Supermicro Super 
Server/X10SRH-CLN4F, BIOS 2.0a 09/20/2016
Dec  4 07:06:00 elephant kernel: [22019.386400] task: 8800704ae2d0 ti: 
88005c41 task.ti: 88005c41
Dec  4 07:06:00 elephant kernel: [22019.387204] RIP: e030:[]  
[] _base_build_sg_scmd_ieee+0x1f9/0x2d0 [mpt3sas]
Dec  4 07:06:00 elephant kernel: [22019.388054] RSP: e02b:88005c413a00  
EFLAGS: 00010282
Dec  4 07:06:00 elephant kernel: [22019.388855] RAX: 0010 RBX: 
88006fb84070 RCX: 88006fb41be0
Dec  4 07:06:00 elephant kernel: [22019.389684] RDX:  RSI: 
ff30 RDI: 88005c507300
Dec  4 07:06:00 elephant kernel: [22019.390572] RBP:  R08: 
88006f90ae80 R09: 
Dec  4 07:06:00 elephant kernel: [22019.391395] R10: 880078eec000 R11: 
0001 R12: 880071230720
Dec  4 07:06:00 elephant kernel: [22019.392235] R13: ffeb R14: 
fff3 R15: 
Dec  4 07:06:00 elephant kernel: [22019.393031] FS:  () 
GS:88007840() knlGS:
Dec  4 07:06:00 elephant kernel: [22019.393850] CS:  e033 DS:  ES:  
CR0: 80050033
Dec  4 07:06:00 elephant kernel: [22019.394639] CR2: 0010 CR3: 
6ece5000 CR4: 00042660
Dec  4 07:06:00 elephant kernel: [22019.395434] Stack:
Dec  4 07:06:00 elephant kernel: [22019.396253]  88006f90ae70 
008068812a20 88005a1a1500 88007123
Dec  4 07:06:00 elephant kernel: [22019.397065]  88006f880800 
88006fcc2800 88006fb84000 000a
Dec  4 07:06:00 elephant kernel: [22019.397888]  

Bug#784070: Newly-created arrays don't auto-assemble - related to hostname change?

[Andy Smith]

Hi,

On Wed, Nov 23, 2016 at 12:03:49PM +0300, Michael Tokarev wrote:
> It was long ago when we disabled incremental assembly when
> you turned it on by default, and kept old static way to
> assemble arrays, because neither our initrd nor regular
> userpsace weren't ready for that.

Okay, so, on Debian jessie then, it is expected that md arrays on
devices that are only present after the initramfs is done working
will not be automatically (incrementally) started?

I saw Yann mentioned that in stretch the GOTO="md_inc_end" has been
removed again. Does that mean that incremental assembly on device
change is expected to work again in stretch (I have not tested it,
and most likely will not have time to do so with this hardware).

Thanks,
Andy

Bug#844640: mdadm: Newly-created array doesn't assemble at boot - related to hostname change?

[Andy Smith]

On Thu, Nov 17, 2016 at 06:23:08PM +, Andy Smith wrote:
> After install, the server's hostname was changed to "jfd".
> 
> An additional array (md5) was created using member devices /dev/sd{c,d}.
> It was added to /etc/mdadm/mdadm.conf and update-initramfs -u was
> called.
> 
> This array does not assemble during boot.

I've found a work-around.

I noticed that mpt3sas driver wasn't being loaded in the initramfs,
probably because none of the drives on it are required to boot the
system.

I added mpt3sas to /etc/initramfs-tools/modules and then all drives
are seen during initramfs, and arrays are assembled:

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
Begin: Assembling all MD arrays ... [   40.1
58317] random: nonblocking pool is initialized
[   40.161795] md: bind
[   40.162161] md: bind
[   40.163226] md: raid1 personality registered for level 1
[   40.163654] md/raid1:md0: active with 2 out of 2 mirrors
[   40.163745] md0: detected capacity change from 0 to 510328832
[   40.164259]  md0: unknown partition table
mdadm: /dev/md/0 has been started with 2 drives.
[   40.176662] md: bind
[   40.177235] md: bind
[   40.178332] md: raid10 personality registered for level 10
[   40.178656] md/raid10:md1: active with 2 out of 2 devices
[   40.178746] md1: detected capacity change from 0 to 1998585856
[   40.179170]  md1: unknown partition table
mdadm: /dev/md/1 has been started with 2 drives.
[   40.189887] md: md2 stopped.
[   40.191292] md: bind
[   40.191498] md: bind
[   40.192705] md/raid10:md2: active with 2 out of 2 devices
[   40.192797] md2: detected capacity change from 0 to 999292928
[   40.193128]  md2: unknown partition table
mdadm: /dev/md/2 has been started with 2 drives.
[   40.204234] md: md3 stopped.
[   40.205278] md: bind
[   40.205695] md: bind
[   40.206613] md/raid10:md3: active with 2 out of 2 devices
[   40.206704] md3: detected capacity change from 0 to 12492734464
[   40.207094]  md3: unknown partition table
mdadm: /dev/md/3 has been started with 2 drives.
[   40.218963] md: md5 stopped.
[   40.223807]  sdb: unknown partition table
[   40.228841]  sda: unknown partition table
[   40.229044] md: bind
[   40.229613] md: bind
[   40.234024]  sdb: unknown partition table
[   40.243686] md/raid10:md5: active with 2 out of 2 devices
[   40.243867] created bitmap (14 pages) for device md5
[   40.244684] md5: bitmap initialized from disk: read 1 pages, set 0 of 28614 
bits
[   40.245376] md5: detected capacity change from 0 to 1920248840192
[   40.248331]  md5: unknown partition table
mdadm: /dev/md/5 has been started with 2 drives.
Success: assembled all arrays.
done.
[   40.260413] device-mapper: uevent: version 1.0.3
[   40.260540] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: 
dm-de...@redhat.com
done.
Begin: Running /scripts/local-premount ... [   40.265067] PM: Starting manual 
resume from disk
done.
Begin: Will now check root file system ... fsck from util-linux 2.25.2
[/sbin/fsck.ext4 (1) -- /dev/md1] fsck.ext4 -a -C0 /dev/md1
root: clean, 44775/122160 files, 265568/487936 blocks
done.
[   40.296866] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: 
(null)
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
[   40.350701] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCR
YPT +ACL +XZ -SECCOMP -APPARMOR)
[   40.350843] systemd[1]: Detected virtualization 'xen'.
[   40.350920] systemd[1]: Detected architecture 'x86-64'.

Welcome to Debian GNU/Linux 8 (jessie)!

I still think there must be an issue here as I can see no reason why
udev should not have incrementally-assembled this array on later
appearance of the drives.

Anyway, it seems there is some discussion of this on linux-raid now:

http://marc.info/?l=linux-raid&m=147935582503112&w=2

so I will continue working through it there.

Cheers,
Andy

Bug#844640: mdadm: Newly-created array doesn't assemble at boot - related to hostname change?

[Andy Smith]

Package: mdadm
Version: 3.3.2-5+deb8u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

First off, I feel like I am missing something obvious and that this may
not be a bug. I did present this problem on linux-raid first, and it
seems to have stumped them. So, here goes…

I installed a server and created four md arrays (md{0,1,2,3}) using
partman from the installer. The devices involved there were all
partitions on /dev/sd{a,b}. At this time the server's hostname was
"tbd".

After install, the server's hostname was changed to "jfd".

An additional array (md5) was created using member devices /dev/sd{c,d}.
It was added to /etc/mdadm/mdadm.conf and update-initramfs -u was
called.

This array does not assemble during boot.

After boot, it does assemble by doing:

# mdadm --assemble /dev/md5

or:

# mdadm --incremental /dev/sdc
# mdadm --incremental /dev/sdd

The mdadm.conf looks correct and is identical to the mdadm.conf inside
the initramfs.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After looking at --detail and --examine I spotted that my new array md5
had a hostname of "jfd" whereas all the others had "tbd", since that was
the hostname when they were created. I tried changing the HOMEHOST line
from  to  or completely removing it.

I also tried changing the hostname of md5 to "tbd" so it was like all
the others, by doing:

# mdadm --assemble --homehost="tbd" --update=homehost /dev/md5 /dev/sd{c,d}

Neil Brown on linux-raid suggested removing my "DEVICE /dev/sd*" line
from mdadm.conf in case it confused udev, which I did also try without
success. Previously it had been the default, "DEVICE partitions
containers".

   * What was the outcome of this action?

None of this seems to have made any difference. md5 does not assemble
during boot but can be assembled manually after boot.

   * What outcome did you expect instead?

For md5 to be assembled during boot like md{0,1,2,3} are.

All of the info below was added by reportbug and I will not remove
anything just in case it is useful. There is some extra info about a
/dev/md4 and its member devices /dev/sd{e,f} which can be ignored
though. Like md5 it does not assemble at boot, but I am choosing to
focus on md5 for now.

The package reportbug script fails to examine the initramfs because it
has a firmware blob prepended to it. I extracted the initramfs and it
doesn't have a conf/conf.d/md file. Here's the conf/mdadm file:

MD_HOMEHOST='jfd'
MD_DEVS=all

reportbug shows /proc/mdstat at boot time, before I have manually
assembled md5. Here is what it looks like afterwards:

$ sudo mdadm --assemble /dev/md5
mdadm: /dev/md5 has been started with 2 drives.
$ cat /proc/mdstat 
Personalities : [raid1] [raid10] 
md5 : active (auto-read-only) raid10 sdd[0] sdc[1]
  1875243008 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  bitmap: 0/14 pages [0KB], 65536KB chunk

md3 : active raid10 sda5[0] sdb5[1]
  12199936 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  
md2 : active (auto-read-only) raid10 sda3[0] sdb3[1]
  975872 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  
md1 : active raid10 sda2[0] sdb2[1]
  1951744 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  
md0 : active raid1 sda1[0] sdb1[1]
  498368 blocks super 1.2 [2/2] [UU]
  
unused devices: 

-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
MAILADDR root
ARRAY /dev/md/0  metadata=1.2 UUID=400bac1d:e2c5d6ef:fea3b8c8:bcb70f8f
ARRAY /dev/md/1  metadata=1.2 UUID=e29c8b89:705f0116:d888f77e:2b6e32f5
ARRAY /dev/md/2  metadata=1.2 UUID=039b3427:4be5157a:6e2d53bd:fe898803
ARRAY /dev/md/3  metadata=1.2 UUID=30f745ce:7ed41b53:4df72181:7406ea1d
ARRAY /dev/md/5  metadata=1.2 UUID=957030cf:c09f023d:ceaebb27:e546f095

--- /etc/default/mdadm
INITRDSTART='all'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=true

--- /proc/mdstat:
Personalities : [raid1] [raid10] 
md3 : active raid10 sda5[0] sdb5[1]
  12199936 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  
md2 : active (auto-read-only) raid10 sda3[0] sdb3[1]
  975872 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  
md1 : active raid10 sda2[0] sdb2[1]
  1951744 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  
md0 : active raid1 sda1[0] sdb1[1]
  498368 blocks super 1.2 [2/2] [UU]
  
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   8   16   15638616 sdb
   8   17 498688 sdb1
   8   181952768 sdb2
   8   19 976896 sdb3
   8   20  1 sdb4
   8   21   12208128 sdb5
   80   15638616 sda
   81 498688 sda1
   821952768 sda2
   83 976896 sda3
   84  1 sda4
   85   12208128 sda5
   90 498368 md0
   911951744 md1
   92 975872 md2
   93   12199936 md3
   8   48 1875374424

Bug#825717: firefox: Input/select boxes have become disproportionately huge (hiDPI issue?)

[Andy Smith]

Package: firefox
Version: 47.0~b5-1
Severity: normal

Dear Maintainer,

I have a hiDPI display and have been using firefox from experimental
because it has fewer issues with this.

Upon upgrading from 47.0~b1 to 47.0~b5, a regression has occurred in
that most input elements such as submit buttons and select dialogs have
become very large in comparison to surrounding text size; something I
had experienced with the stretch version of Firefox.

This is causing many sites to have broken formatting or in some cases
completely unusable interfaces due to button overlap.

This jsfiddle:

https://jsfiddle.net/grifferz/szxydj7b/2/

Renders like this in 47.0~b1:

http://i.imgur.com/5tLnkO0.png

And like this in 47.0~b5:

http://i.imgur.com/iMWiBMZ.png

As you can see it is around 1.5x the size.

Looking at a web page with a simple



button under Style Inspector, I can see no changes other than the font
size for the button in 47.0~b5 being twice as many px as in 47.0~b1. See
http://i.imgur.com/dJJqqmh.png vs. http://i.imgur.com/gKq3uw3.png.

(These four images collected at http://imgur.com/a/wB6cP for ease of
comparison)

As a workaround is there any way to override system font size for form
input elements? It seems to be set in forms.css.


-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: AutoHiDPI
Location: ${PROFILE_EXTENSIONS}/jid1-yldsmqrkspn...@jetpack.xpi
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: Emoji Cheatsheet for GitHub, Basecamp etc.
Location: ${PROFILE_EXTENSIONS}/jid1-xo5sua6qc1d...@jetpack.xpi
Status: enabled

Name: Facebook Purity greasemonkey-user-script
Status: enabled

Name: Firefox Hello
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: GNOME theme
Location: ${PROFILE_EXTENSIONS}/{451500c0-902c-11e0-91e4-0800200c9a66}.xpi
Status: user-disabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: is.gd Creator (fork)
Location: ${PROFILE_EXTENSIONS}/isgdcrea...@mrkschan.at.gmail.com.xpi
Status: enabled

Name: It's All Text!
Location: ${PROFILE_EXTENSIONS}/itsallt...@docwhat.gerf.org
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Open in Browser
Location: ${PROFILE_EXTENSIONS}/openinbrow...@www.spasche.net.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: pq
Location: ${PROFILE_EXTENSIONS}/@pq.xpi
Status: enabled

Name: Tab Memory Usage
Location: ${PROFILE_EXTENSIONS}/jid1-frvglzkoncs...@jetpack.xpi
Status: user-disabled

Name: TinEye Reverse Image Search
Location: ${PROFILE_EXTENSIONS}/tin...@ideeinc.com.xpi
Status: enabled

Name: Tree Style Tab
Location: ${PROFILE_EXTENSIONS}/treestyle...@piro.sakura.ne.jp.xpi
Status: enabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled

Name: Shockwave Flash (11.2.202.616)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled


-- Addons package information
ii  firefox47.0~b5-1amd64Mozilla Firefox web browser
ii  gnome-shell3.20.2-1 amd64graphical shell for the 
GNOME desktop
ii  icedtea-8-plugin:amd64 1.6.2-3  amd64web browser plugin based 
on OpenJDK and IcedTea to execute Java applets
ii  rhythmbox-plugins  3.3.1-2  amd64plugins for rhythmbox 
music player

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.4
ii  libasound21.1.0-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-9
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1 

Bug#821254: systemd[1]: xendomains.service start operation timed out.

[Andy Smith]

Package: xen-utils-common
Version: 4.4.1-9+deb8u4
Severity: normal

Dear Maintainer,

I have a server with a large number of domUs set to auto-start. For the
first time I have booted it with all of them needing to start from cold,
but the xendomains service only got part way through.

syslog showed nothing notable about the domains starting…

Apr 16 14:57:45 snaps xendomains[4631]: Starting Xen domain lima (from 
/etc/xen/auto/010-lima.conf)...done.

…until…

Apr 16 15:02:36 sierra xendomains[4631]: Starting Xen domain juliet (from 
/etc/xen/auto/627-juliet.conf)...done.
Apr 16 15:02:37 sierra kernel: [  341.269174] xen-blkback:ring-ref 8, 
event-channel 15, protocol 2 (x86_32-abi)
Apr 16 15:02:37 sierra kernel: [  341.367307] xen-blkback:ring-ref 9, 
event-channel 16, protocol 2 (x86_32-abi)
Apr 16 15:02:38 sierra kernel: [  341.437187] vif vif-51-0 v-juliet: Guest 
Rx ready
Apr 16 15:02:38 sierra kernel: [  341.437429] IPv6: 
ADDRCONF(NETDEV_CHANGE): v-juliet: link becomes ready
Apr 16 15:02:40 sierra systemd[1]: xendomains.service start operation timed 
out. Terminating.
Apr 16 15:02:40 sierra systemd[1]: Failed to start LSB: Start/stop 
secondary xen domains.
Apr 16 15:02:40 sierra systemd[1]: Unit xendomains.service entered failed 
state.

That the 51st domain, around 60% of the way through the list of domains
it should have started.

Once I'd realised only some of the domains were started I reran "service
xendomains start" and it finished the job.

So, is there a built in timeout of ~5 minutes here that I need to
increase? 

I see that the generated /run/systemd/generator.late/xendomains.service
file contains:

.
.
[Service]
Type=forking
Restart=no
TimeoutSec=5min
.
.

So that's probably what is being hit, but I cannot work out how to make
the generator apply a longer timeout.

Any hints would be appreciated.

Cheers,
Andy

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xen-utils-common depends on:
ii  lsb-base4.1+Debian13+nmu1
ii  python  2.7.9-1
ii  ucf 3.0030
ii  udev215-17+deb8u4
ii  xenstore-utils  4.4.1-9+deb8u4

xen-utils-common recommends no packages.

xen-utils-common suggests no packages.

-- Configuration Files:
/etc/default/xendomains changed [not included]
/etc/xen/scripts/vif-route changed [not included]
/etc/xen/xl.conf changed [not included]

-- no debconf information

Bug#818349: I receive the warning when using single-file config but not split config

[Andy Smith]

Hi,

I have a bunch of jessie hosts that are all very similar, and since
this upgrade one of them has been sending me this cron email during
cron.daily.

I checked out the difference between that host and the other and the
only difference in /etc/exim4/update-exim4.conf.conf was:

dc_use_split_config='false'

After reconfiguring to use single config file I do not receive the
warning.

As I say these are very simple systems. Full content of
/etc/exim4/update-exim4.conf.conf on them all (now) is:

dc_eximconfig_configtype='internet'
dc_other_hostnames='theirhostname.localnet'
dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.80.19'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

Cheers,
Andy

Bug#818061: iceweasel: Form elements such as input and select have huge font on hidpi screen

[Andy Smith]

Hi Mike,

On Sun, Mar 13, 2016 at 06:30:54PM +0900, Mike Hommey wrote:
> Please try firefox from experimental, it should have (better) support
> for hidpi.

Thanks, that is much better. I still need to set devPixelsPerPx to
1.5 to make content not so tiny, but I'm glad to see that form
elements are now in proportion to the rest of the content.

The same JSFiddle (https://jsfiddle.net/xwfjvpup/2/) with Firefox
from experimental now looks like this:

http://imgur.com/fPtKnpy

DOM Inspector still shows it as using -moz-system-font, but that is
now 14.2167px.

Cheers,
Andy

Bug#818061: iceweasel: Form elements such as input and select have huge font on hidpi screen

[Andy Smith]

On Sun, Mar 13, 2016 at 08:37:14AM +, Andy Smith wrote:
> If you look at this JSFiddle:
> 
> https://jsfiddle.net/xwfjvpup/2/
> 
> It renders like this for me:
> 
> http://imgur.com/1Kw6XmO

I forgot to mention, if I use DOM Inspector on say, the select
element, it says this:

font-size   >28.45px
select> -moz-system-font forms.css:194
form> 18pxinline:2

The "form" line is greyed out, I suppose indicating that Iceweasel
has chosen to use -moz-system-font from forms.css.

Cheers,
Andy

Bug#818061: iceweasel: Form elements such as input and select have huge font on hidpi screen

[Andy Smith]

Package: iceweasel
Version: 44.0.2-1
Severity: normal

Dear Maintainer,

I've just installed testing and Iceweasel on a laptop with a fairly high
resolution display; 2560x1440. To make Iceweasel usable I needed to set
layout.css.devPixelsPerPixel to 1.5 otherwise everything was very tiny.
However, this leaves just form elements like ,  and
 using a really big font size.

If you look at this JSFiddle:

https://jsfiddle.net/xwfjvpup/2/

It renders like this for me:

http://imgur.com/1Kw6XmO

Form elements that have font styling on them appear correctly, but
those with only styling on a parent seem to use -moz-system-font which
in my case is coming out as 28.45px.

My system font is Cantarell Regular 16. I don't know if that multiplied
by 1.5 would result in 28.45px font, but in any case the rest of Firefox
(UI and content) is okay, and reducing my system font size makes the
rest of the system appear unusably small.

If I could work out a way to override -moz-system-font then that would
probably be an acceptable workaround, but I cannot find a way.

This issue persists without any extensions and also with upstream
Firefox.

I also tried:

- Changing font preferences in Preferences > Content > Advanced. DOM
  Inspector says that -moz-system-font is selected no matter what is in
  use here.

- Overriding in userChrome.css. This is only for UI, so doesn't affect
  content, and does nothing for me.

- Overriding in userContent.css. This works, but I am unsure of the
  precedence between userContent.css and page CSS, so I worry about
  overriding styles that author has specifically put on form elements.

So as it is, I am overriding in userContent.css because sites I need to
use are unusable otherwise, e.g. form elements expand over the top of
nearby links, leaving me unable to click on them.


-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled


-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled


-- Addons package information
ii  gnome-shell3.18.1-1 amd64graphical shell for the GNOME des
ii  iceweasel  44.0.2-1 amd64Web browser based on Firefox
ii  iceweasel-l10n 1:44.0.2-1   all  English (United Kingdom) language
ii  rhythmbox-plug 3.3-1amd64plugins for rhythmbox music playe

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iceweasel depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.3
ii  libasound21.1.0-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.21-9
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.3-3
ii  libgcc1   1:5.3.1-10
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1.1
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.10.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.1-10
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.11-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.6.3-1
ii  gstreamer1.0-plugins-good  1.6.3-1

Versions of packages iceweasel suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.13.2+dfsg-5
pn  mozplugger 

-- no debconf information

Bug#817016: linux-image-4.3.0-1-amd64: ThinkPad X1 Carbon: Boot stalls at "intel_pstate: HWP enabled"

[Andy Smith]

Package: src:linux
Version: 4.3.5-1
Severity: normal

Dear Maintainer,

Booting this kernel (or the debian-installer latest daily) results in a blank
screen. When removing the quiet option the boot is seen to stall after printing
"intel_pstate: HWP enabled".

Here's a screenshot: http://i.imgur.com/cr5i72L.png

Searching around found me another report from a Yoga 260 owner with the same
issue. They've got a Skylake i5 whereas I've got a Skylake i7. A suggested
workaround was to use kernel parameter:

intel_pstate=no_hwp

This allowed boot of the debian-installer and this installed kernel but I
understand it disables many desirable power efficiency features.

Thanks,
Andy

PS reportbug has included kernel logs that show many errors, but I do not
believe these are relevant to this report. They are triggered by PID 994 which
is Xorg and seem to occur when the screen resolution is changed. I'll report
that separately.

-- Package-specific info:
** Version:
Linux version 4.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160121 (Debian 5.3.1-7) ) #1 SMP Debian 4.3.5-1 (2016-02-06)

** Command line:
BOOT_IMAGE=/vmlinuz-4.3.0-1-amd64 root=/dev/mapper/jameson--vg-root ro 
intel_pstate=no_hwp

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[ 2433.534966]  [] ? warn_slowpath_common+0x7d/0xb0
[ 2433.534967]  [] ? warn_slowpath_fmt+0x5c/0x80
[ 2433.534979]  [] ? gen9_read32+0xf4/0x2c0 [i915]
[ 2433.534987]  [] ? assert_csr_loaded+0x92/0xf0 [i915]
[ 2433.534995]  [] ? skl_set_power_well+0x72e/0x960 [i915]
[ 2433.535003]  [] ? intel_display_power_get+0x9c/0xe0 [i915]
[ 2433.535017]  [] ? intel_hdmi_set_edid+0x33/0xe0 [i915]
[ 2433.535030]  [] ? intel_hdmi_detect+0x4d/0x90 [i915]
[ 2433.535034]  [] ? 
drm_helper_probe_single_connector_modes_merge_bits+0x218/0x480 [drm_kms_helper]
[ 2433.535037]  [] ? mutex_lock+0xe/0x30
[ 2433.535054]  [] ? drm_mode_getconnector+0x2ec/0x340 [drm]
[ 2433.535060]  [] ? drm_ioctl+0x110/0x440 [drm]
[ 2433.535067]  [] ? drm_mode_getcrtc+0x120/0x120 [drm]
[ 2433.535070]  [] ? do_vfs_ioctl+0x2a5/0x490
[ 2433.535072]  [] ? SyS_ioctl+0x74/0x80
[ 2433.535074]  [] ? system_call_fast_compare_end+0xc/0x67
[ 2433.535076] ---[ end trace 7314370e76d2c1e6 ]---
[ 2433.535077] [ cut here ]
[ 2433.535084] WARNING: CPU: 2 PID: 994 at 
/build/linux-19r8NQ/linux-4.3.5/drivers/gpu/drm/i915/intel_csr.c:461 
assert_csr_loaded+0xc6/0xf0 [i915]()
[ 2433.535086] CSR SSP Base Not fine
[ 2433.535086] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix 
ntfs msdos jfs xfs libcrc32c fuse rfcomm ctr ccm bnep nls_utf8 nls_cp437 vfat 
fat arc4 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic joydev 
intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt 
iwlmvm iTCO_vendor_support acer_wmi sparse_keymap mac80211 kvm snd_hda_intel 
uvcvideo snd_hda_codec videobuf2_vmalloc iwlwifi videobuf2_memops snd_hda_core 
videobuf2_core snd_hwdep v4l2_common i915 efi_pstore psmouse rtsx_pci_ms evdev 
pcspkr snd_pcm serio_raw efivars i2c_i801 memstick cfg80211 snd_timer sg 
videodev mei_me drm_kms_helper media mei btusb shpchp btrtl btbcm drm btintel 
bluetooth i2c_algo_bit thinkpad_acpi wmi nvram snd soundcore rfkill battery ac 
video button tpm_crb tpm_tis tpm
[ 2433.535112]  processor efivarfs autofs4 ext4 crc16 mbcache jbd2 
algif_skcipher af_alg dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul 
crc32c_intel jitterentropy_rng sha256_ssse3 sha256_generic hmac drbg ansi_cprng 
rtsx_pci_sdmmc mmc_core aesni_intel aes_x86_64 lrw gf128mul glue_helper 
ablk_helper cryptd ahci libahci e1000e ptp pps_core xhci_pci libata xhci_hcd 
rtsx_pci scsi_mod mfd_core usbcore usb_common thermal
[ 2433.535126] CPU: 2 PID: 994 Comm: Xorg Tainted: GW   
4.3.0-1-amd64 #1 Debian 4.3.5-1
[ 2433.535127] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET34W (1.08 
) 01/21/2016
[ 2433.535128]   bed6e6d8 812ddf19 
880216557b80
[ 2433.535130]  81072afd 880217dd 880216557bd8 
0002
[ 2433.535132]  300f  81072b8c 
a07950bf
[ 2433.535133] Call Trace:
[ 2433.535135]  [] ? dump_stack+0x40/0x57
[ 2433.535137]  [] ? warn_slowpath_common+0x7d/0xb0
[ 2433.535139]  [] ? warn_slowpath_fmt+0x5c/0x80
[ 2433.535146]  [] ? assert_csr_loaded+0xc6/0xf0 [i915]
[ 2433.535153]  [] ? skl_set_power_well+0x72e/0x960 [i915]
[ 2433.535160]  [] ? intel_display_power_get+0x9c/0xe0 [i915]
[ 2433.535173]  [] ? intel_hdmi_set_edid+0x33/0xe0 [i915]
[ 2433.535185]  [] ? intel_hdmi_detect+0x4d/0x90 [i915]
[ 2433.535189]  [] ? 
drm_helper_probe_single_connector_modes_merge_bits+0x218/0x480 [drm_kms_helper]
[ 2433.535191]  [] ? mutex_lock+0xe/0x30
[ 2433.535199]  [] ? drm_mode_getconnector+0x2ec/0x340 [drm]
[ 2433.535205]  [] ? drm_ioctl+0x110/0x440 [drm]
[ 2433.535212]  [] ? drm_mode_getcrtc+0x120/0x120 [drm]
[ 2433.535215]  [] ? do_vfs_ioctl+0x2a5/0x490
[ 24

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[Andy Smith]

Hi Ian,

On Fri, Jan 29, 2016 at 02:57:23PM +, Ian Campbell wrote:
> I spent a bit of time investigating this, but sadly I'm not able to
> reproduce the basis failure.

FWIW it was me who reported this with the packages in Debian stable
(linux-image-3.16.0-4-amd64 3.16.7-ckt20-1+deb8u3,
xen-hypervisor-4.4-amd64 4.4.1-9+deb8u3) when using
"dom0_mem=1024M,max:1024M" on the hypervisor command line.

I must admit I found this bug when searching for the error message,
and have only been seeing it printed a couple of times at guest
shutdown, not thousands of times.

So if having it printed a couple of times isn't considered a bug,
I'm sorry if I've led you astray here. Might be worth finding a way
to remove it anyway though; anyone having a problem is going to keep
searching for it thinking it is relevant to their case.

At the moment I am avoiding seeing the message at all by running with
only "dom0_mem=1024M" on the command line. What's the disadvantage
of not having the "max:1024M" there?

Cheers,
Andy

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[Andy Smith]

Hi,

I'm also seeing this.

With:

GRUB_CMDLINE_XEN="dom0_mem=1024M,max:1024M …"

I see a flurry of "xen:balloon: Cannot add additional memory (-17)"
messages every time a domU is shut down.

In this configuration I note that I also see with "free -m" that
dom0 has 929M, though "xl list" shows 1024M.

I can run "xl mem-set 0 1024" without visible error but it does not
prevent the error messages being logged.

With:

GRUB_CMDLINE_XEN="dom0_mem=1024M …"

I do not see any of the balloon error messages.

In this configuration "free -m" shows 768M RAM for dom0, though "xl
list" still shows 1024M.

xen-hypervisor-4.4-amd644.4.1-9+deb8u3
linux-image-3.16.0-4-amd64  3.16.7-ckt20-1+deb8u2

I'm guessing that the reason I end up with 768M RAM in dom0 is
because I have not specified the *maximum* RAM for dom0, so the
kernel scales structures for the possible case of dom0 getting the
entire 128G of RAM at some point.

I added "mem=1G" to the Linux kernel command line and then dom0
boots with "free -m" showing 930M.

So, at the moment I am running with "dom0_mem=1024M" on the Xen
command line, "mem=1G" on the Linux kernel command line, and
"autoballoon=off" in /etc/xen/xl.conf.

This seems to avoid the xen:balloon error messages and provide
something more like thr expected amount of dom0 memory. Is there a
downside of not specifying the ",max:1024M" part?

Cheers,
Andy

Bug#783063: Xen domU freeze with "Guest Rx stalled"

[Andy Smith]

Hi,

Quick question: do you consider this a guest kernel bug or a dom0
kernel bug?

I ask, because in the last two months I have now seen it three
times.

I recently deployed three jessie dom0 servers as part of a rolling
upgrade (everything else is wheezy or older at this stage). Within a
few weeks of putting customers on the first one I saw this "Guest Rx
stalled" one one customer VM.

I had a look at the customer VM and it was a really old Ubuntu 8.04
thing with a 2.6.18 kernel, hopelessly old, so I advised them to
upgrade it.

A few weeks later I saw it again and this time it was an old Debian
VM with 2.6.26+xen patches. Still pretty ancient and not in a shape
to report a bug on, so again I advised them to upgrade to a
supported release.

Now today I've seen it but this time it is a Debian jessie install.
I'm not completely sure of the kernel in use there but I imagine it
will be stock jessie package.

As for dom0 side of things, that's jessie with
3.16.7-ckt11-1+deb8u5.

So… if this is guest kernel bug, good that I don't have to reboot
into a new kernel, but bad in that I don't have direct control over
what kernels the customer VMs use.

If I see it again with a jessie VM I will report it as a bug. Here
or in a new bug?

Cheers,
Andy

Bug#804315: [Vmdebootstrap-devel] Namespace issues

[Andy Smith]

Hello,

Speaking as a fairly happy user of live-build, but not a contributor
to it. I also don't know anything about live-build-ng yet so it is
perhaps worth mentioning that while I always got the live-build
support I needed, I did always feel that Daniel was perhaps a bit
too brusque with people. Point being, I'm not some Daniel fanboy
that just popped up out of nowhere. :)

However…

On Sun, Nov 08, 2015 at 11:45:50PM +, Iain R. Learmonth wrote:
> It is worth noting that live-build is not a Debian project, it is an
> external project that claims to be an official Debian project. This is
> something that needs to be fixed.

Can I ask why this matters? I have never before seen Debian take it
lightly when a new project/package invades an existing package's
namespace. I don't understand why it matters that live-build isn't a
Debian project and live-build-ng is.

I would have thought that a Debian project would be /more/ careful
about following existing Debian customs regarding namespace. Isn't
the existing custom to advise new packages to pick different names?

> live-build has been deprecated by debian-cd, and live-build-ng is
> replacing it. In a purely Debian context at least, live-build is deprecated.

It seems to me like if there is an issue with live-build claiming to
be some sort of official Debian project when it isn't, that could be
solved by asking it to not claim that. Not making your own that
deliberately takes over its name and goes out of its way to call it
deprecated.

As someone who is unaware of any previous hostilities and is just a
user of live-build, what this thread tells me is that it isn't
enough for people in Debian to come up with their own live project,
they have to explicitly attack the current live-build.

> live-build-ng is being developed in collaboration with debian-cd and D-I.

Don't you think it is quite offensive to call something foo-ng when
foo is clearly still alive?

> I'm aware that I'm going to be upsetting people, but this has been a long
> time coming and I'm not going to spend time bikeshedding over naming. I
> would rather spend that time on integration of live image creation into
> official Debian infrastructure and building the best system for live image
> creation possible.

It seems to me like it would be really quite trivial for you to pick
a different name, so it need not take away any real time from your
other activities.

Speaking from the point of view of someone who currently uses
live-build, I am no less likely to research live-build-ng just
because it would have a different name.

So…

> Consider this thread marked as wontfix.

…I don't really understand why things have to be so hostile, or why
this escalation of hostility was necessary. :(

Cheers,
Andy

Bug#794071: [Pkg-xen-devel] Bug#794071: Bug#794071: "xenconsole: Could not open tty `': No such file or directory" during PV guest boot

[Andy Smith]

Hi Ian,

On Wed, Oct 21, 2015 at 08:25:11AM +0100, Ian Campbell wrote:
> On Tue, 2015-10-20 at 15:21 +0000, Andy Smith wrote:
> > On Fri, Sep 04, 2015 at 02:27:27PM +0100, Ian Campbell wrote:
> > > This sounds a bit like the issue fixed by
> > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=39ba2989b10b6a1
> > 852e253b204eb010f8e7026f1
> > > 
> > > Are you able to run a new Xen (either 4.5.1~rc1-1 from experimental
> > or an
> > > upstream version would do) to confirm?
> > 
> > Yes, that fixes the problem for me.
> 
> Super. Did you run a packaged version from Debian or an upstream
> version? Can you let me know which so I can tell the BTS about it
> please.

Sorry, I did not try the Debian package from experimental, I just
downloaded and compiled 4.6.0 from
http://xenproject.org/downloads/xen-archives/xen-46-series/xen-460.html.
I mainly wanted it to work with the current Debian stable package.

Cheers,
Andy

Bug#794071: [Pkg-xen-devel] Bug#794071: "xenconsole: Could not open tty `': No such file or directory" during PV guest boot

[Andy Smith]

Hi Ian,

On Fri, Sep 04, 2015 at 02:27:27PM +0100, Ian Campbell wrote:
> This sounds a bit like the issue fixed by
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=39ba2989b10b6a1852e253b204eb010f8e7026f1
> 
> Are you able to run a new Xen (either 4.5.1~rc1-1 from experimental or an
> upstream version would do) to confirm?

Yes, that fixes the problem for me. I applied the patch to the
current Debian stable "xen" source package and it also fixed the
issue.

Thanks,
Andy

Bug#800088: apticron: Needs interface list for IP discovery as well as IPs per interface

[Andy Smith]

Package: apticron
Version: 1.1.57
Severity: wishlist

Dear Maintainer,

At the moment apticron seems to have an IPADDRESSNUM= setting which
controls how many IP addresses are listed, but this appears to be IP
addresses *per interface*.

I have hosts with 70+ network interfaces, and as a result their apticron
headers have one IPv4 and one IPv6 address per interface, which makes
for incredibly verbose header text that takes up the entire first page
of any report.

It would be good to limit IP address discovery to listed interfaces, so
that I can choose just the interface I care about. For example:

IPINTERFACES="bond0 eth7"

If not set then the default behaviour of getting addresses from every
interface would prevail.

As a workaround it is possible to use IPADDRESSES="…" to hard-code the
correct IP addresses for each host, which is not too much trouble with
config management to generate a unique config file per host.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apticron depends on:
ii  apt1.0.9.8.1
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2
ii  bzip2  1.0.6-7+b3
ii  cron [cron-daemon] 3.0pl1-127+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.25
ii  ucf3.0030

Versions of packages apticron recommends:
ii  apt-listchanges  2.85.13+nmu1
ii  iproute2 3.16.0-2

apticron suggests no packages.

-- debconf information excluded

Bug#794820: Sorry, it's not ruby-rack's problem

[Andy Smith]

Hi,

I'm sorry, this is a mistaken report. The problem is real, but
downgrading ruby-rack did not fix it, it just took slightly longer
to manifest itself. So ruby-rack is not to blame.

Apologies for wasting your time.

Cheers,
Andy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794820: ruby-rack: High CPU usage in "apache -k start" processes with phusion passenger

[Andy Smith]

Package: ruby-rack
Version: 1.4.1-2.1+deb7u1
Severity: normal

Dear Maintainer,

After upgrading ruby-rack package from 1.4.1-2.1 to 1.4.1-2.1+deb7u1,
high CPU usage is observed with the two apache "start" processes.
Between them they are trying to use 100% CPU forever.

This problem goes away when ruby-rack package is downgraded to 1.4.1-2.1
again.

The app being run here is puppet master, but the only package being
changfed is ruby-rack.

An strace of the apache processes showed them to be just waiting on a
read of fd #89 (a pipe), but I expect they are multi-threaded so this
was not useful.

Apache MPM in use is prefork, and phusion passenger

-- System Information:
Debian Release: 7.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ruby-rack depends on:
ii  ruby  1:1.9.3
ii  ruby1.8 [ruby-interpreter]1.8.7.358-7.1+deb7u3
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.1+deb7u5

ruby-rack recommends no packages.

ruby-rack suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794071: "xenconsole: Could not open tty `': No such file or directory" during PV guest boot

[Andy Smith]

Package: xen-utils-common
Version: 4.4.1-9+deb8u1
Severity: normal

Dear Maintainer,

When booting a PV guest (xl create -c /etc/xen/foo.conf), immediately
after pygrub has determined which kernel/initramfs it will use, the
following error messages are logged:

xenconsole: Could not open tty `': No such file or directory
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] 
exited with error status 2

The boot does however continue normally including all expected console
output from the guest. The resulting console is perfectly usable once
the guest's login prompt is reached.

Then, once the console is exited with ctrl-], the terminal settings are
messed up such that no text is echoed and pressing return does not
advance to the next line. Terminal usability can be restored by using
"stty sane" or "reset" at this point.

Searching the web for the above error messages only reveals people who
say that xenconsoled wasn't running, however in this case xenconsoled
*is* running (and the console does work, both continuing from the "xl
create -c …" and also if connected to with "xl console …").

Here is an example guest config:

name   = "debtest1"
memory = 1024
vif= [ "mac=00:16:5e:00:02:39, ip=192.168.82.225, vifname=v-debtest1" ]
bootloader = "/usr/lib/xen-default/bin/pygrub"
disk   = [ "phy:/dev/vg/debtest1_xvda,xvda,w",
   "phy:/dev/vg/debtest1_xvdb,xvdb,w", ]

The kernel command line that pygrub will extract is:

linux (kernel )(ramdisk 
)(args 
"root=UUID=bb7a41e3-67f4-436a-8a80-07ec26573360 ro console=hvc0")

however it happens with all my guests regardless of distribution or
version.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xen-utils-common depends on:
ii  lsb-base4.1+Debian13+nmu1
ii  python  2.7.9-1
ii  ucf 3.0030
ii  udev215-17+deb8u1
ii  xenstore-utils  4.4.1-9+deb8u1

xen-utils-common recommends no packages.

xen-utils-common suggests no packages.

-- Configuration Files:
/etc/xen/scripts/vif-route changed [not included]
/etc/xen/xl.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#620390: This can also happen if you have old 0.90 superblocks lying about

[Andy Smith]

I recently needed to shrink a 6 device RAID-10 array down to 4
devices, on a Debian wheezy host. As part of that process I needed
to upgrade the metadata from 0.90 to 1.0.

After the work was done, I started receiving these "error: found two
disks with the index 3 for RAID md2" messages from grub-probe.

My searching found this bug, and the upstream bug:

http://savannah.gnu.org/bugs/index.php?34250

but both of these state that the problem is fixed upstream and that
it doesn't happen with 1.x metadata.

It turns out that the old copy of the 0.90 metadata is left on my
disk and grub-probe is finding it.

This can be verified as follows:

# mdadm --examine --metadata=1.0 /dev/sda3
/dev/sda3:
  Magic : a92b4efc
Version : 1.0 
Feature Map : 0x0 
 Array UUID : 3905b303:ca604b72:be5949c4:ab051b7a
   Name : 2   
  Creation Time : Sun Jun  4 08:18:59 2006
 Raid Level : raid10
   Raid Devices : 4   
  
 Avail Dev Size : 618727264 (295.03 GiB 316.79 GB)
 Array Size : 618726528 (590.06 GiB 633.58 GB)
  Used Dev Size : 618726528 (295.03 GiB 316.79 GB)
Data Offset : 128 sectors
   Super Offset : 618727392 sectors
  State : active
Device UUID : e30176be:81a57e84:1f2aa206:9515150f
  
Update Time : Fri Sep 12 12:22:47 2014
   Checksum : bd6c9738 - correct
 Events : 1415
  
 Layout : near=2
 Chunk Size : 64K 
  
   Device Role : Active device 1
   Array State :  ('A' == active, '.' == missing)
[andy@specialbrew ~]$ sudo mdadm --examine --metadata=0.90 /dev/sda3
/dev/sda3:
  Magic : a92b4efc
Version : 0.90.01
   UUID : 3905b303:ca604b72:be5949c4:ab051b7a
  Creation Time : Sun Jun  4 08:18:58 2006
 Raid Level : raid10
  Used Dev Size : 309363264 (295.03 GiB 316.79 GB)
 Array Size : 928089792 (885.10 GiB 950.36 GB)
   Raid Devices : 6   
  Total Devices : 6   
Preferred Minor : 2   
  
Update Time : Sun Aug 24 14:26:50 2014
  State : clean
 Active Devices : 6   
Working Devices : 6   
 Failed Devices : 0   
  Spare Devices : 0   
   Checksum : e613d577 - correct
 Events : 312149996
  
 Layout : near=2
 Chunk Size : 64K 
  
  Number   Major   Minor   RaidDevice State
this 5   835  active sync   /dev/sda3
  
   0 0   8   510  active sync   /dev/sdd3
   1 1   8   671  active sync
   2 2   8   832  active sync
   3 3   8   193  active sync   /dev/sdb3
   4 4   8   354  active sync   /dev/sdc3
   5 5   835  active sync   /dev/sda3

Note that it thinks there are 6 devices in the array, proving that
this is from before the shrink operation. The 1.0 metadata which is
currently being used says:

# mdadm --examine /dev/sda3
/dev/sda3:
  Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
 Array UUID : 3905b303:ca604b72:be5949c4:ab051b7a
   Name : 2
  Creation Time : Sun Jun  4 08:18:59 2006
 Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 618727264 (295.03 GiB 316.79 GB)
 Array Size : 618726528 (590.06 GiB 633.58 GB)
  Used Dev Size : 618726528 (295.03 GiB 316.79 GB)
Data Offset : 128 sectors
   Super Offset : 618727392 sectors
  State : active
Device UUID : e30176be:81a57e84:1f2aa206:9515150f

Update Time : Fri Sep 12 12:22:47 2014
   Checksum : bd6c9738 - correct
 Events : 1415

 Layout : near=2
 Chunk Size : 64K

   Device Role : Active device 1
   Array State :  ('A' == active, '.' == missing)

I am told it can be fixed by zeroing the old metadata:

# mdadm --zero-super --metadata=0.90 /dev/sda3

However, that requires the array to be stopped so I haven't verified
this yet.

I thought I would mention this on this bug report because although
it is not strictly a bug of grub-probe (grub-probe could be more
verbose about what it is reading though), it can be very confusing
as to why it is happening still with 1.0 metadata, and this bug is
the main search result I found during my research.

Is this worth separate bugs on grub-probe (wishlist: be more verbose
about which version of metadata is being found and where) and/or
mdadm (wishlist: zero old metadata after upgrading to new)?

Cheers,
Andy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "

Bug#684334: xen-hypervisor-4.0-amd64: Does not complete boot of dom0 kernel, extremely slow boot from BIOS RAM map onwards

[Andy Smith]

Package: xen-hypervisor-4.0-amd64
Version: 4.0.1-5.2
Severity: important
Tags: patch

I have a system based on a Supermicro X8DTH-i motherboard and a Xeon
E5506 CPU. It was previously running Debian lenny with
xen-hypervisor-3.2-1-amd64 / linux-image-2.6.26-2-xen-amd64 without
incident.

I upgraded it to Debian squeeze, with xen-hypervisor-4.0-amd64 /
linux-image-2.6.32-5-xen-amd64 and now it does not complete a boot of
the dom0 kernel.

I can boot it into a vanilla (or -xen) kernel directly on bare metal and
it seems okay with that.

This was originally reported upstream:
http://lists.xen.org/archives/html/xen-devel/2012-07/msg01663.html

I have since bisected their hg and found that the following changeset
fixes the problem for me:

http://xenbits.xen.org/hg/xen-4.0-testing.hg/rev/ab1fb1b8b569?revcount=480

I have attached Keir's changeset as
fix_bind_irq_vector_destination.patch.

Here follows a portion of my dom0 serial console output to the point
where booting becomes incredibly slow, and then the later "increasing
min_delta_ns" spam, just in case that helps someone searching their own
issue. The full logs are available in the xen-devel post linked above.

Thanks,
Andy

(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: 
done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128, offset_in_bytes 
258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-45) 
(dannf@xx) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sun May 6 
08:57:29 UTC 2012
[0.00] Command line: placeholder 
root=UUID=10aafd06-36d7-4181-a343-c542150957e3 ro console=tty0 console=hvc0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] released 0 pages of unused memory
[0.00] BIOS-provided physical RAM map:
[0.00]  Xen:  - 00099000 (usable)
[0.00]  Xen: 00099000 - 0010 (reserved)
[0.00]  Xen: 0010 - 4000 (usable)
[0.00]  Xen: bf78e000 - bf79 type 9
[0.00]  Xen: bf79 - bf79e000 (ACPI data)
[0.00]  Xen: bf79e000 - bf7d (ACPI NVS)
[0.00]  Xen: bf7d - bf7e (reserved)
[0.00]  Xen: bf7ec000 - c000 (reserved)
[0.00]  Xen: e000 - f000 (reserved)
[0.00]  Xen: fec0 - fec01000 (reserved)
[0.00]  Xen: fec8a000 - fec8b000 (reserved)
[0.00]  Xen: fec9a000 - fec9b000 (reserved)
[

At this point output stalls and it has appeared to hang, but if I wait a long 
time (minutes) some more output does appear:

[0.00]  Xen: fee0 - fee01

I waited tens of minutes and after it gets past the BIOS RAM map bit, booting 
proceeds at a normal speed until..

[  113.636747] 3w-9xxx: scsi0: AEN: INFO (0x04:0x000C): Initialize
started:unit=0, subunit=1.
[10065189777.645584] [ cut here ]
[10065189777.645584] [ cut here ]
[10065189777.645584] WARNING: at
/build/buildd-linux-2.6_2.6.32-45-amd64-FcX7RM/linux-2.6-2.6.32/debian/build/source_amd64_xen/kernel/time/clockevents.c:112
clockevents_program_event+0x26/0x7e()
[10065189777.645584] Hardware name: X8DTH-i/6/iF/6F
[10065189777.645584] Modules linked in: psmouse serio_raw snd_pcm
snd_timer snd soundcore snd_page_alloc joydev pcspkr evdev i2c_i801
i2c_core ioatdma button processor acpi_processor ext3 jbd mbcache
dm_mod sd_mod crc_t10dif usbhid hid uhci_hcd ehci_hcd 3w_9xxx
usbcore nls_base scsi_mod igb dca thermal thermal_sys [last
unloaded: scsi_wait_scan]
[10065189777.645584] Pid: 0, comm: swapper Not tainted
2.6.32-5-xen-amd64 #1
[10065189777.645584] Call Trace:
[10065189777.645584][] ?
clockevents_program_event+0x26/0x7e
[10065189777.645584]  [] ?
clockevents_program_event+0x26/0x7e
[10065189777.645584]  [] ?
warn_slowpath_common+0x77/0xa3
[10065189777.645584]  [] ?
clockevents_program_event+0x26/0x7e
[10065189777.645584]  [] ?
tick_dev_program_event+0x2d/0x95
[10065189777.645584]  [] ?
hrtimer_interrupt+0x15d/0x18d
[10065189777.645584]  [] ?
xen_timer_interrupt+0x34/0x

Bug#679051: ntp: Start of ntp during boot is delayed by 60 seconds at lockfile-touch step

[Andy Smith]

Package: ntp
Version: 1:4.2.6.p5+dfsg-2
Severity: minor

Dear Maintainer,

For a long while now (certainly through lenny and squeeze) I've noticed that on
boot of my Xen-based virtual machines, ntp seems to take an inordinately long
time to get started. I initially wrote this off as some peculiarity of Xen, as
ntp did start after about a minute and all seemed well.

I have just looked into it further by inserting a "set -x" in /etc/init.d/ntp
to see which part it was actually waiting on, and was surprised to find it was
lockfile-touch.

Here is a portion of the output of /etc/init.d/ntp up until the place where it
pauses:

+ /bin/echo -n Starting NTP server: ntpd
Starting NTP server: ntpd+ log_daemon_msg_post Starting NTP server ntpd
+ :
+ [ -z 101:104 ]
+ lock_ntpdate
+ [ -x /usr/bin/lockfile-create ]
+ lockfile-create /var/lock/ntpdate

At this point there is a pause of 60 seconds, and then:

+ LOCKTOUCHPID=1422
+ start-stop-daemon --start --quiet --oknodo --pidfile /var/run/ntpd.pid 
--startas /usr/sbin/ntpd -- -p /var/run/ntpd.pid -x -g -u 101:104
+ lockfile-touch /var/lock/ntpdate
+ status=0
+ unlock_ntpdate
+ [ -x /usr/bin/lockfile-create ]
+ kill 1422
+ lockfile-remove /var/lock/ntpdate
+ log_end_msg 0

...and so on.

In /etc/init.d/ntp there's this:

lock_ntpdate() {
if [ -x /usr/bin/lockfile-create ]; then
lockfile-create $LOCKFILE
lockfile-touch $LOCKFILE &
LOCKTOUCHPID="$!"
fi
}

I don't understand why, but it seems like the lockfile-touch part is waiting
for 60 seconds even though it's invoked with "&".

Subsequent stop/start of the daemon with invoke-rc.d after boot don't have any
such pause.

This VM, though running wheezy, is based on an image that was initially running
sarge and has been dist-upgraded through all releases over the years. I haven't
yet tested whether the same thing happens on a clean install of wheezy in the
same environment.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ntp depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.16.3
ii  libc62.13-33
ii  libcap2  1:2.22-1
ii  libedit2 2.11-20080614-5
ii  libopts251:5.12-0.1
ii  libssl1.0.0  1.0.1c-3
ii  lsb-base 4.1+Debian6
ii  netbase  5.0

Versions of packages ntp recommends:
ii  perl  5.14.2-12

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/default/ntp changed:
NTPD_OPTS='-x -g'

/etc/init.d/ntp changed:
set -x
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
DAEMON=/usr/sbin/ntpd
PIDFILE=/var/run/ntpd.pid
test -x $DAEMON || exit 5
if [ -r /etc/default/ntp ]; then
. /etc/default/ntp
fi
if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
fi
LOCKFILE=/var/lock/ntpdate
lock_ntpdate() {
if [ -x /usr/bin/lockfile-create ]; then
lockfile-create $LOCKFILE
lockfile-touch $LOCKFILE &
LOCKTOUCHPID="$!"
fi
}
unlock_ntpdate() {
if [ -x /usr/bin/lockfile-create ] ; then
kill $LOCKTOUCHPID
lockfile-remove $LOCKFILE
fi
}
RUNASUSER=ntp
UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
if test "$(uname -s)" = "Linux"; then
NTPD_OPTS="$NTPD_OPTS -u $UGID"
fi
case $1 in
start)
log_daemon_msg "Starting NTP server" "ntpd"
if [ -z "$UGID" ]; then
log_failure_msg "user \"$RUNASUSER\" does not exist"
exit 1
fi
lock_ntpdate
start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE 
--startas $DAEMON -- -p $PIDFILE $NTPD_OPTS
status=$?
unlock_ntpdate
log_end_msg $status
;;
stop)
log_daemon_msg "Stopping NTP server" "ntpd"
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
log_end_msg $?
rm -f $PIDFILE
;;
restart|force-reload)
$0 stop && sleep 2 && $0 start
;;
try-restart)
if $0 status >/dev/null; then
$0 restart
else
exit 0
fi
;;
reload)
exit 3
;;
status)
status_of_proc $DAEMON "NTP server"
;;
*)
echo "Usage: $0 
{start|stop|restart|try-restart|force-reload|status}"
exit 2
;;
esac

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a su

Bug#667594: support MODULES=most in initramfs even for a netboot

[Andy Smith]

Package: live-build
Version: 2.0.12-2
Severity: wishlist

If a net image is built, then currently
/usr/share/live/build/scripts/build/lb_chroot_hacks forces
chroot/etc/initramfs-tools/initramfs.conf to contain:

MODULES=netboot
BOOT=nfs
NFSROOT=auto

if it did not already have MODULES=netboot in it.

Despite doing a netboot, I would like the user to have access to any
local block devices at initramfs time in case the user wishes to use
persistence. With MODULES=netboot, the user will only ever see loop
devices at this point.

I have confirmed that setting MODULES=most still results in a working
netboot, and also does allow for persistence to work.

As far as I can see, lb_chroot_hacks happens after chroot_local-hooks or
-includes so it is not possible to provide my own
chroot/etc/initramfs-tools/initramfs.conf file.

At the moment, the messy workaround I have is to use a hook to ensure
that chroot/etc/initramfs-tools/initramfs.conf already contains:

MODULES=netboot
MODULES=most
BOOT=nfs
NFSROOT=auto

Since the file then already contains the string "MODULES=netboot",
lb_chroot_hacks does not modify it further.

Possibly the initramfs could just always have MODULES=most as it doesn't
make it very much bigger.

-- Package-specific info:

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages live-build depends on:
ii  debootstrap  1.0.26+squeeze1 Bootstrap a basic Debian system

Versions of packages live-build recommends:
ii  cpio  2.11-4 GNU cpio -- a program to manage ar
ii  gnu-fdisk 1.2.4-3Linux fdisk replacement based on l

Versions of packages live-build suggests:
pn  dosfstools (no description available)
ii  fakeroot 1.14.4-1Gives a fake root environment
pn  genisoimage(no description available)
ii  grub-legacy [grub]   0.97-64 GRand Unified Bootloader (Legacy v
pn  memtest86+ | memtest   (no description available)
pn  mtools (no description available)
pn  parted (no description available)
pn  squashfs-tools | gen   (no description available)
ii  sudo 1.7.4p4-2.squeeze.2 Provide limited super user privile
ii  uuid-runtime 2.17.2-9runtime components for the Univers
pn  win32-loader   (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#667435: live-boot-initramfs-tools: Using kernel parameter nfsopts results in an incorrect invocation of nfsmount

[Andy Smith]

Package: live-boot-initramfs-tools
Version: 2.0.15-1
Severity: wishlist

If the Linux kernel parameter "nfsopts" is used then scripts/live ends
up calling nfsmount incorrectly.

nfsmount is invoked like so:

nfsmount -o nolock -o ro ${NFSOPTS} "${NFSROOT}" "${mountpoint}" && rc=0 && 
break

If, for example, a kernel command line like this is used:

root=/dev/nfs hostname=rescue boot=live config 
nfsroot=192.168.80.243:/srv/rescue nfsopts=tcp

then that results in the following being invoked:

nfsmount -o nolock -o ro tcp 192.168.80.243:/srv/rescue /live/image && rc=0 
&& break

This is a syntax error and results in a failed boot. Hacking a "-o "
onto the front of NFSOPTS works, if NFSOPTS is set.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages live-boot-initramfs-tools depends on:
ii  busybox   1:1.17.1-8 Tiny utilities for small and embed
ii  initramfs-tools   0.98.8 tools for generating an initramfs
ii  udev  164-3  /dev/ and hotplug management daemo

live-boot-initramfs-tools recommends no packages.

live-boot-initramfs-tools suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#666565: /usr/lib/libreoffice/program/soffice: Menu items are not displayed with cairo 1.12

[Andy Smith]

Package: libcairo2
Version: 1.12.0-2
Followup-For: Bug #666565

Same problem here (similar to Luca Tettamanti's screenshot) with several
applications. I've noticed it in Epiphany, Nautilus and gnome-terminal. It's
most severe using Gmail in Epiphany, I guess because that involves a lot of
text redrawing.

The problem occurs with libcairo2 1.12.0-2, but not after downgrading
libcairo2, libcairo2-dev, libcairo-gobject2 and libcairo-script-interpreter2 to
1.10.2-7.

Using xserver-xorg-video-radeon 1:6.14.3-2.




-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcairo2 depends on:
ii  libc6  2.13-27
ii  libfontconfig1 2.8.0-3.1
ii  libfreetype6   2.4.9-1
ii  libpixman-1-0  0.24.4-1
ii  libpng12-0 1.2.47-2
ii  libx11-6   2:1.4.4-4
ii  libxcb-render0 1.8.1-1
ii  libxcb-shm01.8.1-1
ii  libxcb11.8.1-1
ii  libxrender11:0.9.6-2
ii  multiarch-support  2.13-27
ii  zlib1g 1:1.2.6.dfsg-2

libcairo2 recommends no packages.

libcairo2 suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: package libcairo2 is not installed



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#653074: fail2ban: initscript's status action does not set exit value correctly

[Andy Smith]

Package: fail2ban
Version: 0.8.4-3
Severity: minor

"invoke-rc.d fail2ban status" returns an exit value of zero even when
the service is not running:

$ invoke-rc.d fail2ban status && echo $?
Status of authentication failure monitor: fail2ban is not running
0

I think it would be better if it returned a failure value in the case
that fail2ban is not running.

I am marking this as "minor" instead of "wishlist" because LSB
recommends that init scripts return failure if the service is not
running.


-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fail2ban depends on:
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
ii  python-central  0.6.16+nmu1  register and build utility for Pyt

Versions of packages fail2ban recommends:
ii  iptables  1.4.8-3administration tools for packet fi
ii  whois 5.0.10 an intelligent whois client

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20100314cvs-1 simple mail user agent
pn  python-gamin   (no description available)

-- Configuration Files:
/etc/fail2ban/action.d/iptables-allports.conf changed [not included]

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651914: linux-image-2.6.32-5-xen-amd64: Poor IPv6 performance from Xen guest; GSO-related?

[Andy Smith]

On Tue, Dec 13, 2011 at 05:23:23AM +, Andy Smith wrote:
> What I'm noticing is the occasional incorrect checksum and "ICMPv6
> packet too big" messages seen above around 23:59:00.672905 and
> 23:59:01.240946 after a packet of length 2856.  These do not occur
> on the server with the e1000e driver, where all the packets top out
> at 1428. They always occur on the two servers with the igb driver
> where the poor throughput is observed.

Ah, could this be a duplicate of #630730? That was fixed in
2.6.32-39 while the machine in question is running 2.6.32-34.

#630730 seems to suggest that the bug would also have affected
e1000e, though. Another machine running 2.6.32-34 and using driver
e1000e is fine..

Thanks,
Andy



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651914: linux-image-2.6.32-5-xen-amd64: Poor IPv6 performance from Xen guest; GSO-related?

[Andy Smith]

Package: linux-2.6
Version: 2.6.32-38
Severity: important
Tags: ipv6

I have three squeeze servers running:

ii  linux-image-2.6.32-5-xen-amd64  2.6.32-38 Linux 2.6.32 for 64-bit 
PCs, Xen dom0 support

All three servers have Intel gigabit NICs, but one server uses the
e1000e driver and the other two use the igb driver.

They've been in production for around 6 months now and it seems like
somewhat embarrassingly we've only just now discovered a problem
with IPv6 performance on the two servers with the igb driver.

The problem manifests itself as awful TCP performance to a Xen domU,
on the order of 15-30KB/sec data transfer. Doing the same data
transfer from the server dom0 itself does not show the same issue,
and the expected tens of MB/sec data transfer is achieved.

Here's an example tcpdump from the dom0 host when the problem is
occurring:

# tcpdump -vpni bond0 'host 2a00:801:0:11::2'
[...]
23:59:00.672905 IP6 (hlim 55, next-header TCP (6) payload length: 4316) 
2a00:801:0:11::2.80 > 2001:db8:1f1:f240::2.35241: Flags [P.], cksum 0x62d3 
(incorrect -> 0x1c84), seq 15709:19993, ack 127, win 9, options [nop,nop,TS val 
1771553020 ecr 1086205224], length 4284
23:59:00.672987 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:db8:0:1f1::8 > 2a00:801:0:11::2: [icmp6 sum ok] ICMP6, packet too big, 
length 1240, mtu 1500
23:59:00.673161 IP6 (hlim 63, next-header TCP (6) payload length: 32) 
2001:db8:1f1:f240::2.35241 > 2a00:801:0:11::2.80: Flags [.], cksum 0x24e4 
(correct), ack 17137, win 716, options [nop,nop,TS val 1086205237 ecr 
1771553020], length 0
23:59:00.725659 IP6 (hlim 55, next-header TCP (6) payload length: 1460) 
2a00:801:0:11::2.80 > 2001:db8:1f1:f240::2.35241: Flags [.], cksum 0x16de 
(correct), seq 19993:21421, ack 127, win 9, options [nop,nop,TS val 1771553033 
ecr 1086205237], length 1428
23:59:00.725940 IP6 (hlim 63, next-header TCP (6) payload length: 44) 
2001:db8:1f1:f240::2.35241 > 2a00:801:0:11::2.80: Flags [.], cksum 0x25f5 
(correct), ack 17137, win 716, options [nop,nop,TS val 1086205250 ecr 
1771553020,nop,nop,sack 1 {19993:21421}], length 0
[...]
23:59:01.188463 IP6 (hlim 63, next-header TCP (6) payload length: 32) 
2001:db8:1f1:f240::2.35241 > 2a00:801:0:11::2.80: Flags [.], cksum 0x0105 
(correct), ack 25705, win 1073, options [nop,nop,TS val 1086205366 ecr 
1771553149], length 0
23:59:01.240946 IP6 (hlim 55, next-header TCP (6) payload length: 2888) 
2a00:801:0:11::2.80 > 2001:db8:1f1:f240::2.35241: Flags [P.], cksum 0x5d3f 
(incorrect -> 0xf9ef), seq 25705:28561, ack 127, win 9, options [nop,nop,TS val 
1771553162 ecr 1086205366], length 2856
23:59:01.241040 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:db8:0:1f1::8 > 2a00:801:0:11::2: [icmp6 sum ok] ICMP6, packet too big, 
length 1240, mtu 1500

2a00:801:0:11::2 is speedtest.tele2.net which helpfully hosts files
like http://speedtest.tele2.net/100MB.zip for testing purposes. The
above is the result of me using wget to download that file from a
domU on this server. The domU is at 2001:db8:1f1:f240::2 and the
dom0 is at 2001:db8:0:1f1::8.

What I'm noticing is the occasional incorrect checksum and "ICMPv6
packet too big" messages seen above around 23:59:00.672905 and
23:59:01.240946 after a packet of length 2856.  These do not occur
on the server with the e1000e driver, where all the packets top out
at 1428. They always occur on the two servers with the igb driver
where the poor throughput is observed.

This also does not occur when the IPv6 traffic is sourced on the dom0.
It's only when it's coming from a Xen domU.

I'm wondering if I am hitting something like this:

http://amailbox.org/mailarchive/linux-kvm/2010/2/2/6257539/thread

I have played with disabling and enabling GSO and checksums on every
interface I can (using ethtool), both in dom0 and domUs, and that makes
no difference.

Looking at linux-source-2.6.32 on squeeze, it does not have this
patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8e1e8a4779cb23c1d9f51e9223795e07ec54d77a

although I notice that this commit also touches e1000e where I am
not currently having any problems, even without this commit.

("severity: important" seemed correct because this renders IPv6
effectively unusable for large transfers to/from domUs)

-- Package-specific info:
** Version:
Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-34squeeze1) (da...@debian.org) 
(gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Thu May 19 01:16:47 UTC 2011

** Command line:
placeholder root=UUID=2586c7d6-dea0-43db-a809-3a131bbfb128 ro console=tty0 
console=hvc0

** Not tainted

** Kernel log:

** Model information
sys_vendor: Supermicro
product_name: X8DTN+-F
product_version: 1234567890
chassis_vendor: Supermicro
chassis_version: 1234567890
bios_vendor: American Megatrends Inc.
bios_version: 080016 
board_vendor: Supermicro
board_name: X8DTN+-F
board_version: 1234567890

** Loaded modules:
Module  Size  Used by
dm_

Bug#644116: ekeyd-egd-linux: Expose statistics on how much entropy clients are requesting

[Andy Smith]

Package: ekeyd-egd-linux
Version: 1.1.3-3
Severity: wishlist

It is currently difficult to tell which clients are requesting entropy
from the daemon and how much they are requesting, along with whether the
request could be completely satisfied.

This would be useful for capacity planning, as at the moment the only
way for me to know if my entropy keys are overused is:

- wait until clients start exhausting their entropy
- check there's no problem local to the client
- start sniffing network and/or tracing ekeyd-egd-linux process to see
  who is requesting what.

Exposing some stats (even just logging) would make life easier.

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ekeyd-egd-linux depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

ekeyd-egd-linux recommends no packages.

Versions of packages ekeyd-egd-linux suggests:
pn  ekeyd  (no description available)

-- Configuration Files:
/etc/default/ekeyd-egd-linux changed [not included]

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#590285: Patch to fix SQLite backslash-escaping issue

[Andy Smith]

Hi Matthijs,

I can confirm that the problem still exists in 2.9.22-6 (and
upstream), and the same patch will still apply to it.

Cheers,
Andy

On Tue, Aug 03, 2010 at 06:21:37PM +0200, Matthijs Mohlmann wrote:
> You're using version 2.9.21-2.1 which is currently the stable version. Can
> you try with 2.9.22-6 which is in testing to reproduce?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#590285: Patch to fix SQLite backslash-escaping issue

[Andy Smith]

This works for me and shouldn't have any effect on MySQL; haven't
looked at the pgsql backend though.

thanks
-- 
Call the SQL backend's escaping method instead of the generic sqlEscape().

Modify SQLite's escaping method to only escape single quotes, and to do so with
another single quote. SQLite doesn't do anything special with backslashes.
Fixes bug #590285.
Index: pdns-2.9.21.2/modules/gsqlitebackend/ssqlite.cc
===
--- pdns-2.9.21.2.orig/modules/gsqlitebackend/ssqlite.cc	2010-08-03 13:10:26.0 +
+++ pdns-2.9.21.2/modules/gsqlitebackend/ssqlite.cc	2010-08-03 13:15:04.0 +
@@ -141,10 +141,12 @@
 {
   std::string a;
   
+// The only thing that needs to be escaped in SQLite is a ', and it gets
+// escaped with another '
 for( std::string::const_iterator i = name.begin(); i != name.end(); ++i ) 
 {
-  if( *i == '\'' || *i == '\\' )
-a += '\\';
+  if( *i == '\'' )
+a += '\'';
 
   a += *i;
 }
Index: pdns-2.9.21.2/pdns/backends/gsql/gsqlbackend.cc
===
--- pdns-2.9.21.2.orig/pdns/backends/gsql/gsqlbackend.cc	2010-08-03 13:10:39.0 +
+++ pdns-2.9.21.2/pdns/backends/gsql/gsqlbackend.cc	2010-08-03 13:12:18.0 +
@@ -385,7 +385,7 @@
 {
   char output[1024];
   snprintf(output,sizeof(output)-1,d_InsertRecordQuery.c_str(),
-	   sqlEscape(r.content).c_str(),
+	   d_db->escape(r.content).c_str(),
 	   r.ttl, r.priority,
 	   sqlEscape(r.qtype.getName()).c_str(),
 	   r.domain_id, toLower(sqlEscape(r.qname)).c_str()); 

Bug#590285: pdns-backend-sqlite has incorrect handling of backslash escapes

[Andy Smith]

Package: pdns-backend-sqlite
Version: 2.9.21.2-1
Severity: important

Backslash escapes are not supported by sqlite
(http://www.sqlite.org/lang_expr.html "Literal Values") but
pdns-backend-sqlite will insert them, and tries to escape single quotes
in SQL with them.

http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/gsqlitebackend/ssqlite.cc?rev=210#L136

As a result, a BIND format zone file that uses \032 to introduce a space
will, when AXFRed to pdns with sqlite, insert a record like "some\\
string\\ with\\ spaces". This will not be returned correctly in DNS.

If you want to see this in action:

BIND:

$ dig +noall +answer -t ptr _http._tcp.atomic-x.co.uk @a.authns.bitfolk.com.
_http._tcp.atomic-x.co.uk. 1800 IN  PTR 
atomic-x\.co\.uk\032Homepage._http._tcp.atomic-x.co.uk.
_http._tcp.atomic-x.co.uk. 1800 IN  PTR 
atomic-x\.co\.uk\032Webmail._http._tcp.atomic-x.co.uk.

PDNS:

$ dig +noall +answer -t ptr _http._tcp.atomic-x.co.uk @b.authns.bitfolk.com.
_http._tcp.atomic-x.co.uk. 1800 IN  PTR atomic-x\.co\.uk\\\000.
_http._tcp.atomic-x.co.uk. 1800 IN  PTR atomic-x\.co\.uk\\\000.

Since escaping single quotes is a security precaution, it may also be
possible to introduce a security problem in this manner.

-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-23-xen (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages pdns-backend-sqlite depends on:
ii  libc6  2.7-18lenny4  GNU C Library: Shared libraries
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libsqlite0 2.8.17-4  SQLite shared library
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  pdns-server2.9.21.2-1extremely powerful and versatile n
ii  sqlite 2.8.17-4  command line interface for SQLite
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

pdns-backend-sqlite recommends no packages.

pdns-backend-sqlite suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#574568: lurker: "zap" link to delete email from archive is javascript GET, causes bad interactions with crawlers

[Andy Smith]

On Fri, Mar 19, 2010 at 03:16:06AM +, Andy Smith wrote:
> It might also be nice to document a simple way to remove the link
> entirely. This looks promising:
> 
> http://www.terpstra.ca/lurker/message/20060423.233328.bd5efdb8.en.html

Just a note that the above (deleting the link from the .xsl file)
seems to work fine if you just want the link gone.

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#574568: lurker: "zap" link to delete email from archive is javascript GET, causes bad interactions with crawlers

[Andy Smith]

Package: lurker
Version: 2.1-13
Severity: minor

By default, lurker includes a javascript image link on each email that
looks something like this:

javascript:trash('http://lists.example.com/lurker/zap/20100318.113155.0e0de092.en.html');

Because this link just appears to a non-human client like any other page
link, crawlers such as googlebot will attempt to follow it.

At the very least this causes log spam of "Password:" prompt and then
failed password notification, and of course the wasted bandwidth of
having the bots follow all these links, which appear on every page of
the archive.

It may be possible to keep bots out with a suitable robots.txt, e.g.:

User-agent: *
Disallow: 
Crawl-delay: 5
Disallow: /lurker/zap/

However, this seems to have limited effect even against googlebot.

In general using simple GET URLs for things which have an action (i.e.,
deleting an email from the archive) is bad form. This should really be
done as a proper form via POST, then bots would ignore it.

It might also be nice to document a simple way to remove the link
entirely. This looks promising:

http://www.terpstra.ca/lurker/message/20060423.233328.bd5efdb8.en.html

Cheers,
Andy

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-xen-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lurker depends on:
ii  adduser3.110 add and remove users and groups
ii  apache22.2.9-10+lenny6   Apache HTTP Server metapackage
ii  apache2-mpm-prefork [h 2.2.9-10+lenny6   Apache HTTP Server - traditional n
ii  debconf [debconf-2.0]  1.5.24Debian configuration management sy
ii  libc6  2.7-18lenny2  GNU C Library: Shared libraries
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libmimelib1c2a 4:3.5.9-5 KDE mime library
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  passwd 1:4.1.1-6+lenny1  change and administer password and
ii  ucf3.0016Update Configuration File: preserv
ii  xsltproc   1.1.24-2  XSLT command line processor
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

lurker recommends no packages.

Versions of packages lurker suggests:
ii  gnupg 1.4.9-3+lenny1 GNU privacy guard - a free PGP rep
ii  mailman   1:2.1.11-11Powerful, web-based mailing list m

-- debconf information excluded

-- 
http://bitfolk.com/ -- No-nonsense VPS hosting

"It is I, Simon Quinlank.  The chief conductor on the bus that is called
 hobby." -- Simon Quinlank


signature.asc
Description: Digital signature

Bug#557576: Postinstallation of 'locales' fails because of missing locale-gen

[Andy Smith]

Package: locales
Version: 2.10.1-7
Severity: important

Whilst upgrading from lenny to squeeze, I cam across the following error during 
postinst of 'locales':-

Setting up locales (2.10.1-7) ...
/var/lib/dpkg/info/locales.postinst: line 64: locale-gen: command not found
dpkg: error processing locales (--configure):
 subprocess installed post-installation script returned error exit status 127

p.d.o says locale-gen should be in locales, but a 'dpkg -L locales' doesn't 
show a locale-gen.

Apologies if this has been submitted already, but I did search and couldn't 
find an existing
bug.

Cheers,

Andy.
--
Andy Smith
+44 7538 089864 | +44 1302 638000 | http://andys.org.uk/ | PGP: 0xA762A666

-- System Information:
Debian Release: 5.0.3
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages locales depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii  libc6 [glibc-2.10-1]  2.10.1-7   GNU C Library: Shared libraries

locales recommends no packages.

locales suggests no packages.

-- debconf information:
  locales/default_environment_locale: None
  locales/locales_to_be_generated: en_GB.UTF-8 UTF-8



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513842: [Pkg-xen-devel] Bug#513842: xen-utils-common: please make pygrub available

[Andy Smith]

Hi Anand,

On Mon, Feb 02, 2009 at 04:25:47AM +1100, Anand Kumria wrote:
> It would be very useful it /usr/bin/pygrub was available -- it should be a 
> symlink (or wrapper) that points to the real version in the Xen hypervisor.

Isn't this already accomplished by using
/usr/lib/xen-default/bin/pygrub?

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#499366: "4gb seg fixup" not fixed in 2.7-14?

[Andy Smith]

On Wed, Oct 15, 2008 at 01:49:11PM +0200, [EMAIL PROTECTED] wrote:
> Andy Smith <[EMAIL PROTECTED]> wrote:
> >Unfortunately ldconfig will not allow the same hwconfig twice.
> >
> >For now I reverted it to 0 and rebooted; this has got rid of the
> >warnings.  I will just have to bear it in mind for when I can again
> >use the Lenny kernel for this Lenny domU I suppose.
> 
> That did it, thanks!
> 
> Luckily I managed without rebooting. I just edited libc6-xen.conf, ran 
> ldconfig and restarted several processes and services.  Now only init 
> (pid 1) complains once in a while.

You can re-exec init with "telinit u" to fix this.

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#499366: "4gb seg fixup" not fixed in 2.7-14?

[Andy Smith]

On Wed, Oct 15, 2008 at 08:56:57AM +0200, Aurelien Jarno wrote:
> On Tue, Oct 14, 2008 at 09:20:12PM +0000, Andy Smith wrote:
> > Thanks Bastian.  What is your best advice for a workaround since I
> > can't change dom0 from the packaged Etch hypervisor and current Lenny
> > kernels do not boot with that hypervisor?
> 
> Could you try to edit /etc/ld.so.conf.d/libc6-xen.conf, and add back
> the line "hwcap 0 nosegneg", while keeping the line "hwcap 1 nosegneg"?

Unfortunately ldconfig will not allow the same hwconfig twice.

For now I reverted it to 0 and rebooted; this has got rid of the
warnings.  I will just have to bear it in mind for when I can again
use the Lenny kernel for this Lenny domU I suppose.

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#499366: "4gb seg fixup" not fixed in 2.7-14?

[Andy Smith]

On Tue, Oct 14, 2008 at 11:06:18PM +0200, Bastian Blank wrote:
> On Tue, Oct 14, 2008 at 04:15:29PM +0200, Aurelien Jarno wrote:
> > The proposed patch has been applied. But maybe it is wrong. Waldi, could
> > you please have a look? I have no Xen machine.
> 
> The patch is correct. The problem is the "wrong" capability definition
> in the Etch kernel. But fixing the package to work together with the
> Lenny kernel is more important. Maybe I should fix the kernel in Etch
> also.

Thanks Bastian.  What is your best advice for a workaround since I
can't change dom0 from the packaged Etch hypervisor and current Lenny
kernels do not boot with that hypervisor?

Cheers,
Andy



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#499366: "4gb seg fixup" not fixed in 2.7-14?

[Andy Smith]

Hi,

Ever since updating to libc6-xen 2.7-14 I am seeing the "4gb seg fixup" 
warnings:

Oct 14 10:43:34 cacti kernel: printk: 11610 messages suppressed.
Oct 14 10:43:34 cacti kernel: 4gb seg fixup, process head (pid 5876), cs:ip 
73:b7ebb33a
Oct 14 10:43:38 cacti init: Trying to re-exec init
Oct 14 10:43:39 cacti kernel: printk: 1038209 messages suppressed.
Oct 14 10:43:39 cacti kernel: 4gb seg fixup, process libc6.postinst (pid 6135), 
cs:ip 73:b7e5b948
Oct 14 10:43:44 cacti kernel: printk: 522190 messages suppressed.
Oct 14 10:43:44 cacti kernel: 4gb seg fixup, process dpkg (pid 6179), cs:ip 
73:b7e75eb7
Oct 14 10:43:49 cacti kernel: printk: 645077 messages suppressed.
Oct 14 10:43:49 cacti kernel: 4gb seg fixup, process dpkg (pid 6356), cs:ip 
73:b7e6eeb7
Oct 14 10:43:54 cacti kernel: printk: 471625 messages suppressed.
Oct 14 10:43:54 cacti kernel: 4gb seg fixup, process dpkg (pid 6374), cs:ip 
73:b7df1860
Oct 14 10:44:00 cacti kernel: printk: 62714 messages suppressed.

[...]

Oct 14 11:21:41 cacti kernel: 4gb seg fixup, process apache2 (pid 9543), cs:ip 
73:b7e0450e
Oct 14 11:21:59 cacti kernel: printk: 58 messages suppressed.
Oct 14 11:21:59 cacti kernel: 4gb seg fixup, process apache2 (pid 9544), cs:ip 
73:b7ee0598
Oct 14 11:21:59 cacti kernel: 4gb seg fixup, process apache2 (pid 9544), cs:ip 
73:b7ee32e5
Oct 14 11:23:27 cacti kernel: 4gb seg fixup, process sshd (pid 9545), cs:ip 
73:b7ba9eb7
Oct 14 11:24:01 cacti kernel: printk: 1972 messages suppressed.
Oct 14 11:24:01 cacti kernel: 4gb seg fixup, process sh (pid 9548), cs:ip 
73:b7e4e8c0
Oct 14 11:24:01 cacti kernel: 4gb seg fixup, process sh (pid 9548), cs:ip 
73:b7f1d810
Oct 14 11:24:01 cacti kernel: 4gb seg fixup, process sh (pid 9548), cs:ip 
73:b7e4feb7
Oct 14 11:24:01 cacti kernel: 4gb seg fixup, process sh (pid 9548), cs:ip 
73:b7f1d810
Oct 14 11:24:01 cacti kernel: 4gb seg fixup, process sh (pid 9548), cs:ip 
73:b7dba967
Oct 14 11:24:01 cacti kernel: 4gb seg fixup, process sh (pid 9548), cs:ip 
73:b7dba96a
Oct 14 11:24:02 cacti kernel: printk: 663233 messages suppressed.
Oct 14 11:24:02 cacti kernel: 4gb seg fixup, process php (pid 9564), cs:ip 
73:b7a08f44

Restarting things doesn't help, restarting the domU doesn't help.
Is there something I have missed or doesn't this update actually fix
it?

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#461644: Also affects Red Hat and probably Fedora too

[Andy Smith]

Ask followed up to say that he'd opened a bug with Red Hat on this
back in January '07, so it's by no means a Debian issue:

https://bugzilla.redhat.com/show_bug.cgi?id=223947

As it says, using tap:aio to access the LV is one possible
workaround (but not something I want to do).

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#461644: linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems

[Andy Smith]

Package: linux-image-2.6.18-5-xen-686
Version: 2.6.18.dfsg.1-17
Severity: normal

I have several machines using LVM on (md) raid10 on 4 SATA disks.  When
I create an LV and export it to a Xen domU as a whole disk, as soon as
that domU tries to partition or write to the disk I get many of these
errors in dom0:

Jan 19 04:42:47 corona kernel: raid10_make_request bug: can't convert block 
across chunks or bigger than 64k 309585274 4
Jan 19 04:42:47 corona last message repeated 2 times
Jan 19 04:42:47 corona kernel: raid10_make_request bug: can't convert block 
across chunks or bigger than 64k 305922559 4
Jan 19 04:42:47 corona last message repeated 3 times
Jan 19 04:42:47 corona kernel: raid10_make_request bug: can't convert block 
across chunks or bigger than 64k 309585274 4
Jan 19 04:42:48 corona last message repeated 2 times

Continued attempts to use the disk in the domU results in i/o error and
the partition being remounted read-only.

This does not occur when the LV is exported as a block device.  It
happens on all of my machines which run Etch and LVM on software RAID.
It does not happen on my machines which run Etch and LVM on hardware
RAID.  All of my software RAID boxes use raid10, so I haven't had chance
to try it in different RAID levels.

Also please note that although below says I am running 2.6.18-4-xen-686,
that's because I rebooted into it to see if the problem had been
introduced in -5.  It happens in both -4 and -5.

/etc/mdadm/mdadm.conf:
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST corona

# instruct the monitoring daemon where to send mail alerts
MAILADDR [EMAIL PROTECTED]

# definitions of existing MD arrays
ARRAY /dev/md1 level=raid10 num-devices=4 
UUID=6eb313b7:a4cb7ef0:511ed56b:bbe6f809
ARRAY /dev/md2 level=raid1 num-devices=4 
UUID=d4712241:f57750d0:a05dcc72:f711af28
ARRAY /dev/md3 level=raid10 num-devices=4 
UUID=bfc032df:afb6b003:57c24ef0:12cc371f
ARRAY /dev/md5 level=raid10 num-devices=4 
UUID=75de1b2e:db3428ca:a3d746a5:86201486

# This file was auto-generated on Wed, 04 Apr 2007 02:25:06 +
# by mkconf $Id: mkconf 261 2006-11-09 13:32:35Z madduck $

My single LVM PV is on /dev/md5:

$ sudo mdadm -D /dev/md5
/dev/md5:
Version : 00.90.03
  Creation Time : Wed Apr  4 00:07:31 2007
 Raid Level : raid10
 Array Size : 618727168 (590.06 GiB 633.58 GB)
Device Size : 309363584 (295.03 GiB 316.79 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 5
Persistence : Superblock is persistent

Update Time : Sun Jan 20 04:37:28 2008
  State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

 Layout : near=2, far=1
 Chunk Size : 64K

   UUID : 75de1b2e:db3428ca:a3d746a5:86201486
 Events : 0.453

Number   Major   Minor   RaidDevice State
   0   850  active sync   /dev/sda5
   1   8   211  active sync   /dev/sdb5
   2   8   372  active sync   /dev/sdc5
   3   8   533  active sync   /dev/sdd5

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-xen-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-5-xen-686 depends on:
ii  initramfs-tools 0.85htools for generating an initramfs
ii  linux-modules-2.6.18-5- 2.6.18.dfsg.1-17 Linux 2.6.18 modules on i686

Versions of packages linux-image-2.6.18-5-xen-686 recommends:
ii  libc6-xen  2.3.6.ds1-13etch4 GNU C Library: Shared libraries [X

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#452721: xen-utils-common: "xendomains" does not restore domains in same order as it would start them

[Andy Smith]

Package: xen-utils-common
Version: 3.0.3-0-2
Severity: wishlist

The "xendomains" init script will start domains according to the order
of config files found in /etc/xen/auto/*.  I use this so that, in the
event of a hard reboot, the more important domains will start first.

Some of these contain essential services like DNS resolvers, slapd and
so on, and since starting xen domains happens in series and can be quite
time consuming, it is rather useful to have the around first before
everything else starts up.

Unfortunately though it seems that when restoring domains from a save
file in /var/lib/xen/save/* the ordering is alphabetical.

It would be great if restoring from savefile could be ordered in the
same way as starting from cold.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-xen-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages xen-utils-common depends on:
ii  lsb-base   3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii  udev   0.105-4   /dev/ and hotplug management daemo

xen-utils-common recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#451297: linux-image-2.6.18-5-xen-686: kernel page allocation failure causes networking freeze

[Andy Smith]

Package: linux-image-2.6.18-5-xen-686
Version: 2.6.18.dfsg.1-13etch4
Severity: grave
Justification: renders package unusable

Hi,

In the past couple of months two of my Xen dom0 servers have, after about
a week of uptime, been reporting kernel errors like so:

Nov 14 18:57:58 corona kernel: swapper: page allocation failure. order:0, 
mode:0x20
Nov 14 18:57:58 corona kernel:  [] __alloc_pages+0x261/0x275
Nov 14 18:57:58 corona kernel:  [] cache_alloc_refill+0x297/0x493
Nov 14 18:57:58 corona kernel:  [] hypervisor_callback+0x3d/0x48
Nov 14 18:57:58 corona kernel:  [] handle_diacr+0x58/0xad
Nov 14 18:57:58 corona kernel:  [] kmem_cache_alloc+0x3b/0x54
Nov 14 18:57:58 corona kernel:  [] alloc_skb_from_cache+0x48/0x110
Nov 14 18:57:58 corona kernel:  [] __alloc_skb+0x6c/0x70
Nov 14 18:57:58 corona kernel:  [] netif_be_start_xmit+0x118/0x3d5
Nov 14 18:57:58 corona kernel:  [] dev_hard_start_xmit+0x19a/0x1f0
Nov 14 18:57:58 corona kernel:  [] dev_queue_xmit+0x247/0x2e3
Nov 14 18:57:58 corona kernel:  [] br_dev_queue_push_xmit+0x155/0x178 
[bridge]
Nov 14 18:57:58 corona kernel:  [] br_forward_finish+0x43/0x45 
[bridge]
Nov 14 18:57:58 corona kernel:  [] br_nf_forward_finish+0xc6/0xcc 
[bridge]
Nov 14 18:57:58 corona kernel:  [] br_nf_forward_arp+0x116/0x128 
[bridge]
Nov 14 18:57:58 corona kernel:  [] nf_iterate+0x30/0x61
Nov 14 18:57:58 corona kernel:  [] br_forward_finish+0x0/0x45 [bridge]
Nov 14 18:57:58 corona kernel:  [] nf_hook_slow+0x3a/0x90
Nov 14 18:57:58 corona kernel:  [] br_forward_finish+0x0/0x45 [bridge]
Nov 14 18:57:58 corona kernel:  [] __br_forward+0x46/0x57 [bridge]
Nov 14 18:57:58 corona kernel:  [] br_forward_finish+0x0/0x45 [bridge]
Nov 14 18:57:58 corona kernel:  [] br_flood+0x65/0x9d [bridge]
Nov 14 18:57:58 corona kernel:  [] __br_forward+0x0/0x57 [bridge]
Nov 14 18:57:58 corona kernel:  [] br_flood_forward+0xa/0xc [bridge]
Nov 14 18:57:58 corona kernel:  [] __br_forward+0x0/0x57 [bridge]
Nov 14 18:57:58 corona kernel:  [] br_handle_frame_finish+0x80/0xcf 
[bridge]
Nov 14 18:57:58 corona kernel:  [] br_handle_frame+0x15f/0x179 
[bridge]
Nov 14 18:57:58 corona kernel:  [] netif_receive_skb+0x25e/0x357
Nov 14 18:57:58 corona kernel:  [] e1000_clean_rx_irq_ps+0x4a6/0x569 
[e1000]
Nov 14 18:57:58 corona kernel:  [] e1000_clean+0x69/0x136 [e1000]
Nov 14 18:57:58 corona kernel:  [] net_rx_action+0x96/0x18f
Nov 14 18:57:58 corona kernel:  [] __do_softirq+0x5e/0xc3
Nov 14 18:57:58 corona kernel:  [] do_softirq+0x3a/0x4a
Nov 14 18:57:58 corona kernel:  [] do_IRQ+0x48/0x53
Nov 14 18:57:58 corona kernel:  [] evtchn_do_upcall+0x64/0x9b
Nov 14 18:57:58 corona kernel:  [] hypervisor_callback+0x3d/0x48
Nov 14 18:57:58 corona kernel:  [] raw_safe_halt+0x8c/0xaf
Nov 14 18:57:58 corona kernel:  [] xen_idle+0x22/0x2e
Nov 14 18:57:58 corona kernel:  [] cpu_idle+0x91/0xab
Nov 14 18:57:58 corona kernel:  [] start_kernel+0x378/0x37f
Nov 14 18:57:58 corona kernel: Mem-info:
Nov 14 18:57:58 corona kernel: DMA per-cpu:
Nov 14 18:57:58 corona kernel: cpu 0 hot: high 186, batch 31 used:30
Nov 14 18:57:58 corona kernel: cpu 0 cold: high 62, batch 15 used:55
Nov 14 18:57:58 corona kernel: DMA32 per-cpu: empty
Nov 14 18:57:58 corona kernel: Normal per-cpu: empty
Nov 14 18:57:58 corona kernel: HighMem per-cpu:
Nov 14 18:57:58 corona kernel: cpu 0 hot: high 90, batch 15 used:75
Nov 14 18:57:58 corona kernel: cpu 0 cold: high 30, batch 7 used:6
Nov 14 18:57:58 corona kernel: Free pages:   34404kB (33228kB HighMem)
Nov 14 18:57:58 corona kernel: Active:146620 inactive:39375 dirty:10 
writeback:0 unstable:0 free:8601 slab:19722 mapped:2949 pagetables:254
Nov 14 18:57:58 corona kernel: DMA free:1176kB min:3452kB low:4312kB 
high:5176kB active:454452kB inactive:122052kB present:745464kB
pages_scanned:0 all_unreclaimable? no
Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 204
Nov 14 18:57:58 corona kernel: DMA32 free:0kB min:0kB low:0kB high:0kB 
active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 204
Nov 14 18:57:58 corona kernel: Normal free:0kB min:0kB low:0kB high:0kB 
active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 1632
Nov 14 18:57:58 corona kernel: HighMem free:33228kB min:204kB low:444kB 
high:684kB active:132028kB inactive:35448kB present:208904kB
pages_scanned:0 all_unreclaimable? no
Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 0
Nov 14 18:57:58 corona kernel: DMA: 0*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 
0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1176kB
Nov 14 18:57:58 corona kernel: DMA32: empty
Nov 14 18:57:58 corona kernel: Normal: empty
Nov 14 18:57:58 corona kernel: HighMem: 1353*4kB 1691*8kB 439*16kB 129*32kB 
17*64kB 8*128kB 4*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
33228kB
Nov 14 18:57:58 corona kernel: Swap cache: add 23, delete 0, find 0/0, race 0+0
Nov 14 18:57:58 corona kernel: Free swap  = 1975580kB
Nov 14 18:57:58 coron

Bug#412743: Info received (I am also experiencing this, using sarge apt-cacher with etch and ubuntu clients)

[Andy Smith]

I should also point out, my /etc/apt/sources.list is:

deb http://apt-cacher.bitfolk.com/cache/ftp.uk.debian.org/debian/   
etchmain contrib
deb-src http://apt-cacher.bitfolk.com/cache/ftp.uk.debian.org/debian/   
etchmain contrib

deb http://apt-cacher.bitfolk.com/cache/security.debian.org/
etch/updatesmain contrib

deb http://apt-cacher.bitfolk.com/cache/ftp.uk.debian.org/debian-volatile/  
etch/volatile   main contrib

Removing the "apt-cacher.bitfolk.com/cache/" part makes this problem
go away.

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#412743: I am also experiencing this, using sarge apt-cacher with etch and ubuntu clients

[Andy Smith]

Package: apt-cacher
Version: 0.9.4sarge1
Followup-For: Bug #412743

I am experiencing the same thing after an upgrade of a client to etch
(server with apt-cacher still runs sarge):

[EMAIL PROTECTED] stats]$ sudo aptitude dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
The following packages will be upgraded:
  recode
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 179kB of archives. After unpacking 193kB will be freed.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
Get:1 http://apt-cacher.bitfolk.com etch/main recode 3.6-12 [179kB]
Fetched 179kB in 0s (1155kB/s)
E: Failed to fetch 
http://apt-cacher.bitfolk.com/cache/ftp.uk.debian.org/debian/pool/main/r/recode/recode_3.6-12_i386.deb:
 Size mismatch

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.19curacao3xenu
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#417937: debian-installer does not support raid10 for partitioning

[Andy Smith]

Package: installation-reports

Boot method: CD
Image version: http://cdimage.debian.org/cdimage/etch_di_rc2/i386/iso-cd/
Date: 03 Apr 2007

Machine: Supermicro PDSMi-based rackmount system
Processor: Core2Duo Xeon 2.4GHz
Memory: 4GiB
Partitions: No partitions were created because didn't get that far

Output of lspci -nn and lspci -vnn: Ditto

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Installer offers to create software RAID arrays from partitions
marked as RAID members, but does not support raid10 which was a
show-stopper for the installation of this server with 4 disks,
intended to be almost entirely on raid10.

Switching to a terminal and issuing lsmod I could see the raid0, 1
and 5 modules loaded but no raid10.  raid10 module was also not
present in the filesystem so I assume it is not supported.

Of course it is not possible to boot from raid10, which is why I
intended to create a small /boot in raid1, but I wanted everything
else in raid10.

In the end I booted from a livecd and installed by debootstrap.

Obviously a bit of a fringe case, but "it would be nice".


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#368617: This seems to be an issue for Xen also

[Andy Smith]

I am also seeing this every time I reboot a Xen domU on Etch:

[...]
IF-MIB::ifDescr.24 = STRING: v-deep
IF-MIB::ifDescr.28 = STRING: v-isst
IF-MIB::ifDescr.34 = STRING: v-light
IF-MIB::ifDescr.35 = STRING: v-light
IF-MIB::ifDescr.36 = STRING: v-light
[...]
IF-MIB::ifAdminStatus.24 = INTEGER: up(1)
IF-MIB::ifAdminStatus.28 = INTEGER: up(1)
IF-MIB::ifAdminStatus.34 = INTEGER: down(2)
IF-MIB::ifAdminStatus.35 = INTEGER: down(2)
IF-MIB::ifAdminStatus.36 = INTEGER: up(1)

The domU corresponding to v-light there was rebooted twice, and is
now using ifindex 36.  The other two instances of that interface are
not visible in "ifconfig -a" output nor in "ip link" output.

These go away if I restart snmpd.

This makes bandwidth use stats a bit tricky since most tools
continue using same interface index if it exists and has correct
name.

snmpd 5.2.3-7

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#115767: I see this too on x86-xen running etch

[Andy Smith]

On Mon, Apr 24, 2006 at 08:04:27PM +, Andy Smith wrote:
> I'll look into running another sshd on a higher port for my own
> needs and strace one on port 22.  The dictionary attacks should
> still trigger this eventually.

Okay, I did this, and ~5 days later a massive dictionary attack
triggered the problem:

# grep -c 'sshd.*Invalid user.*from 62.193.245.215' /var/log/auth.log
1902
# grep -B 4 6372 /var/log/auth.log
Apr 29 13:57:06 ruminant sshd[443]: Invalid user qmailr from 62.193.245.215
Apr 29 13:57:06 ruminant sshd[445]: Invalid user qmails from 62.193.245.215
Apr 29 13:57:07 ruminant sshd[447]: Invalid user r00t from 62.193.245.215
Apr 29 13:57:07 ruminant sshd[449]: Invalid user r00t from 62.193.245.215
Apr 29 13:57:07 ruminant sshd[6372]: fatal: Couldn't obtain random bytes (error 
604389476)
# ls -lh /var/log/ssh-strace/ssh-strace.log.6372
-rw-r--r-- 1 root root 23M Apr 29 13:57 /var/log/ssh-strace/ssh-strace.log.6372
# tail -40 /var/log/ssh-strace/ssh-strace.log.6372
13:57:07 write(7, "\0\0\2Y\n\n\n\nPort 22\n\n\n\nProtocol 2\n\nH"..., 609) = 609
13:57:07 close(7)   = 0
13:57:07 close(8)   = 0
13:57:07 getpid()   = 6372
13:57:07 getpid()   = 6372
13:57:07 close(4)   = 0
13:57:07 select(8, [3 5], NULL, NULL, NULL) = 1 (in [5])
13:57:07 --- SIGCHLD (Child exited) @ 0 (0) ---
13:57:07 waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], WNOHANG) = 449
13:57:07 waitpid(-1, 0xbfffeb5c, WNOHANG) = -1 ECHILD (No child processes)
13:57:07 rt_sigaction(SIGCHLD, NULL, {0x804d470, [], 0}, 8) = 0
13:57:07 sigreturn()= ? (mask now [])
13:57:07 close(5)   = 0
13:57:07 select(8, [3], NULL, NULL, NULL) = 1 (in [3])
13:57:07 accept(3, {sa_family=AF_INET6, sin6_port=htons(40492), 
inet_pton(AF_INET6, ":::62.193.245.215", &sin6_addr), sin6_flowinfo=0, 
sin6_scope_id=0}, [28]) = 4
13:57:07 fcntl64(4, F_GETFL)= 0x2 (flags O_RDWR)
13:57:07 pipe([5, 6])   = 0
13:57:07 socketpair(PF_FILE, SOCK_STREAM, 0, [7, 8]) = 0
13:57:07 fork() = 451
13:57:07 close(6)   = 0
13:57:07 write(7, "\0\0\2b\0", 5)   = 5
13:57:07 write(7, "\0\0\2Y\n\n\n\nPort 22\n\n\n\nProtocol 2\n\nH"..., 609) = 609
13:57:07 close(7)   = 0
13:57:07 close(8)   = 0
13:57:07 getpid()   = 6372
13:57:07 getpid()   = 6372
13:57:07 getpid()   = 6372
13:57:07 getpid()   = 6372
13:57:07 getpid()   = 6372
13:57:07 time([1146319027]) = 1146319027
13:57:07 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=56, ...}) = 0
13:57:07 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=56, ...}) = 0
13:57:07 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=56, ...}) = 0
13:57:07 getpid()   = 6372
13:57:07 socket(PF_FILE, SOCK_DGRAM, 0) = 6
13:57:07 fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
13:57:07 connect(6, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
13:57:07 send(6, "<34>Apr 29 13:57:07 sshd[6372]: "..., 85, MSG_NOSIGNAL) = 85
13:57:07 close(6)   = 0
13:57:07 exit_group(255)= ?

I can't see anything that jumps out as being wrong in any of the
strace logs for the forked children 451, 449, 447, 445 etc..  Any
ideas?

Cheers,
Andy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#115767: I see this too on x86-xen running etch

[Andy Smith]

On Sun, Apr 16, 2006 at 11:42:00AM -0400, Justin Pryzby wrote:
> What about strace without -f?  I just tested with strace -o /dev/null sh, and 
> I
> am still able to run sudo.  It isn't clear to me whether this will catch the
> problem; it depends on the server crashing (you said it did, no?) and sshd not
> forking before it tries to read urandom. 

I restarted it without -f, and sshd stayed up for about 6 days.
Unfortunately when I look at the log file its mtime is about 6 days
ago.. so I doubt very much it has anything useful in it.

I'll look into running another sshd on a higher port for my own
needs and strace one on port 22.  The dictionary attacks should
still trigger this eventually.

Cheers,
Andy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#115767: I see this too on x86-xen running etch

[Andy Smith]

> On Fri, Apr 14, 2006 at 03:58:09PM +0000, Andy Smith wrote:
> > Okay, I'm now running:
> > 
> > $ sudo strace -ff -o /var/log/ssh-strace/ssh-strace.log /usr/sbin/sshd

Unfortunately now whenever I log in via an sshd that is running
under strace, none of my setuid binaries work.  For sudo this is a
showstopper: all I get is "sudo: must be setuid root".  Since I
still need to use this machine I've had to stop running sshd under
strace. :(

If anyone is interested in debugging this I can set you up a 64M
etch xen domain that you have root access to and you can do what you
like to it to try and get to the bottom of this.

Failing that, I guess I will have to do the same, but I will be
slower..

Cheers,
Andy


signature.asc
Description: Digital signature

Bug#115767: I see this too on x86-xen running etch

[Andy Smith]

On Thu, Mar 09, 2006 at 12:37:06PM -0500, Justin Pryzby wrote:
> Something like strace -f -o /var/log/ssh-strace/ssh-strace.log, where
> you should be able to set the directory permissions to be sufficiently
> tight.

Okay, I'm now running:

$ sudo strace -ff -o /var/log/ssh-strace/ssh-strace.log /usr/sbin/sshd

But after only a couple of minutes all these files have been
created:

$ sudo ls -lah /var/log/ssh-strace/
total 3.2M
drwx--  2 root root 3.0K Apr 14 15:54 .
drwxr-xr-x 10 root root 2.0K Apr 14 06:30 ..
-rw-r--r--  1 root root  87K Apr 14 15:54 ssh-strace.log
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15527
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15528
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15529
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15530
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15531
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15532
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15533
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15534
-rw-r--r--  1 root root  75K Apr 14 15:52 ssh-strace.log.15535
-rw-r--r--  1 root root 6.0K Apr 14 15:51 ssh-strace.log.15536
-rw-r--r--  1 root root 2.2K Apr 14 15:51 ssh-strace.log.15537
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15538
-rw-r--r--  1 root root 5.3K Apr 14 15:51 ssh-strace.log.15539
-rw-r--r--  1 root root  57K Apr 14 15:52 ssh-strace.log.15540
-rw-r--r--  1 root root  76K Apr 14 15:52 ssh-strace.log.15541
-rw-r--r--  1 root root 2.4K Apr 14 15:51 ssh-strace.log.15542
-rw-r--r--  1 root root  17K Apr 14 15:51 ssh-strace.log.15543
-rw-r--r--  1 root root 2.4K Apr 14 15:51 ssh-strace.log.15544
-rw-r--r--  1 root root 2.3K Apr 14 15:51 ssh-strace.log.15545
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15546
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15547
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15548
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15549
-rw-r--r--  1 root root 3.4K Apr 14 15:51 ssh-strace.log.15550
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15551
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15552
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15553
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15554
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.1
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15556
-rw-r--r--  1 root root  56K Apr 14 15:51 ssh-strace.log.15557
-rw-r--r--  1 root root 5.2K Apr 14 15:51 ssh-strace.log.15558
-rw-r--r--  1 root root  39K Apr 14 15:52 ssh-strace.log.15559
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15560
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15561
-rw-r--r--  1 root root  94K Apr 14 15:52 ssh-strace.log.15562
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15563
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15564
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15565
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15566
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15567
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15568
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15569
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15570
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15573
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15575
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15576
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15577
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15578
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15579
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15581
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15582
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15583
-rw-r--r--  1 root root 5.3K Apr 14 15:52 ssh-strace.log.15584
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15585
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15586
-rw-r--r--  1 root root  56K Apr 14 15:52 ssh-strace.log.15587
-rw-r--r--  1 root root 5.2K Apr 14 15:52 ssh-strace.log.15588
-rw-r--r--  1 root root  56K Apr 14 15:53 ssh-strace.log.15589
-rw-r--r--  1 root root 5.2K Apr 14 15:53 ssh-strace.log.15590
-rw-r--r--  1 root root  56K Apr 14 15:53 ssh-strace.log.15591
-rw-r--r--  1 root root 5.2K Apr 14 15:53 ssh-strace.log.15592
-rw-r--r--  1 root root  56K Apr 14 15:53 ssh-strace.log.15593
-rw-r--r--  1 root root 5.3K Apr 14 15:53 ssh-strace.log.15594
-rw-r--r--  1 root root  44K Apr 14 15:53 ssh-strace.log.15595
-rw-r--r--  1 root root 2.5K Apr 14 15:53 ssh-strace.log.15596
-rw-r--r--  1 root root  56K Apr 14 15:53 ssh-strace.log.15597
-rw-r--r--  1 root root 5.2K Apr 14 15:53 ssh-strace.log.15598
-rw-r--r--  1 root root  56K Apr 14 15:53 ssh-strace.log.15599
-rw-r--r--  1 root root 5.2K Apr 14 15:53 ssh-strace.log.15600
-rw-r--r-- 

Bug#115767: I see this too on x86-xen running etch

[Andy Smith]

On Thu, Mar 09, 2006 at 12:37:06PM -0500, Justin Pryzby wrote:
> On Thu, Mar 09, 2006 at 05:13:34PM +0000, Andy Smith wrote:
> > Hi,
> > 
> > I get this error message and sshd dying intermittently since I
> > upgraded one of my sarge xen domains to etch.  It always happens in
> > the middle of a prolonged dictionary attack on my sshd.  My other
> > sarge domains on the same hardware get the dictionary attacks and
> > weather them fine though.
> > 
> > I don't understand how it can be running out of random bytes when
> > /dev/urandom is there and appears to be working.
> > 
> > Last time this happened I ran sshd from the console like so:
> > 
> > /usr/sbin/sshd -eD -o 'LogLevel VERBOSE'
> This doesn't actually help much; the same error code was reported
> before.

Fair point, just wanted to show it really is the same thing as
previously reported.

> Would you consider trying to strace the processes?  This was
> recommended for the other similar bug (assigned to "openssl"; there
> are #115767, #155467).

I would but I'm concerned that this will use large amounts of disk
space.  This problem only manifests itself perhaps once every month
or two and depends on me getting a big SSH dictionary attack it
seems.

> Something like strace -f -o /var/log/ssh-strace/ssh-strace.log, where
> you should be able to set the directory permissions to be sufficiently
> tight.

What if I ran strace without the -f and ran ssh with -eD again so it
doesn't detach or fork?  Then I'd only have strace logs from the
parent sshd right?  Which wouldn't be too much of a logging burden
yet would still show the problem, I'm guessing.

> This might also be a kernel bug, if read() returns short when it
> shouldn't.  How reproducible is this for you?  What if you
> 
>   while :; do ssh otherhost true; done;
> 
> (with rsa or other noninteractive authentication mechanism enabled)

I've had this running for a few minutes now and can't reproduce..
indeed the ssh dictionary attacks were connecting constantly for
hours at a time and still not triggering it, so I think it will be
hard to reproduce.  I'll leave it running and update if there's
anything to report.

Thanks for looking into this,
Andy

-- 
http://strugglers.net/wiki/Xen_hosting -- A Xen VPS hosting hobby
Encrypted mail welcome - keyid 0x604DE5DB


signature.asc
Description: Digital signature

Bug#115767: I see this too on x86-xen running etch

[Andy Smith]

Hi,

I get this error message and sshd dying intermittently since I
upgraded one of my sarge xen domains to etch.  It always happens in
the middle of a prolonged dictionary attack on my sshd.  My other
sarge domains on the same hardware get the dictionary attacks and
weather them fine though.

I don't understand how it can be running out of random bytes when
/dev/urandom is there and appears to be working.

Last time this happened I ran sshd from the console like so:

/usr/sbin/sshd -eD -o 'LogLevel VERBOSE'

and got this:

(snip thousands of similar lines)
Failed password for invalid user random from 219.238.174.73 port 47185 ssh2
Received disconnect from 219.238.174.73: 11: Bye Bye
Connection from 219.238.174.73 port 47333
Invalid user cacilia from 219.238.174.73
input_userauth_request: invalid user cacilia
Failed password for invalid user cacilia from 219.238.174.73 port 47333 ssh2
Received disconnect from 219.238.174.73: 11: Bye Bye
Connection from 219.238.174.73 port 47476
Couldn't obtain random bytes (error 604389476)
ruminant:~#

Any ideas?

-- 
http://strugglers.net/wiki/Xen_hosting -- A Xen VPS hosting hobby
Encrypted mail welcome - keyid 0x604DE5DB


signature.asc
Description: Digital signature