Package: nfs-kernel-server
Version: 1:1.2.8-4
Severity: wishlist
Hi.
I'd think it would be really useful to move the more general
manpages (especially exports(5) but maybe also some of the others)
to the nfs-common package.
I would like to be able to read them, with getting a nfs server.
Cheer
Source: linux
Version: 3.10.7-1
Severity: normal
Hi.
I got a little bit stuck with this...
I'm having a Fujitsu Lifebook E782 which has some Sierra Gobi 3000
UMTS modem in it.
For many years it simply used to work perfectly, but a year ago or so it
already stopped
working (i.e. wasn't detected
Source: linux
Version: 4.12.12-2
Severity: critical
Tags: security
Justification: root security hole
Hi.
Any chance to get CVE-2017-1000251, which seems to be quite critical fixed
anytime soon? :-)
https://security-tracker.debian.org/tracker/CVE-2017-1000251
Thx,
Chris
On Fri, 2017-09-15 at 19:18 +0100, Ben Hutchings wrote:
> Probably less critical than you think, since we enable
> CONFIG_CC_STACKPROTECTOR.
Well... yes, but it wouldn't be the first time in history, that such
defence could then also be circumvented in the next evolution of an
exploit :-)
But of
Package: initramfs-tools
Version: 0.130
Severity: important
Hi.
The following is a quite strange problem, and it may actually be a kernel bug.
Few days ago, I got a new notebook (a Fujitsu U757), before I removed the HDD
from
the old one, I changed MODULES=most on the old and updated the initra
Package: src:linux
Version: 4.13.10-1
Severity: critical
Justification: breaks unrelated software
Hi.
Apparently AppArmor was enabled per default in the last version.
While I'm usually in favour of anything that improves security
(leaving aside the question here whether SELinux wouldn't be the
The severity would have shown people which haven't upgraded, that there
are issues... :-(
On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote:
> Although you can disable it (security=dac or apparmor=0) if you want.
Sure. I never said this wasn't possible.
> > While I'm usually in favour of a
Package: initramfs-tools
Version: 0.120
Severity: wishlist
Hi.
I just noticed in the changelog that there is /run/initramfs/fsck.log.
Awesome :-)
But could you please move that to /var/log (and appened entries each run
and have it handled by logrotate)?
Yes I know, this is from the initramfs w
Source: linux
Version: 4.9.30-2+deb9u2
Severity: normal
Hey Ben, et al.
There seems to be an annoying bug in btrfs, as described here:
https://www.spinics.net/lists/linux-btrfs/msg67479.html
It's not really extremely critical as it causes no direct fs corruption,
but it gives spurious ENOSPC in
Hey
I had the very same,... empty dir left behind... never modified any
configs in it (and even then I couldn't see how this can be desired, if
the modified config itself wasn't left behind somehow :) ).
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2016-12-20 at 04:39 +, Ben Hutchings wrote:
> It looks like dpkg will remove it on the next upgrade of initramfs-
> tools-core. The problem only occurs once because dpkg tries to
> remove
> the directory before the conffile.
I've seen such tickets several times before,... and had the
Hey Ben.
Sorry I oversaw your mail back then.
Provided the information from perf top now in the kernel.org bugzilla,
and pinged the linux-usb list as you suggested:
https://www.spinics.net/lists/linux-usb/msg151899.html
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Source: linux
Version: 4.9.2-2
Severity: normal
Tags: patch upstream
Hey.
There's an issue in NBD which prevents some larger images to be
correctly "connected" on the client side (if done by the kernel),
largely described here:
https://github.com/NetworkBlockDevice/nbd/issues/44
Thers's a patch
On Mon, 2017-01-16 at 02:37 +, Ben Hutchings wrote:
> This should possibly go to 4.9-stable, but in any case I've queued it
> up for our next upload.
Could you ping the responsible people? Guess you have far better
contacts there than me ;-)
Cheers,
Chris.
smime.p7s
Description: S/MIME cryp
The bug in question was a wishlist matter, so it's not really "fixed"
by recent upstream versions.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Source: linux
Version: 4.18.10-2+b1
Severity: wishlist
Hi.
Could you please enable the crypto modules for MORUS and AEGIS
AEAD ciphers?
It shoul be supported now in cryptsetup/dm-crypt for volumes
with integrity protection and I'd like to play with them.
Thanks,
Chris.
-- System Information:
Source: linux
Version: 4.18.20-1
Severity: important
Tags: upstream
Hi.
Possibly the following may be also partially iptables (i.e. the userland tool)
fault.
I'm using fail2ban with some custom usage mode, which is that the hook-rule
for fail2ban's change isn't just appended somehwere, but an
Hey.
Just wondered if a maintainer could possibly tell me whether this could
happen anytime soon?
It's no big problem for me if not, I'd just want to avoid compiling the
whole kernel on my system (which is not the fastest one ^^) if you'd
enable it anyway on the next version or so.
Cheers,
Chri
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=201791
Source: linux
Version: 4.18.20-2
Severity: critical
Tags: upstream patch
Justification: causes serious data loss
Hi.
There's a bug in the blk-mq schedulers which may cause serious data
curruption...
See https://bugzilla.kernel.org/show_bug.cgi?id=201685
Seems like a patch was made recently,...
For those reading along, Jens Axboe gave a summary on how to
check whether one's affected or not:
Quoting from: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c294
> scsi_mod.use_blk_mq=0 will do the trick, as will just ensuring that you have
> a scheduler for your device. Eg for sda, check:
>
There is some indication, that this issue doesn't occur with the kernel
from oldstable (i.e. 3.16.51-3+deb8u1, with the rest of our userland
still at stretch)... at least we have on node downgraded to that
kernel, and so far that one wasn't hit in nearly two weeks, while many
other were.
If there'
Source: firmware-nonfree
Version: 20151018-2
Severity: wishlist
Hi.
Could you please turn all the Depends of the meta-packages into
Recommends?
It doesn'ts seem to make much sense to force e.g. everyone who wants
to install firmware-linux-nonfree to have to install firmware-amd-graphics
as well
Package: initramfs-tools
Version: 0.120
Severity: normal
Hi.
When / is on btrfs, then /usr/share/initramfs-tools/hooks/fsck
tries to include /sbin/fsck.btrfs into the initramfs; fsck.btrfs
is however in /bin (and included by btrfs-tools' initramfs hook).
So the warning is misleading (as a fsck f
Source: linux
Severity: minor
Hey.
This is absolutely just cosmetic ;-)
I've noted that the symlink /initrd.img is always absolute,
while /vmlinuz is always relative, e.g.:
$ ls -al /initrd.img /vmlinuz
lrwxrwxrwx 1 root root 30 Sep 27 13:37 /initrd.img ->
/boot/initrd.img-4.2.0-1-amd64
lrwxrwx
Package: initramfs-tools
Version: 0.120
Severity: normal
Hi.
I've just noted the following:
Processing triggers for initramfs-tools (0.120) ...
update-initramfs: /boot/initrd.img-4.2.0-1-amd64 has been altered.
update-initramfs: Cannot update. Override with -t option.
Not sure what caused it to
Hey.
That seems to work again at least since 4.2.5-1, but probably already
since few versions earlier (I didn't check this every time).
See upstream for little more details
Closing,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Package: src:linux
Version: 4.2.6-1
Severity: normal
Hey.
This is originall from http://article.gmane.org/gmane.linux.kernel/2090843:
I bough a USB3.0 ExpressCard from StarTech[0] which is apparently[1]
based on the NEC uPD720200.
Using a kernel 4.2.6 on amd64, the System is Debian sid, the fo
Source: linux
Version: 4.2.6-1
Severity: wishlist
Hey.
Not sure if linux is the right source package for this...
In several circumstances it would be handy, if there were
/vmlinux. and /initrd.img. symlinks
where each of them points to the most recent installed
kernel/initramfs of the respective
Hi.
I'm using a Tyan Thunder K8WE board with two DualCore Opterons (AMD
Modell 275). Each CPU have two 1GB RAM modules (thus a total of 4GB).
When I enter the BIOS the summary screen show 4096 MB but Linux seems to
detect only 2815 MB (see attached dmesg.txt).
High Memory Support is enabled
Hi,.. :-)
I've got some questions about kernel configuration... and hope someone
could possibly help me.
I'm using a Tyan S2895 Thunder K8WE mainboard,.. with two AMD Opterons
Model 275 (=2,2 GHz and DualCore). My total amoun of physical RAM is 4
GB (2 GB for each CPU).
So,...
1) Maximum numb
Frederik Schueler wrote:
looks like you did not activate NUMA and sparse/discontiguous memory
mapping.
What is that NUMA?
I've already read about it on some websites (k8we.com).
Do I have to change some BIOS settings perhaps?
I must admit that I don't understand most of the BIOS options,...
Ok,.. I've changed some options in the Memory Hole Menu,... (activated
IOMMU or something like that,.. an changed something from disabled to
software)
Now Linux seems to correctly identify my memory:
(dmesg)
Linux version 2.6.13.2 ([EMAIL PROTECTED]) (gcc version 4.0.2 (Debian
4.0.2-1)) #1 SMP
Hi everybody.
I'm currently (together with others) investigating in a severe data
corruption problem that at least many users might suffer from.
A short description, when you validate lots of GBs over and over with
md5sums (or another hash) there are errors found.
We do not yet know the real res
Package: kernel
Severity: critical
Justification: causes serious data loss
Hi everybody.
I'm currently (together with others) investigating in a severe data
corruption problem that at least many users might suffer from.
A short description, when you validate lots of GBs over and over with
md5sum
Hi.
Sorry that I've ignored the last answers to the bug but I somehow missed
the mail.
First of all,.. there is still no other solution than iommu=soft (at
least as of my knowledge) and we had even someone on the bugreport at
bugzilla.kernel.org who claimed that _only_ iommu=soft helped, but not
Steve Langasek wrote:
>> In all doing respect, I think that it's a much greater risk to not use
>> iommu=soft per default than doing so. Even if we imagine that there
>> would by systems that don't work with the sw-iommu it's likely that
>> they simply break (at boot time). And then the affecte
Hi Steve.
As I've told you in my email before I just tested your patch with the
following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
testing, of course on an amd64 system):
- The patch applies without problems
- The kernel compiles with it without problems (at least with my config)
Steve Langasek wrote:
> But regardless, there are no plans
> for another kernel update before etch r0, and including one is likely to
> delay the release. I'm of the opinion that this bug does not justify a
> delay at this point.
>
Uhm, sad to hear this...
> With the consent of the kernel
Andreas Barth wrote:
> BTW, we intended to have frequent kernel uploads to proposed-updates,
> and frankly speaking, I personally don't mind to already have a newer
> kernel in proposed-updates during the release, but that's something I
> want to have signed-off by Martin.
The main problem with the
Steve Langasek wrote:
> Well, there's no reason that someone can't use iommu=soft when booting the
> installer, as well. So perhaps it would be best to clone that bug and
> include this information in the installation guide or errata?
>
Yes that's a good idea.
I assume it would be also a probl
Package: initramfs-tools
Version: 0.92b
Severity: wishlist
Could you please move the get_fstype() from
/usr/share/initramfs-tools/scripts/local
to /usr/share/initramfs-tools/scripts/functions so that other scripts
can use it, too?
(My problem is, that I have a script in local-top, that tries to
On Mon, 2008-06-23 at 17:36 +0200, maximilian attems wrote:
> that shouldn't be needed, did you try booting with rootdelay=X ?
No,... but isn't rootdelay a delay for mounting the root-filesystem? I'm
temporarily mounting another filesystem (USB-stick) where the key for
dm-crypt/cryptsetup lies.
>
Just had a look at this by comparing the list of kernel modules loaded
just before cryptsetup waits for passphrase entry at boot, with
modules=most and =dep.
By that I found out, that with =most the module psmouse is loaded while
it is not with =dep.
If I add psmouse to /etc/initramfs-tools/modul
Hey.
I just ran into the same problem in bullseye.
Linux lcg-lrz-admin 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09)
x86_64 GNU/Linux
Salvatore, AFAICS, that kernel should already contain the commit you've
mentioned, however, it still gives an error about missing firmware.
Downloading t
Source: linux
Version: 5.18.16-1
Severity: important
Tags: upstream patch
Hey.
This is merely a heads up, that a potentially pretty nasty data corruption
issue has been found in btrfs.
As far as I understand:
It was introduced in 5.12, has the highest chances to occur with
free space cache v2,
Control: tags -1 + patch
Hey.
The patch for this has been merged in the stable kernels... could you
please cherry pick respectively update the sid kernel ASAP?
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6
commit: a2e54eb64229f07f917b05d0c323604fda9b89f7
btrfs: fix space cache c
On Thu, 2022-09-01 at 16:40 +0200, Salvatore Bonaccorso wrote:
> 5.19.6-1 has been uploaded earlier today.
Ah,... okay... I had only seen the UNRELEASED commit in salsa.
Cheers,
Chris.
Package: initramfs-tools
Version: 0.142
Severity: important
Tags: security
Hey.
According to initramfs.conf(5):
> RESUME
> Specifies the device used for suspend-to-disk (hibernation),
> which the initramfs code should attempt to resume from. If this
>
Am 25. September 2022 20:13:26 MESZ schrieb Bastian Blank :
>On Sun, Sep 25, 2022 at 08:05:29PM +0200, Christoph Anton Mitterer wrote:
>But an attacker can already modify the kernel command line. Secure boot
>up until recently was completely incompatible with hibernation, so
>
Source: linux
Version: 5.19.6-1
Severity: critical
Justification: breaks the whole system
Hi.
6.0.3 introduced a commit that causes (permanent) CPU soft lockups
for some people with btrfs filesystems, effectively breaking the
system, e.g. when booting.
See e.g.
https://lore.kernel.org/linux-btr
Control: retitle -1 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space
cache v1 filesystems
Control: notfound -1 5.19.6-1
Control: found -1 6.0.3-1
No idea why reportbug picked 5.19.6, which I have not even installed
anymore... o.O
Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso
:
>According to your references there is the workaround of mounting with
>clear_cache,space_cache=v2 and convert the filesystem.
>
>What would one prevent doing so?
v2 space cache is still rather new and had only recently some bug
Hey.
This seems like a very trivial patch... and a very helpful one, too.
Any chance to get this merged?
Thanks,
Chris.
Package: initramfs-tools
Version: 0.140
Severity: normal
Tags: security
Hi.
AFAIU, the UMASK option is there for cases like e.g. when dm-crypt keys
are included in the initramfs.
I played a bit with it, and found that it already doesn't just affect the
final initramfs image, but also parts belo
Hey.
Seems there were at least a series of commits from upstream last
November and few again this January.
And there even seem to be some more in their dev branch.
The number of CVEs mentioned by Salvatore is worrying, but it looks
even much worse over the years for ntfs-3g:
https://cve.mitre.or
Hello there.
I just wondered whether it has even been considered to make just one
package which contains the actual kernel+modules, and another one that
contains the signatures?
I'm not an expert when it comes to the binary layout of that, but
AFAIU, the modules are anyway the same between the
Hey Ben.
Nice to see a package for that :-)
On Tue, 2024-06-25 at 00:46 +0200, Ben Hutchings wrote:
> > net.ipv4.conf.all.rp_filter=1
>
> This is (effectively) set to 2 by the new configuration.
Just wondered why not using 1?
AFAIU, the RFC would recommend strict mode (1). Does that break
anyth
Hey.
Is this still followed up or already supported to some extent in the
meantime?
I've looked through the previous messages and suggested patches and
some notes on these:
- Auto-detection of resume device, when resuming happens, is most
likely a security hole, as I've described previously in
Source: linux
Version: 6.1.11-1
Severity: normal
Hey.
Over the year this has unfortunately happened numerous times, either by changes
in the Xorg driver, or libinput... and now it seems the kernel caused the
same:
After upgrading from linux-image-6.1.0-3-amd64 to linux-image-6.1.0-4-amd64 and
a
Hey Salvatore.
On Wed, 2023-02-15 at 07:12 +0100, Salvatore Bonaccorso wrote:
> Just to be sure, that I understood you correctly. That is if on the
> current system with the issue you roll back just only the kernel back
> to 6.1.8-1, then the issue dissaper?
Exactly, and the roll back even only
Package: initramfs-tools
Version: 0.140
Severity: normal
Hey.
Just noted by coincidence, that even though I have set:
COMPRESS=zstd
and zstd is installed and even runs (seen in e.g. top utility) when running
update-initramfs -u
the files are in the end nevertheless plain cpio:
file /boot/i
Control: tags -1 - moreinfo
On Mon, 2021-05-31 at 11:08 +0200, Nicolas Schier wrote:
> To validate my argumentation,
> please set 'COMPRESS=gzip' in '/etc/initramfs-tools/initramfs.conf',
> run 'update-initramfs -u' again and compare the sizes of the
> (probably)
> zstd-compressed one with the
On Sat, 2021-06-05 at 16:23 +0200, Ben Hutchings wrote:
> You have intel-microcode installed, which prepends an uncompressed
> initramfs. Not a bug.
Couldn't it then just skip the compression altogether?
Cheers,
Chris.
On Sat, 2021-06-05 at 16:59 +0200, Ben Hutchings wrote:
> You mean, can the main initramfs be uncompressed? I'm not sure
> whether
> the kernel supports that. It's certainly not an option in initramfs-
> tools at the moment.
Forget it... I'm stupid ^^ ... it's just the microcode, that's
uncompre
Hey Bastian.
Thanks for fixing.
Is this going to be backported to bullseye?
Thanks,
Chris.
Hey Salvatore.
On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote:
> I did decide to still do so, so we can have the CVE fix migrate
> finally to testing (which took some time as well given there was the
> perl transition ongoing).
Fine for me... I think it would be nice if there was a
On Sat, 2022-10-29 at 09:23 +0200, Salvatore Bonaccorso wrote:
>
> No unfortunately we cannot do that. The reason is similar to what
> lead
> to
> https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71
> or caused bugs like #916927.
Forgive me my ignorance, b
On Sat, 2022-10-29 at 09:44 +0200, Salvatore Bonaccorso wrote:
> We do similar with intel-microcode updates, so maybe this is
> something
> we should consider to. But I think it's to early to think about a
> potential 20220913-1~deb11u1 via a bullseye point release.
It's just that for any bullseye
Package: firmware-iwlwifi
Version: 20221012-1
Severity: normal
Hey there.
There possibly is a firmware file missing. In the kernel log I see:
# dmesg | grep -i wifi
[ 158.112234] Intel(R) Wireless WiFi driver for Linux
[ 158.114662] iwlwifi :00:14.3: firmware: failed to load
iwlwifi-so-a0
Package: firmware-iwlwifi
Version: 20221012-1
Severity: normal
Hey there.
My new Fujitsu Lifebook U7512 has some Intel USB Bluetooh device:
# lsusb -v -d 8087:0033
Bus 001 Device 009: ID 8087:0033 Intel Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB
Package: debian-kernel-handbook
Version: 1.0.20
Severity: normal
Hey.
Chapter 4.2.1.1. Disk space requirements explains how to disable debug info
during, build:
> You can disable debug info by changing the value of debug-info to false in
> debian/config/arch/defines, if it's set there, or in deb
Source: linux
Version: 6.0.7-1
Severity: normal
Hey.
When I tried out some recent patch from the intel folks for i915,
I built a custom kernel as described in:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
Now before I installed the custom built de
Just noted, that part of what I wrote is probably bollocks. ^^
On Thu, 2022-11-10 at 03:37 +0100, Christoph Anton Mitterer wrote:
> $ ls -al 6.0.0-3-amd64/build 6.0.0-3-amd64/source
> lrwxrwxrwx 1 calestyo calestyo 36 Nov 5 14:41 6.0.0-3-amd64/build ->
> /usr/src/linux-headers-6
Hey Diederik and Bastian
On Thu, 2022-11-10 at 13:07 +0100, Bastian Blank wrote:
> Those symlinks are included in linux-headers-6.0.0-3-amd64, see
> https://packages.debian.org/sid/amd64/linux-headers-6.0.0-3-amd64/filelist
>
> Did you remove that package as well?
You are both right, I have lin
Package: klibc-utils
Version: 2.0.11-1
Severity: normal
Tags: upstream
Hey there.
There’s a bug in ash-bashed shells, including the one shipped with
klibc.
The original variant is described here (for dash):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024635
respectively
https://lore.kern
Hey Ben.
On Sun, 2022-11-27 at 17:51 +0100, Ben Hutchings wrote:
> I don't think I will work on this in klibc until there's a fix in
> upstream dash. If you're still watching upstream dash, please let me
> know when there's a fix I can pick.
A patch has now been posted for dash at:
https://lore.
Just for the records, meanwhile I've also opened a proper ticket about
this over at BusyBox regarding the same bug in their sh at:
https://bugs.busybox.net/show_bug.cgi?id=15171
Package: nfs-kernel-server
Version: 1:1.3.4-6
Severity: wishlist
Hi.
It may make sense to ship exports(5) manpage in nfs-common as the same file
is also used by other NFS server implementations (e.g. one of them would be
dCache (http://dcache.org/), which provides a pNFS 4.1 server).
And obviso
Hey.
I've just wondered whether there is recommended way to find out whether
one is currently "within" the initramfs (i.e. early boot) as generated
by Debians initramfs-tools, or not?
I'd have probably done something like checking for:
if [ -f /conf/initramfs.conf ] && [ -f /scripts/init-top/ORDE
Hey Romain.
Thanks for your ideas:
On Wed, 2021-10-06 at 18:49 +0200, Romain Perier wrote:
> Quickly, few ideas (perhaps not the perfect ones):
> 1. Check for what is currently mounted as "/" ? (which technically
> should differ between initramfs or real rootfs)
That sounds like a pretty nice id
Hey.
Wanted to ask here, before I make (probably unnecessary noise at
lkml).. O:-)
I just noticed that \r is not escaped in e.g. /proc/mounts (and
possibly similar files that do such escaping).
The output does in fact contain then a \r, so I guess parsing for most
(all?) shell tools should be
Source: linux
Version: 5.14.12-1
Severity: normal
Hey.
There are some leftovers when purging:
Purging configuration files for linux-image-5.14.0-2-amd64 (5.14.9-2) ...
rmdir: failed to remove '/lib/modules/5.14.0-2-amd64': Directory not empty
dpkg: warning: while removing linux-image-5.14.0-2-a
This bug has actually NOT been fixed.
It's NOT the one with the CPU not going into the RC6 state.
Cheers,
Chris.
On Sun, 2021-05-02 at 15:56 +0200, Salvatore Bonaccorso wrote:
> In this case I'm reopening the bug again. But I suggest to ping again
> upstream in this case, because without progress/movement/ideas
> upstream we cannot do anything here downstream.
I'm afraid that upstream has shown pretty clearl
Hey.
I'm a bit disturbed by seeing such a regression added so shortly before
release.
AFAIU the NEWS entry:
>* If the /usr filesystem is on a RAID device and the INITRDSTART
> setting in /etc/default/mdadm is not 'all', you will need to change
> it to include that device.
the value (which de
Package: src:linux
Version: 3.19.1-1~exp1
Severity: normal
Hi.
Not sure whether this bug is actually within the kernel or
whether the real problem is rather in libvirtd or network-manager
(which is always a valid suspect of screwing up network things).
Since I've upgraded from 3.16 from sid to
Source: linux
Version: 5.2.9-2
Severity: critical
Tags: upstream patch
Justification: causes serious data loss
Hi.
There were some reports over the last weeks from users on linux-btrfs which
suffered from catastrophic btrfs corruption.
The bug which is apparently a regression introduced in 5.2 h
Hey.
Just to put some emphasise on this, the fix has now been merged late to
5.3 as urgent.
Also note Filipe's post[0] that the issue can more or less hit anyone.
Cheers,
Chris.
[0]
https://lore.kernel.org/linux-btrfs/9731b0e7-81f3-4ee5-6f89-b4fd8d981...@petaramesh.org/T/#m7b3863ef7ec5f62a2f7
Hey.
Is there anything one can help to speed this up?
A patch is available for two weeks now, while Debian users of testing
and unstable are left with the danger of catastrophic btrfs corruption
without even any warning to them (so that they could at least downgrade
to <5.2).
Cheers,
Chris.
Source: linux
Version: 5.3.7-1
Severity: important
Hi.
Apparently changes from 5.2+107 -> 5.3.7-1 break sound completely.
As soon as I login to the desktop environment the following goes of:
Oct 24 18:33:10 heisenberg kernel: snd_hda_intel :00:1f.3: azx_get_response
timeout, switching to p
Source: linux
Version: 4.19.20-1
Severity: critical
Tags: upstream patch
Justification: causes serious data loss
Hi.
Apparently there was a longer existing data corruption bug in btrfs[0],
AFAIU it happened when compression was used together with holes in data
and there was *no* recognition by ch
Here's the "proper" patch:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg85515.html
Hey Ben, Salvatore.
Thanks for cherry-picking the bug for unstable.
AFAIU stretch and jessie[-backports] should be affected as well.
Shouldn't it go there, too?
At least at the upstream mailing list it was said[0] the the bug was
introduced around October 2008, which should be roughly kernel 2.6
btw: 5.3.15-1 seems to be still affected.
While I see mostly "normal" temperatures right after boot (and when
everything has settled)... after some point in time, tmeperatures get
up and remain at high levels, e.g. :
Package id 0: +81.0°C (high = +100.0°C, crit = +100.0°C)
Core 0:+7
I should perhaps add that there is some slight indication that this
might be graphics related.
Cause when I switch from the running X/Cinnamon (with the CPU at
average temperatures between 75-70°C, while top doesn't show really
much) to the virtual kernel console, temperatures go down drastically
Package: linux-base
Version: 4.6
Severity: grave
Justification: renders package unusable
Hi.
Since last April, the package can't be upgraded as it conflicts with
the current version of kernel-common.
Would be nice if this could be resolved.
Probably it's this change:
* Take over kernel-img.c
Control: severity -1 grave
Raising severity, since this current kernels are completely unusable on
at least some hardware (i.e. the one I use here), since the temperature
just explodes.
I'd say grave is justified already by potential hardware damages of
systems running even at little actual load a
Control: forwarded -1
https://lore.kernel.org/lkml/d05aba2742ae42783788c954e2a380e7fcb10830.ca...@scientia.net/
Hey.
I've forwarded this to lkml.
My most recent post in that thread[0] contains an pretty elaborate test
series comparing kernel 5.2 vs. 5.4 (each with intel_pstate=disable and
witho
Hey.
According to https://gitlab.freedesktop.org/drm/intel/issues/953 the
bug was introduced by:
drm/i915/gen8+: Add RC6 CTX corruption WA
(d4360736a7c0a6326e3bbdf7d41181f6ed03d9a6)
which, AFAIU, is actually a security fix.
There seem to be some patches, but not sure when they'll be "final" (i
1 - 100 of 183 matches
Mail list logo
