Looks like this is the likely candidate:
commit 7fa1a35564b270e940111c31828e553bff8f063b
Author: Gustavo A. R. Silva
Date: Thu Aug 2 22:40:19 2018 -0500
drm/i915/kvmgt: Fix potential Spectre v1
info.index can be indirectly controlled by user-space, hence leading
to a
** Summary changed:
- kernel bug causes i915 modesetting to not work
+ regression: between 4.15.0-45 and 4.15.0-50 - i915 vmalloc_fault
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834177
Title:
e. A short time after that I tried
to use that auto-mount directory again ("/home/tj/SourceCode") and the
shell hung. I tried from several more shells with different commands
with the same result.
Initially couldn't see any clues in the logs but after a while the
kernel dump
time after that I tried
to use that auto-mount directory again ("/home/tj/SourceCode") and the
shell hung. I tried from several more shells with different commands
with the same result.
Initially couldn't see any clues in the logs but after a while the
kernel dumped a couple of stack trace
Tested with the 19.10 daily (2019-06-22) amd64 build and the problem
affects the live environment too.
Set x-p-m Lid Close action on battery to suspend and the 2nd lid close
cycle results in DPMS=off when the GUI TTY is active.
As in comment #15 I monitored the LVDS DPMS state whilst switching
I modified libxrandr to return the actual error code returned from
XRRSetCrtcConfig():
--- libxrandr-1.5.1.orig/src/XrrCrtc.c
+++ libxrandr-1.5.1/src/XrrCrtc.c
@@ -155,9 +155,10 @@ XRRSetCrtcConfig (Display *dpy,
req->mode = mode;
req->rotation = rotation;
Data32 (dpy, outputs,
We have a second bug that causes the call by update-
initramfs::get_sorted_versions() to report nothing when calling
(/usr/bin/) "linux-versions list".
This because the target root file-system is copied from the
filesystem.squashfs on the ISO which does NOT contain a
/boot/vmlinuz-$(uname -r).
I should have made clear, this 'second bug' is the only bug.
initrmafs-tools is in the clear - it wasn't finding a kernel image
because there wasn't one when update-initramfs was executed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Or is it? Actually I not, because the test in update-
initramfs::get_sorted_versions() expects an existing
initrd.img-$version:
get_sorted_versions()
{
version_list="$(
linux-version list |
while read -r version; do
test -e
After many hours diving down rabbit holes it turns out this is due to a
major change in the behaviour of update-initramfs introduced by Debian
in July 2018 which made its way into the Ubuntu archive end of april
2019.
01:02 Right! initramfs-tools had a MAJOR import from Debian with
** Also affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of
The problem seems to be in the calamares configuration. The initramfs
task is being called before the target's live-* packages have been
removed. This is specifically warned about in the calamares initramfs
module but we see the timestamps of the initramfs task are before the
live-* packages are
The problem here is the installer failed to build/install initrd.img.
After installing into a LVM LV via libvirt and seeing the error I
mounted the disk image contained in the LV and explored:
$ sudo losetup -f --show -P /dev/VG02/lubuntu1910
/dev/loop5
$ sudo mount /dev/loop5p1 /mnt/target
$
It appears from the screenshot the panic is occurring because the
initramfs /init script is failing to find and mount the real root file-
system.
You can drop to a busybox shell in the initramfs by adding a kernel-
command line option manually in the GRUB boot menu.
Tap Esc key to get to the
Added:
Description: Loop delay on CRTc config failure
--- xfce4-settings-4.13.4.orig/xfsettingsd/displays.c
+++ xfce4-settings-4.13.4/xfsettingsd/displays.c
@@ -1256,10 +1256,17 @@ xfce_displays_helper_apply_crtc (XfceRRC
ret = xfce_displays_helper_disable_crtc (helper, crtc->id);
The reason the CRTC isn't configured:
(xfsettingsd:1694): xfsettingsd-WARNING **: 15:02:36.290: Failed to
configure CRTC 79 XRRSetCrtcConfig()=3.
This due to my patch:
--- xfce4-settings-4.13.4.orig/xfsettingsd/displays.c
+++ xfce4-settings-4.13.4/xfsettingsd/displays.c
@@ -1265,7 +1265,7 @@
I've captured a log where it doesn't fail. The difference is a single
error message. In failing sessions there is an additional "Failed to
configure CRTC..." which is not seen here:
xfce4-settings(displays): UPower lid event received (closed -> open).
xfce4-settings(displays): Toggling internal
This seems to be the crux of the issue. In a VT console I did:
DISPLAY=:0 XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon
and the did the usual lid-close->resume cycle and found:
xfce4-settings(displays): UPower lid event received (open -> closed).
xfce4-settings(displays): Toggling
Finally found some evidence and it is surprising.
I added /usr/local/bin/xfce4-power-manager:
#!/bin/sh
exec /usr/bin/xfce4-power-manager --debug
and logged in as normal. Confirmed x-p-m is writing debug messages.
Closed the lid, it suspended, opened lid and tap key to resume as per
usual.
Yet more results changing the target once again!
I was able to reproduce the issue whilst using sddm which tends to
suggest lightdm may not be the cause.
I also managed to prove (not sure why this did not occur to me before
now!) that the DPMS state is being set 'off' when switching to the GUI
maxpus=1 still suffers the same issue.
I then disabled and stopped the upower daemon but the issue remains with
the only common factors being systemd-logind and lightdm.
I tried console-only tests with lightdm stopped and CANNOT reproduce the
issue.
I installed sddm and changed the default
I purged both xfce4-screensaver and light-locker packages, restarted
lightdm and tested with x-p-m set to suspend on lid-close for battery
(and AC as I've had the battery exhaust several times due to the length
of these tests!)
In this case there is no password challenge dialog on resume.
It
On brainwash's suggestion (IRC #xubuntu-devel) I disabled UPower's Lid
handling with /etc/UPower/UPower.conf:
IgnoreLid=true
After six suspend-resume cycles this does seem to have prevented the issue.
*However* I then noticed that in the x-p-m dialog, General tab, the
options to control the
Update: Disabling x-p-m Security > Lock screen when system is going to
sleep causes the LCD to be blank resume for the 1st cycle.
This definitely feels like some weird interaction with x-p-m, light-
locker, and logind.
--
You received this bug notification because you are a member of Ubuntu
And it gets weirder... with supend-lock disabled AND leaving x-p-m
dialog box on screen whilst suspending the LCD always gets enabled on
resume!
I tried leaving other application windows open but those don't have the
same effect.
--
You received this bug notification because you are a member of
I've done some more tests with another clean install of 19.04; The only
user setting I changed was on x-p-m for Laptop Lid Closed, On Battery =
suspend.
1st suspend=resume cycle is fine; user session re-appears after
unlocking with password
*BUT*
2nd suspend-resume cycle turns the LCD panel off
More search seems to point to a 2015 commit that integrated light-locker
into xfce4-power-manager. This patch in particular appears to attempt to
work with logind Lid handling too:
commit 10076da7caa49320b3e907d319a9f27ee6702969
Author: Sean Davis
Date: Sat Feb 7 11:49:31 2015 +0300
Light
To check on current systemd-logind properties including these:
$ loginctl -a show-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1759950
Title:
Lid-close suspend: blank screen when
** Bug watch added: Xfce Bugzilla #15151
https://bugzilla.xfce.org/show_bug.cgi?id=15151
** Also affects: systemd via
https://bugzilla.xfce.org/show_bug.cgi?id=15151
Importance: Unknown
Status: Unknown
** Changed in: xfce4-power-manager (Ubuntu)
Status: New => Confirmed
Turns out this *is* systemd-logind and xfce4-power-manager fighting over
the lid close event.
It can be solved with:
echo "HandleLidSwitch=ignore" | sudo tee -a /etc/systemd/logind.conf
echo "HandleLidSwitchExternalPower=ignore" | sudo tee -a
/etc/systemd/logind.conf
If you're doing this
Just having upgraded several laptops to 19.04 and been hit by this
again. Did some more research and revisited my upstream report and
suspect this is caused by some interaction with the power manager and
possibly systemd-logind (maybe they both try to set DPMS state for lid-
close/open events? )
** Changed in: linux (Ubuntu)
Assignee: TJ (tj) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
Title:
rtlwifi: aggresive memory leak
To manage notifications ab
Had a user in IRC #ubuntu today re-rporting this for 18.04 when trying
to use Onboard. The user was asked to create a new bug report for their
issue but may not do so.
Adding this link which may be useful for other users caught by this:
Public bug reported:
On 18.04 amd64 whilst trying to build an 18.04 package:
W: copy:///<>/resolver-uIDqUN/apt_archive/./Release.gpg: The key(s)
in the keyring /etc/apt/trusted.gpg.d/sbuild-build-depends-archive.gpg are
ignored as the file is not readable by user '_apt' executing apt-key.
W:
** Changed in: linux (Ubuntu)
Status: In Progress => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
Title:
rtlwifi: aggresive memory leak
To manage notifications about this
** Description changed:
Hey, i got a memory leak on Ubuntu 18.04.2 even in console mode (no X/GUI)
the memory usage grows slowly to take all the available RAM when i let the
computer running over the night (with just top and irssi), and i have to reboot
to get things back to normal. I didn't
** Summary changed:
- Possible memory leak due to PCI AER faults even with pci=noaer
+ rtlwifi: aggresive memory leak
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
Title:
rtlwifi:
Packages for 4.18.0-20.21-kmemleak are currently building in my bug-
fixes PPA. See
https://launchpad.net/~tj/+archive/ubuntu/bugfixes/+packages
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
providing the same
file with different content.
tj ~ apt-file list live-tools | grep man
live-tools: /usr/share/man/ca/man7/live-tools.7.gz
live-tools: /usr/share/man/ca/man8/live-update-initramfs.8.gz
live-tools: /usr/share/man/de/man1/live-system.1.gz
live-tools: /usr/share/man/de/man1/live-toram
** Description changed:
Hey, i got a memory leak on Ubuntu 18.04.2 even in console mode (no X/GUI)
the memory usage grows slowly to take all the available RAM when i let the
computer running over the night (with just top and irssi), and i have to reboot
to get things back to normal. I didn't
** Attachment added: "ps -efly at startup"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268936/+files/ps-efly.nogui-at-startup.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: "kern.log OOM extract from earlier GUI-based boot"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268935/+files/kern.OOM.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: "dmesg after leaving overnight"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268934/+files/dmesg.after-overnight.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
: (unassigned) => TJ (tj)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
Title:
Possible memory leak due to PCI AER faults even with pci=noaer
To manage notifications about this
** Attachment added: "dmesg after startup"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268933/+files/dmesg.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
** Attachment added: "lspci -vvvnnk"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268932/+files/lspci-vvvnnk.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
** Attachment added: "lspci -tvvvnn"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268931/+files/lspci-tvvvnn.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
** Attachment added: "PCI AER error log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831751/+attachment/5268930/+files/pci_aer.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831751
** Description changed:
Hey, i got a memory leak on Ubuntu 18.04.2 even in console mode (no X/GUI)
the memory usage grows slowly to take all the available RAM when i let the
computer running over the night (with just top and irssi), and i have to reboot
to get things back to normal. I didn't
** Description changed:
Hey, i got a memory leak on Ubuntu 18.04.2 even in console mode (no X/GUI)
the memory usage grows slowly to take all the available RAM when i let the
computer running over the night (with just top and irssi), and i have to reboot
to get things back to normal. I didn't
Further investigation revealed that a change to the semantics of
'cryptsetup' tool is responsible for the specific manual build I did.
On 18.04 'cryptsetup luksFormat --type=luks ...' would create a LUKS v1
header. On 19.04 it creates a LUKS v2 header. GRUB only supports LUKS v1
headers
I've confirmed this with a new 19.04 install, and it's not just the
d-r-u process.
In a manually configured system with:
sda3 -> LUKS_BOOT > /boot/
sda4 -> sda4_crypt -> LVM -> /dev/mapper/ubuntu-rootfs -> /
# grep -rn GRUB_ENABLE_CRYPTODISK /etc/default/grub /etc/grub.d/
/usr/lib/grub/
** Changed in: grub2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813126
Title:
Full-disk encryption: Unbootable system after upgrade to Ubuntu 19.04
Additional, more positive, discussion.
12:59 or just relax the policy and let us get LE certs outselves, just
like for all the other names
13:00 maybe we could do that if we registered a new domain name
13:01 I'll bring it up again soon
13:03 the problem is we round robin mirrors under
s it is a CODB (cost of doing business) if Canonical wants
to be taken seriously
12:52 Yeah. My mirrorbits solution would around to encourage more use
of [verified good] mirrors to offset the direct costs a bit
12:54 Something like https://download.lineageos.org/star2lte
12:55 TJ-: that is still
The kernel driver (dkms) fails to build due to the bad logic in
drivers/Makefile trying to detect the non-existent modversions.h (Ubuntu
kernels do not use CONFIG_MODVERSIONS ) and thus not adding
-I$(KERNEL_DIR)/include to the search path - so cannot find
linux/init.h
Even with that fixed there
The previous patch (v2) had a problem when the server reloaded. Because
fork() wasn't done the tell-tale child_pid (-3) got passed to the PID
file! This version should avoid that.
** Patch added: "Bring PID creation into parent process v3"
I've developed and tested a different approach. More invasive and
probably not something upstream will like the look of!
The approach is to have ngx_daemon() not do the parent process exit()
after fork() but to return the child PID. The parent process detects
that (a value > 0), sets ngx_pid =
This may be a viable workaround.
For a systemd Type=fork unit 'success' is determined when the parent
process exits. At this time systemd expects the PIDFile to exist. nginx
actually creates the PID file in the forked process.
Presumably on single CPU systems there is a sufficient delay in
Driver is in v4.20 according ot [1] - the site also documents some user-
space configuration options.
[1] https://github.com/robotrovsky/Linux-Magic-Trackpad-2-Driver
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1829620 ***
https://bugs.launchpad.net/bugs/1829620
** This bug has been marked a duplicate of bug 1829620
intel-microcode on ASUS makes kernel stuck during loading initramfs on
bionic-updates, bionic-security
--
You received this bug notification
Steve: Another possible system affected where disabling microcode
loading appears to have fixed it. I'll leave it to you to decide whether
that is a duplicate of this issue though:
LP: #1829402 "Purple screen hangup during boot"
Tom and myself have spent some considerable time with the affected
This looks to be related to LP: #829620 "intel-microcode on ASUS makes
kernel stuck during loading initramfs on bionic-updates, bionic-
security" which until now we thought only affected particular models.
Intel are aware, and this issue is being tracked in that bug.
--
You received this bug
This appears to be caused by the partitioning on the target install
disk. In the UbiquityPartman.txt log-file it shows towards the end there
are 3 primary and 4 logical partitions, which means the disk label is
MSDOS not GPT.
Looking further there is no EFI System Partition on /dev/sda.
Mark:
An additional kernel command-line option that might reveal more would be
remove "quiet splash" and add "debug early_print=XXX" where XXX is vga
for BIOS-mode or efi for UEFI mode boots.
You may find "earlycon" added into the mix may also add more early
messages.
See
Mark
I just realised your report isn't about cryptsetup being the problem and
you never reach the initialramfs shell.
Your report that the last thing you see is "my system gets stuck at
"Booting, Loading initramfs" tells us the kernel isn't starting. Those
messages come from GRUB when it loads
Mark
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
cryptsetup stuck at loading initramfs
To manage notifications about this bug go to:
Mark:
With a LUKS encrypted system, when a new kernel is installed "update-
initramfs -u -k $KERNEL_VERSION" is executed.
As part of that cryptsetup hooks scripts are called. They examine
/etc/fstab and /etc/crypttabto determine if the root file-system, or
swap (which may be used for
15:38 TJ-, for a brief moment i saw 2-3 lines of text, first line
is "error: no video mode activated"
15:38 was unable to see more.
15:38 but this is a successful boot no purple screen this time
15:38 Jackneill: so, GRUB_TERMINAL=console was successfully booted to
desktop?
15:39
Can we collect more information about the circumstances in which this
happens, since these can often be crucial in narrowing down the
possibilities and identifying a solution?
1. Does the problem occur if the system is completely powered off
between reboots (as opposed to what is called a 'warm'
Public bug reported:
On 18.04, amd64:
$ sudo apt install libtagsoup-java librhino-java icedtea-netx:i386
Reading package lists... Done
Building
Ghah! After pressing "Post Comment" also found this firmer confirmation
of (part of) the algorithm:
"Solution: From 0-2 TB the sector size is 512k. From 2-4 TB the sector
size is 1028k. Then from 4 + it changes the sector size to 2048k thats
why the information is displayed in as unallocated.
Due to this issue being brought to IRC #ubuntu I did some background
research to try to confirm Danny's theory about sector-size.
So far the best resource I've found in the Promise Knowledge base
(kb.promise.com) is:
https://kb.promise.com/thread/how-do-i-create-an-array-larger-than-2tb-
Continuing issues up to and including 5.0.0-8. Experienced three lock-
ups today.
I strongly suspect the iwlwifi device but as the lock up is total and
silent there are zero clues.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1817308 ***
https://bugs.launchpad.net/bugs/1817308
I installed the fix. Both computers and both printers back to normal.
Life is good. Thanks!
On Sat, Feb 23, 2019 at 10:55 AM Launchpad Bug Tracker <
1817...@bugs.launchpad.net> wrote:
> Status changed
Public bug reported:
This has happened to both of my computers running xubuntu. My first
computer, I updated yesterday. The second computer did not exhibit the
problem this morning. Once I updated the software with Software
Updater, it acquired the same issue.
ProblemType: Bug
DistroRelease:
*** This bug is a duplicate of bug 1813663 ***
https://bugs.launchpad.net/bugs/1813663
Upstream commit ID is be1c63c8017bb00a4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813745
Title:
*** This bug is a duplicate of bug 1813663 ***
https://bugs.launchpad.net/bugs/1813663
Marking this as a duplicate of bug #1813745 since that already has a
test kernel build available which you should try, and if it solves the
issue, confirm on that bug.
** This bug has been marked a
*** This bug is a duplicate of bug 1813663 ***
https://bugs.launchpad.net/bugs/1813663
** This bug is no longer a duplicate of bug 1813765
Regression/crash in i915 for 4.15.0-44.47
** This bug has been marked a duplicate of bug 1813745
ubuntu 18-04 hangs on graphical start with kernel
The 4.15.0-44 kernel in in the bionic-proposed pocket. Looks like we
need to pull it due to this regression until this is resolved.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813765
Title:
>From an initial reading of the commit history I suspect the issue may be
caused by e417085e79136d9f955 "drm/i915/dp: Send DPCD ON for MST before
phy_up" which deals with power transitions during monitor
connect/disconnect.
--
You received this bug notification because you are a member of Ubuntu
Initial summary of the changes affecting i915 specifically:
gitlog Ubuntu-4.15.0-43.46..Ubuntu-4.15.0-44.47 -- drivers/gpu/drm/i915
d2da7cbf2ae0 2019-01-14 09:28:55 + N Ville Syrjälä drm/i915: Fix PIPESTAT
irq ack on i965/g4x
e417085e7913 2019-01-14 09:28:55 + N Lyude Paul drm/i915/dp:
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
** This bug has been marked a duplicate of bug 1542939
system freeze after vt switching
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
Based on the original report's JournalErrors.txt showing:
"vblank wait timed out on crtc 0"
marking this as a duplicate of the master bug #1542939
** This bug has been marked a duplicate of bug 1542939
This has *just* had a fix committed upstream and is hoped to be
available in v5.0. Could we get it backported to the LTS kernels?
commit ed20151a7699bb2c77eba3610199789a126940c4
Author: Ville Syrjälä
Date: Tue Nov 27 20:20:04 2018 +0200
drm/vblank: Allow dynamic per-crtc max_vblank_count
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
** This bug has been marked a duplicate of bug 1542939
system freeze after vt switching
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
** This bug has been marked a duplicate of bug 1542939
system freeze after vt switching
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
** This bug has been marked a duplicate of bug 1542939
system freeze after vt switching
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
** This bug has been marked a duplicate of bug 1542939
system freeze after vt switching
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1542939 ***
https://bugs.launchpad.net/bugs/1542939
** This bug has been marked a duplicate of bug 1542939
system freeze after vt switching
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This has *just* had a fix committed upstream and is hoped to be
available in v5.0. Could we get it backported to the LTS kernels?
commit ed20151a7699bb2c77eba3610199789a126940c4
Author: Ville Syrjälä
Date: Tue Nov 27 20:20:04 2018 +0200
drm/vblank: Allow dynamic per-crtc max_vblank_count
** Description changed:
This is affecting 18.04 and others where cryptsetup v2 is used and has
created a LUKS v2 container.
If booting to a shell in initialramfs with "break=premount" and manually
executing:
cryptsetup --debug open /dev/sda3 LUKS_VG
...
Userspace crypto
** Description changed:
This is affecting 18.04 and others where cryptsetup v2 is used and has
created a LUKS v2 container.
If booting to a shell in initialramfs with "break=premount" and manually
executing:
cryptsetup --debug open /dev/sda3 LUKS_VG
...
Userspace crypto
It may be that cryptsetup needs to be taught to use offset= and skip=
for LUKS as well as plain.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810235
Title:
cryptsetup silently fails in live
Public bug reported:
This is affecting 18.04 and others where cryptsetup v2 is used and has
created a LUKS v2 container.
If booting to a shell in initialramfs with "break=premount" and manually
executing:
cryptsetup --debug open /dev/sda3 LUKS_VG
...
Userspace crypto wrapper cannot use
** Changed in: linux (Ubuntu)
Status: In Progress => Incomplete
** Changed in: linux (Ubuntu)
Assignee: TJ (tj) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1
Have you used the service tag to see if you can get a link to the Dell
Ubuntu 16.04 installation images?
"For those who purchased their system from Dell with Ubuntu already
installed, there are recovery images on their system and if fitting a
new hard drive they can download an installation image
Related Canonical/Ubuntu hardware certification for this model. Notes
suggest Dell-installed image is/may not be the same as used by Ubuntu.
https://certification.ubuntu.com/hardware/201707-25590/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Here is another related experience which may give some insight:
https://ubuntuforums.org/showthread.php?t=2381899
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812758
Title:
Boot failure on Dell
** Summary changed:
- Boot failure on Dell Dell Precision 5820 with Intel Xeon W-2123 CPU
+ Boot failure on Dell Precision 5820 with Intel Xeon W-2123 CPU
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) =>
201 - 300 of 2979 matches
Mail list logo
