Yes it's still happening on 3.13.0-29-generic.
[3.912539] random: nonblocking pool is initialized
[ 19.999335] Adding 3957756k swap on /dev/sda7. Priority:-1 extents:1
across:3957756k FS
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
** Tags removed: kernel-request
...ignoring the bot and changing the state back to New, as the exact
kernel version doesn't matter...
** Changed in: linux (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://
Changing to confirmed to satisfy the bot. :)
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1259861
Title:
5-10 seco
I just tested with linux-
image-3.13.0-031300rc3-generic_3.13.0-031300rc3.201312061335_i386.deb,
it doesn't happen there.
I don't think I should put the 'kernel-fixed-upstream' tag as the
problem might be in some Ubuntu-specific kernel patch or configuration
option that's been around for a couple
06e:brightnessup
e071:f22
(ok, removed with last patch)e072:f22
e073:prog2
e075:presentation
e078:fn
e079:f23
Kind regards,
Alkis Georgopoulos
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architectu
Public bug reported:
Reusing a master ssh socket that is created on an overlayfs mount
reports connection refused, while on real filesystems or on tmpfs it
works fine.
Steps to reproduce (/var is ext4, /tmp is tmpfs.):
# mkdir -p /var/overlayfs-socket
# cd /var/overlayfs-socket
# mkdir root rofs
AFAIK, overlayfs is not mainlined yet.
The problem I reported exists in the Ubuntu patched kernels of at least
Precise, Raring and Trusty though.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Package
Hi Christopher, as mentioned in my other kernel related bug reports I
just didn't know that launchpad wasn't the appropriate place to report
kernel bugs. So for some of my bug reports I provided feedback for 3-4
years and the only result I got was the occasional "can we close it
now?" answer.
I'll
The problem is not there in Ubuntu 12.04.2 (kernel 3.5.0-54)
and it is there in Ubuntu 12.04.3 (kernel 3.8.0-44).
My test case is to boot with ip=dhcp break=top. When the problem doesn't
exist, I get an initramfs prompt in 2 seconds, when it exists I get it
in 12 seconds, and that shows up in dmes
I think the upstream commit that set CONFIG_IP_PNP=y is this:
https://github.com/torvalds/linux/commit/c1b362e3b4d331a63915b268a33207311a439d60#diff-364c3610ebc6899c22148ba10636c71c
Ubuntu and openSUSE now have CONFIG_IP_PNP=y and experience the issue.
Debian and Fedora do not have CONFIG_IP_PNP s
> TJ (tj) wrote 9 hours ago:#26
> Originally introduced into the Ubuntu 13.10 (Saucy) configuration with commit
> 301b4bb
> UBUNTU: rebase to v3.10-rc4
TJ, that doesn't match my tests as mentioned in comment #21,
i.e. that I see the issue since kernel 3.8, and that
https://wiki.ubuntu.com
$ for d in karmic lucid maverick natty oneiric precise quantal raring saucy
trusty utopic vivid wily xenial; do
echo "$d: $(wget -q
http://kernel.ubuntu.com/~kernel-ppa/configs/$d/i386-config.flavour.generic -O
- | grep -w CONFIG_IP_PNP)"
done
karmic:
lucid:
maverick:
natty: # CONFIG_IP_
apw uploaded a test kernel without CONFIG_IP_PNP in
http://people.canonical.com/~apw/lp1259861-xenial/.
I tested it with "ip=dhcp break=top" and it didn't have the 10 sec delay.
Thanks a lot Andy!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscr
I think anyone can just run `dmesg` and verify that the bug exists in all
recent Ubuntu kernels and in none of the vanilla or Debian kernels.
I don't know why the logs are important here.
I don't think there's any point in closing bugs just to lower the bug count
(which means nothing if the bugs
@penlalvch: I was asked in #ubuntu-kernel to file this bug report so
that they can assign someone to work on it.
If you keep adding "it needs this and that" tags, then this bug report
appears to be incomplete, and no developer will start working on it
until I satisfy/remove the tags.
But as I kee
@penalvch: as I mention in comment #6, the "kernel-fixed-upstream" tag
is not appropriate because this was never an upstream bug, so nothing
was fixed upstream. It's an ubuntu-specific bug, so upstream is not
related at all to this bug and shouldn't appear in any tags.
The "needs-kernel-logs" tag
I'm the bug reporter, and I have a problem in doing the verification.
a) The initial testcase that I reported happens in both 4.4 unpatched
and 4.10. I.e. the bug that I reported is not yet fixed.
b) Some Ubuntu developer wrote a new testcase as part of doing the SRU.
I cannot reproduce that test
I had bisected this issue and I had reported upstream on 19 Jan:
https://bugzilla.kernel.org/show_bug.cgi?id=198529.
I verify that the patch/test kernel by wgrant works fine here.
Thanks a lot!
** Bug watch added: Linux Kernel Bug Tracker #198529
https://bugzilla.kernel.org/show_bug.cgi?id=198
Public bug reported:
In Trusty I see a big delay while the kernel boots that I did not see back in
Precise.
Some people have been experiencing this in Saucy too, so I don't know exactly
when it started happening.
Excerpt from dmesg:
[3.740100] Switched to clocksource tsc
[ 14.208118] PM: H
Hi! No, updating the BIOS didn't change anything at all.
$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
V1.30
08/13/2012
I tried both with the raring kernel (3.8.0-33-generic ) on my Precise system,
and with a Trusty daily live CD, with the same results as usual.
Summary
** Changed in: linux (Ubuntu)
Status: Expired => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/345374
Title:
Silicon Integrated Systems [SiS] 191 Gigabit Ethernet
Stat
I verify that the bionic-proposed package addresses the issue.
Tested in:
# lspci -nn -k | grep -A 2 VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630
[8086:5912] (rev 04)
Subsystem: Gigabyte Technology Co., Ltd HD Graphics 630 [1458:d000]
Kernel driv
I just tried with 4.18.0-14-generic, the same issue happens there as
well.
And, another school reported the issue on HD Graphics 630:
root@pc02:~# lspci -nn -k | grep -A 2 VGA 00:02.0 VGA compatible
controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev
04) Subsystem: ASRoc
I don't know the software stacks involved:
If I understood it correctly,
mesa 18.3.3 doesn't work with older kernels while 18.0 did work,
and so I'll do a bisection to see which kernel commit fixes the issue,
and then distro kernel maintainers may cherrypick it for older kernels.
If there's no ne
Hello Sergii,
I tried with 4.20.7 and it appears to work fine! Thanks!
Output of the commands:
# uname -a
Linux srv-6gym-chalk 4.20.7-042007-generic #201902061234 SMP Wed Feb 6 17:49:39
UTC 2019 i686 i686 i686 GNU/Linux
# file /usr/bin/glxinfo
/usr/bin/glxinfo: ELF 32-bit LSB shared object, In
I tried a small kernel bisection using the ubuntu kernel binaries,
4.19.2-041902=fails,
4.19.3-041903=works
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1815172
Title:
Black screen on
Just correcting a wrong comment (#2) I made:
> It happens on both 32bit and 64bit installations.
I asked the school that reported the issue on 64bit to check again, and
they said they have a 32bit installation after all.
So the problem has only been reported in 32bit installations; I don't
know i
** No longer affects: epoptes (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1718227
Title:
replacement of ifupdown with netplan needs integration for
/etc/network/if{up,
** Package changed: linux-lts-xenial (Ubuntu) => linux-signed (Ubuntu)
** Changed in: linux-signed (Ubuntu)
Importance: Undecided => Low
** Changed in: linux-signed (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, whi
This affects the ltsp.org project too;
tftp can't access this file and we don't want to run tftpd as root for better
security,
so we end up copying vmlinuz to a dedicated tftp folder just for the Ubuntu use
case.
--
You received this bug notification because you are a member of Kernel
Packages,
This forces us to run tftpd as root, to serve $CHROOT/boot to netboot clients,
so it's actually LESS secure than it was before the change.
Applying the stat workaround isn't always easy; sometimes $CHROOT/boot
comes from a read-only loopback image.
Also note that initrd.img, which may actually co
*** This bug is a duplicate of bug 759725 ***
https://bugs.launchpad.net/bugs/759725
** This bug has been marked a duplicate of bug 759725
The kernel is no longer readable by non-root users
--
You received this bug notification because you are a member of Kernel
Packages, which is subscri
For the maintainers of the affected packages to be able to help in this issue,
addressing the main question already stated above would be most helpful:
To support netplan, do we have to implement netlink events listeners ourselves?
I'm not sure all maintainers are willing to do that.
Or is there a
@rhansen, your bug might be a different one, since ip=dhcp is processed
by the initramfs, while I'm talking about the kernel, before the
initramfs gets to run.
The bug is still there in Xenial.
I noticed that it doesn't happen in all hardware; I've seen it in *some* real
clients and under Virtual
@rhansen, sorry, it turns out you were right!
ip= is what's causing my kernel delay. I even tried without an initramfs
to verify it, and it caused 10 seconds of delay before the kernel panic
because of the missing initramfs.
I'll try to gather more info about it.
--
You received this bug notifi
Public bug reported:
Concatenating multiple initrds works fine with gzipped initrds.
(microcode+gzip+gzip) => the kernel properly decompresses that
With lz4, it can't decompress anything after the first lz4:
(microcode+lz4+whatever) => it doesn't decompress whatever.
To reproduce:
Get vmlinuz an
This is about loading the kernel/initrd, so running apport-collect on
the host won't provide any useful info, and running it inside the
initramfs isn't possible.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of
I tried all the COMPRESS= methods available in /etc/initramfs-
tools/initramfs.conf in both eoan and bionic.
For each one, I ran:
date > date.txt
echo date.txt | cpio -oH newc > date.img
update-initramfs -u
cat initrd.lz4 date.img > initrd.img
kvm -m 512 -kernel vmlinuz -initrd initrd.img -append
@xnox, thank you, in #3 I was testing date.img as a plain cpio without
compression,
while with your updated lz4/xz commands, it appears that when date.img matches
the compression of initrd.img, then it works fine.
So the problem only happens when mixed compressions are used.
Btw, the reason I w
** Summary changed:
- Concatenated lz4 initrds don't work
+ Mixed compression initrds partially work
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1840945
Title:
Mixed compression init
** Description changed:
- Concatenating multiple initrds works fine with gzipped initrds.
- (microcode+gzip+gzip) => the kernel properly decompresses that
+ Updated description:
- With lz4, it can't decompress anything after the first lz4:
- (microcode+lz4+whatever) => it doesn't decompress wha
** No longer affects: ltsp (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/183303
Title:
Can't create new wireless network using mac80211 based drivers
Status in NetworkManager:
Hi Timo,
if I remember correctly, there were some schools that were affected by this
issue, but I wasn't able to reproduce it in the office due to lack of similar
hardware.
Unfortunately it's not easy to check which were those schools; but I can keep
an eye on this issue, in case I hear about b
Exactly. I did the "verification-done-bionic" step for 18.2.2 in comment
#12 above; and unfortunately I don't have an affected school nearby,
where I could test 18.2.8 in cosmic, and installing cosmic in a remote
school would be hard.
Thanks a lot Timo!
--
You received this bug notification beca
44 matches
Mail list logo