Klaus,
On Tue, 09 Jul 2013, Klaus wrote:
> >>When I manually re-run "update-initramfs -uv", it tells me that the
> >>microcode is found, bundled and put into
> >>the initrd image. Here is an extract of the output:
Could you send me the full output of "update-initramfs -u -v" ?
I'd like to track
On Mon, 15 Jul 2013, nicolas.patr...@gmail.com wrote:
> Le 14/07/2013 23:17:39, Henrique de Moraes Holschuh a écrit :
> > I'll need your help to track this down.
>
> > Please, what are the messages on screen at the time the system gets
> > blocked?
>
> # d
jidanni,
Please run as root:
"update-initramfs -u -v >/tmp/output.txt 2>&1"
on the box you're having problems and send the "/tmp/output.txt" file to me
directly or attach it to the bug report. It will tell me at what point
initramfs-tools decided it needed to include the "microcode" module, and
On Sun, 14 Jul 2013, Nicolas Patrois wrote:
> Today (07-14-2013), updating intel-microcode completely blocks aptitude (and
> dpkg as well).
> When aptitude tries to configure the package, the process stops and does
> nothing. ^C does not kill it, I must kill it with killall and remove the
> lock
On Thu, 11 Jul 2013, jida...@jidanni.org wrote:
> BTW, one notes .old-dkms files are not cleaned up after their kernels
> are gone...
I suggest you file a bug against dkms, then... But before you do that, make
sure you _purged_ the kernels (not just removed them).
--
"One disk to rule them al
On Thu, 11 Jul 2013, jida...@jidanni.org wrote:
> >>>>> "H" == Henrique de Moraes Holschuh writes:
> >> All I know is yesterday I did an aptitude full-upgrade and today I see a
> >> warning.
>
> H> Well, unless I manage to reproduce it he
On Wed, 10 Jul 2013, jida...@jidanni.org wrote:
> H> Well, maybe there is a minor bug in that something is annoyingly including
> H> the microcode driver in the initramfs, even when intel-microcode did not
> ask
> H> for it. No harm done, but it logs those useless error messages and it
> might
>
severity 715518 minor
retitle 715518 harmless firmware agent errors on Linux 3.9 and later
thanks
On Wed, 10 Jul 2013, jida...@jidanni.org wrote:
> Today I see
> [4.401809] platform microcode: firmware: agent aborted loading
> intel-ucode/06-2a-07 (not found?)
> [4.401914] microcode: CPU1
On Fri, 21 Jun 2013, jida...@jidanni.org wrote:
> H> BTW, you *really* want to install iucode-tool. It is not recommended just
> H> for the heck of it.
>
> OK then mention that at
> > W: intel-microcode: iucode_tool not found, advanced functionality not
> > available
The reason why iucode-tool
tag 712943 confirmed pending
thanks
Well, it is really easy to reproduce. I will upload a fix shortly.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Taro
found 712943 1.20130222.3
thanks
On Fri, 21 Jun 2013, jida...@jidanni.org wrote:
> update-initramfs: Generating /boot/initrd.img-3.9-1-486
> W: intel-microcode: iucode_tool not found, advanced functionality not
> available
> xargs: invalid option -- 'q'
Hmm... what are the contents of file /etc/
On Mon, 17 Jun 2013, Michael Prokop wrote:
> * Henrique de Moraes Holschuh [Sun Jun 16, 2013 at 03:42:45PM -0300]:
> > Enclosed you will find two patches to add early-initramfs support to
> > initramfs-tools.
>
> > It adds, and properly documents, a hook function tha
o pass system processor microcode and ACPI table
overrides to the kernel (requires Linux kernel v3.9 or later).
Signed-off-by: Henrique de Moraes Holschuh
---
hook-functions| 10 ++
initramfs-tools.8 | 14 ++
mkinitramfs | 19 ---
3 files changed,
Package: sdparm
Version: 1.07-1
Severity: wishlist
Date: Sun, 09 Jun 2013 12:26:19 -0400
From: Douglas Gilbert
Subject: [ANNOUNCE] sdparm 1.08 available
sdparm is a command line utility designed to get and set
SCSI device parameters (cf hdparm for ATA disks). The
parameters are held in mode page
Package: usbutils
Version: 1:006-1
Severity: wishlist
Date: Thu, 6 Jun 2013 16:40:57 -0700
From: Greg KH
Here's the 007 release of usbutils.
Nothing major over the 006 release, just a bunch of tiny bug fixes that
have trickled in over the past year. The short changelog can be found
below.
The
reassign 706443 lxc
retitle 706443 fails to build twice in a row: broken distclean target
thanks
Building lxc twice fails because when dh_clean runs, it is calling
make distclean in the config/ directory.
And config/Makefile.am is borken crap that removes stuff it should never
touch on distclean
On Sun, 19 May 2013, Steve Langasek wrote:
> I strongly recommend a more generic approach of detecting whether the
> required mount is already mounted, and skipping the operation if it is.
There is the non-obvious, and quite vexing issue of mount options.
--
"One disk to rule them all, One dis
On Sun, 07 Apr 2013, Ben Hutchings wrote:
> So it seems that this is only going to be an issue if users take the
> unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe
> there are management tools that do that as a matter of course?
One should never use UUIDs in fstab to refer t
superseded by later ones: microcode-20120606-v2.dat
+
+ -- Henrique de Moraes Holschuh Sun, 03 Mar 2013 16:59:35
-0300
+
intel-microcode (1.20120606.v2.2) unstable; urgency=medium
* initramfs: work around initramfs-tools bug #688794.
--
"One disk to rule them all, One disk to find
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package intel-microcode
Intel released a new version of their microcode dump, which updates the
microcode for a widely-used processor family (latest i5/i7: e.g. i5-3570k
and
Package: qa.debian.org
Severity: normal
The popcon data graphs for at least two packages: intel-microcode and
iucode-tool, has not been updated for a while:
http://qa.debian.org/popcon.php?package=intel-microcode
http://qa.debian.org/popcon.php?package=iucode-tool
-- System Information:
Debian R
On Sat, 23 Feb 2013, Philipp Kern wrote:
> On Sat, Feb 23, 2013 at 09:19:53AM -0300, Henrique de Moraes Holschuh wrote:
> > I recommend that you just ignore the messages, that way you will still get
> > an updated microcode if Intel decides to start shipping one for your
> >
tag 701169 wontfix
severity 701169 minor
thanks
On Fri, 22 Feb 2013, Philipp Kern wrote:
> intel-microcode's initramfs hook seems to try to load microcode
> unconditionally. This causes the following error messages to appear if no
Yes.
> microcode is present in the package, once for every schedu
On Thu, 03 Jan 2013, Alexey Eromenko wrote:
> On Thu, Jan 3, 2013 at 8:05 PM, Didier 'OdyX' Raboud wrote:
> >
> > release and lsb-base being Architecture: foreign). Patches are welcome to
> > make
> > Wheezy+1 more suitable to your needs.
>
> How about changing it from a kernel bug to tasksel fe
On Mon, 24 Dec 2012, Paul Wise wrote:
> On Mon, Dec 24, 2012 at 7:45 AM, Steffen Vogel wrote:
>
> > There still the problem that the package name (sun) might be too generic
> > to be included in the archive. What do you think about this concern?
>
> I think sun is the perfect name for this tool a
On Sun, 16 Dec 2012, Ben Hutchings wrote:
> On Sun, 2012-12-16 at 11:24 -0200, Henrique de Moraes Holschuh wrote:
> > Package: linux
> > Version: 3.2.35-1
> > Severity: important
> > Tags: patch
> >
> > Please include the attached patch in Wheezy, without
Package: linux
Version: 3.2.35-1
Severity: important
Tags: patch
Please include the attached patch in Wheezy, without it, irqbalance fails to
do its job properly on any server (actually any multi-core system with
MSI/MSI-X irqs).
It is important to have irqbalance work properly out-of-the-box, si
On Thu, 22 Nov 2012, Johannes Truschnigg wrote:
> Package: sysvinit
> Version: 2.88dsf-13.1+squeeze1
> Severity: minor
> Tags: patch
>
>
> I added a new entry to inittab on a busy host which did not seem to start upon
> invoking `telinit q`. Syslog received the following message:
>
> Nov 22 10:1
On Sat, 29 Sep 2012, Eric Valette wrote:
> On 29/09/2012 04:11, Henrique de Moraes Holschuh wrote:
> >Why should it? It is the kernel's job. An initscript would just slow the
> >boot. And the wheezy kernel does its job better when the microcode driver
> >is a modul
On Wed, 07 Nov 2012, Ben Hutchings wrote:
> On Wed, Nov 07, 2012 at 05:55:48PM -0200, Henrique de Moraes Holschuh wrote:
> > Package: firmware-linux-nonfree
>
> I think the firmware-linux metapackage would be more appropriate.
Sure, that would work as well.
> > Please reco
Package: firmware-linux-nonfree
Version: 0.36
Severity: wishlist
Please recommend amd64-microcode | intel-microcode for Wheezy. It would be
best if the majority of our users run with up-to-date microcode...
Unfortunately, since these packages are arch-specific, this recommendation
cannot be met
reassign 692535 intel-microcode
thanks
On Wed, 07 Nov 2012, Jon Dowland wrote:
> Summary of situation:
>
> • I have APT::Install-Recommends set to false
> • I installed intel-microcode
> • I noticed iucode-tool was not installed, so installed it
> • Microcode was not updated.
Because the mic
On Tue, 06 Nov 2012, Paul Gevers wrote:
> Both before and after the installation, the output for the microcode was the
> same (see below).
If you didn't have the microcode module loaded, please reboot and check the
microcode revision again. Did the microcode get updated after a reboot?
Alternati
On Tue, 06 Nov 2012, Yves-Alexis Perez wrote:
> would it be possible to update rng-tools to version 4? This version
> apparently fixes a lot of issues with the previous versions and brings
> support for RDRAND instruction.
That requires some work to avoid breaking compatibility with the unofficial
urgency=medium
+
+ * initramfs: work around initramfs-tools bug #688794.
+Use "_" in place of "+-." for the initramfs script name. This works
+around a PANIC during boot when the initramfs was created in a system
+with noexec $TMPDIR.
+
+ -- Henrique de Moraes Hols
.
+Use "_" in place of "+-." for the initramfs script name. This works
+around a PANIC during boot when the initramfs was created in a system
+with noexec $TMPDIR.
+
+ -- Henrique de Moraes Holschuh Tue, 09 Oct 2012 08:18:01
-0300
+
amd64-microcode (1.20120910-1) un
On Tue, 09 Oct 2012, maximilian attems wrote:
> > On Tue, 09 Oct 2012, maximilian attems wrote:
> > > On Mon, Oct 08, 2012 at 06:03:20PM -0300, Henrique de Moraes Holschuh
> > > wrote:
> > > > Well, I don't mind changing the name of the initramfs-too
On Tue, 09 Oct 2012, maximilian attems wrote:
> On Mon, Oct 08, 2012 at 06:03:20PM -0300, Henrique de Moraes Holschuh wrote:
> > Well, I don't mind changing the name of the initramfs-tools helper scripts
> > in the *-microcode packages,
>
> please do so.
As long as the
On Mon, 08 Oct 2012, maximilian attems wrote:
> "Variables set by the user must have a name consisting solely of alphabet‐
> ics, numerics, and underscores - the first of which must not be numeric."
> - dash.1
>
> it seems the initramfs-tools manpage added the "dash" along
> the lines, which is wr
"noexec" option since ages. If I remount it with "exec" before running
> "update-initramfs -u", there is no error and then the next reboot is
> ok. I had a similar problem a few weeks ago with the new flashplayer
> updater script not handling this case.
>
&
Ok, I found the problem. Your broken initramfs image is missing the ORDER
files. All initramfs images that work fine have the ORDER files.
There are _three_ codepaths in the initramfs script/functions: one wants the
ORDER files (which are missing in your initramfs image), the other wants
tsort (
On Sat, 29 Sep 2012, Lionel Gamay wrote:
> Meanwhile I tried something else: I kept the "intel-microde" and
> "iucode-tool" packages installed but used the previous microcode-free
> kernel instead of the one generated after installing the above
> packages. However, I added "microcode" to "/etc/modu
On Sat, 29 Sep 2012, Eric Valette wrote:
> Package: iucode-tool
> Version: 0.8.3-1
> Severity: wishlist
>
> Alreday did several time man iucode-tool, where binary and page man are
> iucode_tool
I will check if I can tell man to have iucode-tool as an alias. I agree it
is annoying.
--
"One d
tag 689042 + wontfix
severity 689042 wishlist
retitle 689042 requires modular microcode driver for autoload on boot
On Fri, 28 Sep 2012, Eric Valette wrote:
> he old microcode.ctl package did at least provide an init script to perform
> it. Why
> not iucode-tool?
Why should it? It is the kernel
On Fri, 28 Sep 2012, Lionel Gamay wrote:
> I followed you advice but I still get a similar error message, without
> any reference to udev:
>
> "Loading, please wait...
> /init: eval: line 1: array_intel_microcode=: not found
> /init: eval: line 1: array_intel_microcode=: not found
> PANIC: Circula
On Wed, 26 Sep 2012, Lionel Gamay wrote:
> It is quite weird to get this error on two different machines using
> different architectures and even while trying two different kernels on
> these two machines. Then four different configurations lead to this
> message. BTW, you are right: it is "array..
tag 688794 + moreinfo
thanks
I cannot reproduce this.
I have installed a brand-new wheezy VM with the wheezy kernel (3.2.0-3). I
installed the old microcode.ctl and intel-microcode packages. It worked. I
rebooted. It worked. I upgraded to the new intel-microcode package (which
also updates m
On Tue, 25 Sep 2012, Lionel Gamay wrote:
> I tried to upgrade from 1.20120606.1 on my i386 netbook and my current x64
> machine, with either 3.2 or 3.5-trunk kernels on each PC. On reboot I always
> get the following error messages before dropping down to BusyBox console:
>
> Loading, please wait.
when backporting to Debian Squeeze
+ * debian/control: add Vcs-* fields
+
+ -- Henrique de Moraes Holschuh Fri, 14 Sep 2012 15:39:37 -0300
+
amd64-microcode (1.20120117-2) unstable; urgency=low
* debian/control: priority of this package should be standard,
diff -Nru amd64-microcode-1.20120117/
Package: iucode-tool
Version: 0.8-1
Severity: minor
Tags: upstream
The iucode_tool(8) manpage up to version 0.8.3 does not document
iucode_tool option -W (--write-named-to).
It is correctly documented by the built-in help (iucode_tool -h):
-W, --write-named-to=directory
Write selected micr
Package: ftp.debian.org
Severity: normal
microcode.ctl is now a transitional package. It has been superseded
by intel-microcode and iucode-tool.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where th
On Sun, 16 Sep 2012, Philipp Kern wrote:
> On Sun, Sep 16, 2012 at 10:43:44AM -0300, Henrique de Moraes Holschuh wrote:
> > Will upload a fix shortly. Missing changelog entries play havoc with the
> > BTS version tracking, so it is not just a cosmetic/record-for-posterity fix.
&
Package: microcode.ctl
Version: 1.18~0+nmu1
Severity: serious
Will upload a fix shortly. Missing changelog entries play havoc with the
BTS version tracking, so it is not just a cosmetic/record-for-posterity fix.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy
On Sun, 16 Sep 2012, Debian Bug Tracking System wrote:
> > I switched to Debian Wheezy upstream, so the upstream diff 0.8.2..0.8.3 has
> > a lot of autotools noise. This doesn't affect the Debian build in any way,
> > because the Debian package removes all autogenerated files and retools at
> > ev
es
+ to be selected by --scan-system on a box with unsupported
+ processors (e.g. non-Intel)
++ Update README: Intel has some microcode update information in
+ some public processor specification update documents
+
+ -- Henrique de Moraes Holschuh Sun, 26 Aug 2012 18:38:54 -0300
+
On Tue, 11 Sep 2012, Jonathan Nieder wrote:
> Henrique de Moraes Holschuh wrote:
> > Still, if any of you would like to do it, please wait a bit. Let's release
> > Wheezy first.
>
> I agree that we should not upload any change along these lines to
> policy in the nea
On Tue, 11 Sep 2012, Jonathan Nieder wrote:
> Bernhard R. Link wrote:
> > * Jonathan Nieder [120911 05:45]:
> >> The requirements in policy for
> >> "debian/rules clean" are very stringent --- to avoid the
> >> "unrepresentable changes" it would be enough to _remove
Transitional packages were uploaded yesterday, and are in the DELAYED/2
queue ATM:
intel-microcode 1.20120606.6Conflicts: microcode.ctl (<< 1.18~0)
microcode.ctl 1.18~0+nmu1 Depends: intel-microcode (>> 1), iucode-tool
Conflicts: intel-microcode (<< 1)
-
retitle 686895 initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
tag 686895 + confirmed
thanks
On Fri, 07 Sep 2012, Simrun Basuita wrote:
> The manpage for fsck(9) makes no mention of a '-f' option. So perhaps
> checkroot.sh shouldn't call it with that argument.
You're correct.
It really l
reassign 686895 btrfs-tools
thanks
On Fri, 07 Sep 2012, Simrun Basuita wrote:
> # cat /var/log/fsck/checkroot
> Log of fsck -C -f -a -t btrfs /run/rootdev
> Fri Sep 7 01:34:14 2012
>
> fsck from util-linux 2.20.1
> fsck.btrfs: invalid option -- 'f'
> usage: btrfsck dev
> Btrfs Btrfs v0.19
> fsck
On Sat, 01 Sep 2012, Philipp Kern wrote:
> On Thu, Aug 02, 2012 at 02:57:35PM -0300, Henrique de Moraes Holschuh wrote:
> > Please unblock package intel-microcode
>
> These are changes that are quite large. I'm willing to unblock them, though,
> as
> they work much b
On Tue, 04 Sep 2012, Petter Reinholdtsen wrote:
> [M G Berberich]
> > For btrfs multi-disk-filesystems to get mounted it is neccessary to do
> > a ‘btrfs scan’ so the kernel knows about btrfs-disks/partitions. This
> > should probably be done in ‘/etc/init.d/mountall.sh’
> >
> > # for btrfs mult
On Tue, 04 Sep 2012, Osamu Aoki wrote:
> For example, if package build environment has pre-defined and agreed
> environment variable such as:
>
> DERIVATIVE=(undefined) # debian build
> DERIVATIVE=debian # debian build
> DERIVATIVE=ubuntu # ubuntu build
> DERIVATIVE=trisquel# trisque
Package: iucode-tool
Version: 0.8.2-1
Severity: normal
iucode-tool --scan-system will cause all intel microcodes to be selected
(and installed by the intel-microcode package in unstable) on systems with
no Intel processors.
It should select no microcodes instead, as there are no Intel processors
On Wed, 29 Aug 2012, Ondřej Surý wrote:
> On Tue, Aug 28, 2012 at 7:46 PM, Jamie Thompson
> wrote:
> > Following a power failure my tls_sessions.db file became corrupted (UPS
> > is currently out of commission - anyway). When the server restarted, I
> > did not notice this fact and would not do so
The nut packages currently in wheezy malfunction severely, to the point of
being unusable for USB-attached UPSes.
The nut packages in unstable work perfectly.
I second the request to unblock nut/2.6.4-2.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in
On Sat, 25 Aug 2012, Mika Suomalainen wrote:
>Package name: caffeine
Near name colision with kaffeine, one of the more common media players for
KDE.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
w
tag 455230 fixed-upstream
thanks
where "upstream" here is the kernel itself. Fixed in Linux kernel
3.2.26, 3.0.41, 3.4.9, 3.5.2, 3.6. The fix will eventually flow down to
the 3.2-based Wheezy kernel and to unstable.
On Wed, 12 Dec 2007, Marc Haber wrote:
> > On Sun, 09 Dec 2007, Marc Haber wrot
On Mon, 13 Aug 2012, Jonathan Nieder wrote:
> You can see why an OS distributor would be stuck in this situation,
> though. If the microcode updates are installed by default, Debian is
> taking responsibility for their effect (in the sense of receiving bug
> reports and providing updates when appr
On Mon, 13 Aug 2012, Paul Menzel wrote:
> Looking into this some more, this seems unlikely in Debian because the
> microcode packages are in non-free [1] and therefore not available for
> Debian users not having enabled non-free repositories.
>
> Because of that the microcode packages are also non
On Wed, 08 Aug 2012, Aljaž Prusnik wrote:
> Isn't that what the network manager does so it can operate - comments
> out those lines?
Don't let anything mess with the loopback. Your system will go bonkers if
it is down because network-manager screwed up or took its sweet time to
bring it up.
--
hanks to Sebastian Andrzej
Siewior for a good suggestion on how to fix it (closes: #683161)
* README.Debian: add "modprobe cpuid" to example
* debian/control: use better Vcs-browser URI that is properly
handled by the current alioth redirector.
-- Henrique de Moraes Hol
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
Please unblock package intel-microcode
Relevant thread in debian-release:
http://lists.debian.org/debian-release/2012/07/msg01358.html
non-free stable and non-free wheezy are curr
icrocodes
+ if no other microcode selection option was used (closes: #683178)
+ * debian/control: add X-Vcs-* fields
+
+ -- Henrique de Moraes Holschuh Sun, 29 Jul 2012 10:06:35 -0300
+
+iucode-tool (0.8.1-1) unstable; urgency=low
+
+ * New upstream release
++ inform user with an error me
severity 683161 important
tag 683161 confirmed
clone 683161 -1
reassign -1 iucode-tool
retitle -1 iucode-tool: bad --scan-system failure mode
found -1 iucode-tool/0.8-1
tags -1 + fixed-upstream confirmed
tags 683161 + patch
thanks
On Sun, 29 Jul 2012, Sebastian Andrzej Siewior wrote:
> Package: in
On Sat, 28 Jul 2012, Rudy Zijlstra wrote:
> stopping aiccu, rmmod sit and tunnel4 and then reloading and
> restarting aiccu did solve it
>
> Next time i will start with restarting aiccu, and not rmmoding the
> related modules
Hmm, okay. That should help narrow it down a lot.
--
"One disk to
tags 542599 + wontfix
thanks
This is currently being properly addressed upstream, by adding TPM support
to the kernel hw_random device.
The kernel fix avoids any conflicts with the userspace TPM stack.
Therefore, I will not accept this patch to rng-tools.
References:
http://lkml.kernel.org/r/133
On Mon, 23 Jul 2012, Sandy Harris wrote:
> >> Initial entropy at very early boot, before Debian seeds the kernel, is a
> >> task that can only be done properly by the kernel itself, and is being
> >> addressed there at this time (patches have already been proposed). The
> >> proper fix for better
I am somewhat worried about this package being added to Debian.
The kernel itself is responsible for collecting randomness from interrupts
when it is deemed safe enough, this is NOT a task well suited to userspace.
Userspace should gather entropy from external sources (like audio noise, USB
HRNGs,
On Thu, 19 Jul 2012, Ansgar Burchardt wrote:
> tag 681735 + wontfix
> thanks
>
> Henrique de Moraes Holschuh writes:
> > intel-microcode provides updated microcode to Intel processors, and
> > should ideally be installed by default on every system with an Intel
> >
On Wed, 18 Jul 2012, Michael Biebl wrote:
> On 17.07.2012 23:52, Roger Leigh wrote:
> > We removed the bootlogs script because it was believed to be made
> > redundant by modern logging daemons. However, this was not taking
> > into account the fact that even though the information is logged,
> >
On Sat, 21 Aug 2010, Henrique de Moraes Holschuh wrote:
> 1. Provide facilities to upload microcode from the initrd. Since a big
> initrd is annoying, it should retain in the initrd only the microcode
> for the CPU update-initramfs was run in. The root filesystem boot
> proces
Package: ftp.debian.org
Severity: normal
Tags: override
intel-microcode provides updated microcode to Intel processors, and
should ideally be installed by default on every system with an Intel
processor. Unfortunately, it is non-free, but its priority should still
reflect the fact that it should
On Fri, 13 Jul 2012, Ben Hutchings wrote:
> I certainly consider mounting of debugfs to be significant security
> liability. I'm not at all happy that people use it as the basis for
Seconded. I know of at least three ways to hardcrash boxes through
debugfs (system specific, not a kernel bug), an
+1,23 @@
+amd64-microcode (1.20120117-2) unstable; urgency=low
+
+ * debian/control: priority of this package should be standard,
+not extra. All AMD-based X86 boxes should install this package
+ * debian/control: update package description
+
+ -- Henrique de Moraes Holschuh Mon, 09 Jul
On Tue, 10 Jul 2012, Kiss Gabor (Bitman) wrote:
> #0 0xb7754424 in __kernel_vsyscall ()
> #1 0xb720f96b in poll () from /lib/i686/cmov/libc.so.6
> #2 0xb4d43444 in ldap_int_select (ld=0x91a8638, timeout=0x0) at os-ip.c:1098
> #3 0xb4d2cdbb in wait4msg (ld=0x91a8638, msgid=4, all=0, timeout=0x0,
On Tue, 10 Jul 2012, Kiss Gabor (Bitman) wrote:
> I could create a core dump. Stack trace:
>
> (gdb) bt
> #0 0xb76f5424 in __kernel_vsyscall ()
> #1 0xb71b096b in poll () from /lib/i686/cmov/libc.so.6
> #2 0xb4ce in ldap_int_select () from /usr/lib/libldap_r-2.4.so.2
> #3 0xb4ccddbb in lda
Package: ftp.debian.org
Severity: normal
Tags: override
amd64-microcode provides microcode patches to AMD processors, and should
ideally be installed by default on every system with an AMD AMD64
processor (regardless of whether it is running i386 or amd64
binaries/kernel). Unfortunately, it is no
On Sat, 07 Jul 2012, Jean-Paul Pozzi wrote:
> Content of /proc/cpuinfo in attached file.
Thank you. Please test with a stable kernel, and report back to bug #680629
so that I know what to report upstream... (just "reply to all" on this
message).
--
"One disk to rule them all, One disk to find
On Sat, 07 Jul 2012, JP Pozzi wrote:
> I try to use the microcode loader for my AMD64 and get the "amd64-microcode"
> package and get "failed" messages
> in the "kern.log" while booting :
>
> microcode: Microcode Update Driver: v2.00 ,
> Peter Oruba
> microcode: CPU0: patch_level=0x01
Please confirm that this is not caused by the leap-second issues, i.e.
you've seen it on a freshely rebooted server, or prior to the 29th of
june.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where th
Meanwhile, the amd64-microcode package made it to unstable.
I'll work with that for the next days, and see what can be done that way,
which is easier and faster on my end.
We can migrate it to firmware-nonfree later. It shouldn't be a problem,
since it will be multiarch-foreign anyway, regardles
On Sun, 24 Jun 2012, Jonathan Nieder wrote:
> Thanks for starting to track this down. Any idea which package might
> be responsible?
It is probably the kernel.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Red
On Sun, 24 Jun 2012, Ben Hutchings wrote:
> On Sun, 2012-06-24 at 13:05 -0300, Henrique de Moraes Holschuh wrote:
> [...]
> > > > 3. firmware-nonfree _really_ needs a README.source :-)
> > >
> > > Yeah.
> [...]
>
> Fixed in svn; let me know if it&#x
On Sun, 24 Jun 2012, Ben Hutchings wrote:
> On Sun, 2012-06-24 at 12:21 -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > > > > The package template system currently only supports one optional
> > > > > postinst actio
On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > > The package template system currently only supports one optional
> > > postinst action, but it wouldn't be hard to extend to add others.
Ok, I tried to ship the microcode for amd processors using firmware-nonfree.
There are a few problems:
1. firmwa
On Sat, 23 Jun 2012, Ben Hutchings wrote:
> On Fri, 2012-06-22 at 23:49 -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > > On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> > > > On Fri, 22 Jun 2012, Ben
submitter 678644 jer...@zoph.org
thanks
On Sat, 23 Jun 2012, Jeroen Roos wrote:
> I am the maintainer of "Zoph", a webbased program to organize photos.
...
> The current version in Debian has several issues, including a few
> security-related of which some are severe. All of these are fixed in the
Package: zoph
Version: 0.8.0.1-1
Severity: grave
Tags: security fixed-upstream
- Forwarded message from Jeroen Roos -
Date: Sat, 23 Jun 2012 14:16:18 +0200
From: Jeroen Roos
To: d-p@l.d.o
Subject: Outdated version of Zoph in Debian
Hi,
I am the maintainer of "Zoph", a webbased program
On Sat, 23 Jun 2012, Jonathan Nieder wrote:
> Russ Allbery wrote:
> > Would one list bug-gnu-ut...@gnu.org? That's the most useful contact
> > point (and we have a copyright-format field for that), but it's not in any
> > real sense the "author."
>
> Sure it is --- it's the contact point for the
501 - 600 of 1722 matches
Mail list logo
