Public bug reported:
# apt update
...
Get:34 http://us.archive.ubuntu.com/ubuntu xenial-security/multiverse i386
Packages [1344 B]
Get:35 http://us.archive.ubuntu.com/ubuntu xenial-security/multiverse amd64
DEP-11 Metadata [200 B]
Fetched 2910 kB in 213503982334601d 7h 0min 0s (0 B/s)
Reading
Thanks---grub-pc does not exhibit this behaviour, so it should be good.
There may be other people upgrading from trusty (LTS)->xenial (LTS) who hit
this issue: is it worth deprecating grub1 on upgrading?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Public bug reported:
The xenial initramfs will not mount the root partition using the
UUID=XXX format when the root drive is mapped (e.g., through a LVM).
update-grub builds its menu.lst file with kernel command line parameters for
root= as, e.g.,
kernel /vmlinuz-4.4.0-16-generic
I could remove the 100% device hwC0D0 usage in PowerTop by playing with my
mixer switches (Mic feedthrough to Main, etc.). However, this did not change
my idle power usage by any significant amount.
20.2W +/- 1W
Lenovo ThinkPad T60
Ubuntu/Xfce 12.04
--
You received this bug notification
This has reared itself again in Karmic.
/etc/gdm/Xsession uses /bin/dash as its parser, but sets the $SHELL
environment variable to /bin/bash (!). This makes any ~/.profile that
uses bash-isms kill the gdm login process.
--
shopt xsession error upon login
https://bugs.launchpad.net/bugs/60079
** SOLVED **
On a hunch, I replaced /sbin/hdparm with a script that told me which
processes were running it.
Six (6) scripts where setting hdparm on resume!
Removing hdparm from the scripts appears to have fixed the problem of
the hanging hard disk on resume when on battery.
Daniel
--
ATA
Not a lot to show on screen unfortunately.
The drive verified correctly on reboot (dd if=/dev/sda of=/dev/null bs=1M - no
messages).
The fault seems to occur more often when resuming on battery power (3 of 3 so
far). This might point to a hardware issue, but Intrepid didn't have this
problem.
Public bug reported:
Kernel 2.6.28-11
Resume from suspend mostly works but...
On maybe 1 in 5 resumes, the disk controller fails all I/O. On pending
reads it will sometimes recover, but on this occasion the kernel paniced
(pending write failed?). The desktop prompted me to file a crash report
** Attachment added: BootDmesg.txt
http://launchpadlibrarian.net/24841176/BootDmesg.txt
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/24841177/Dependencies.txt
** Attachment added: HalComputerInfo.txt
http://launchpadlibrarian.net/24841178/HalComputerInfo.txt
**
I consider this a serious bug. (Scenario 1: another laptop user logs
out*, closes the lid, and you find yourself without any battery power
for the rest of the day. Scenario 2: log out, close the laptop lid,
pack in luggage and the laptop overheats.)
There is a work-around fortunately. Edit
10 matches
Mail list logo
