I changed the default btrfs subvolume to the root, id 0, from
@opensuse/.snapshots/1/snapshot and now the install seems to work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1680613
Title:
Public bug reported:
I install on a existing btrfs partition with OpenSUSE intalled on a
subvolume located under @opensuse.
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: ubiquity 17.04.7
ProcVersionSignature: Ubuntu 4.10.0-13.15-generic 4.10.1
Uname: Linux 4.10.0-13-generic x86_64
** Attachment removed: "/var/log/syslog"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1680613/+attachment/4856712/+files/syslog
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1680613
Now I've tested linux-image-3.17.0-031700-generic for more than a month
and the bug seems to be fixed in it. It has woken up from sleep as it
should every time.
** Changed in: linux (Ubuntu)
Status: Expired = Confirmed
** Tags added: kernel-fixed-upstream kernel-fixed-upstream-3.17.0
--
Also I tried out the 3.16.2, 3.17-rc1, and 3.17-rc2 and got the hang on
all of them. Then I tried out 3.17-rc6 for a about a week before the
3.17.0 was released and didn't get the crash, but I can't say for sure
it's bug free as the hang doesn't come very time.
--
You received this bug
I have updated the BIOS, output from the terminal command is:
$ sudo dmidecode -s bios-version sudo dmidecode -s bios-release-date
A13
04/02/2011
I have also updated to the new 3.6.0-12 kernel. After that I tried to
reproduce the hang by doing suspend resume about 10 times in a row, but
it
Public bug reported:
I closed the lid to suspend the computer, which worked fine. When I
opened the lid the computer hanged during the resume. I got a black
screen with a pointer that I couldn't move. I resolved the problem by
poweing off the computer and then power it on again.
I've got the
I can only speak for myself but I don't have this problem anymore. I
think it was solved when I upgraded to Jaunty, I'm currently running on
the Karmic beta.
I still have the same setup with the root fs on LVM on a LUKS encrypted
md1.
I checked the commit log in the bazaar branch and found this:
I can confirm this bug. I have my root fs on LVM on a LUKS encrypted
md1. Same version of Ubuntu and Cryptsetup as razboinik.
The mounting usually succeeds after entering the password three or four
times. The first time it always fails because /sbin/cryptsetup isLuks
fails to detect that it's
I noticed that LUKS detection is outside the retry loop which puzzled me
a bit. Then I noticed that I have two entries in /conf/conf.d/cryptroot,
one for the root fs and one for swap and both are on the same LVM.
So I guess my previous comment wasn't entirely correct, it's always on
the fourth
10 matches
Mail list logo
