[Kernel-packages] [Bug 1953249] Re: UVD firmware for AMD Southern Islands (GCN 1) GPUs is missing

2021-12-05 Thread Jean-Pierre van Riel
Per coincidence, I worked on this same bug today, as I'm hoping to try
make use of the amdpro legacy OpenCL drivers, which will need amdgpu as
a base.

The issue is Ubuntu is providing newer kernel HWE stacks with amdgpu
driver modules, but failing to keep related Linux firmware packages up
to date and in lockstep. E.g. 20.04.3 LTS is based on kernel 5.11 from
hirsute (21.04), but the linux-firmware collection is left outdated on
1.187.20 that came with kernel 5.4?

https://packages.ubuntu.com/hirsute-updates/linux-firmware shows v
1.197.3, so I'd expect a HWE stack with 20.04.3 to also provide the same
level of firmware updates for kernel 5.11.

> I use UEFI and the module wasn't signed

Perhaps installing the official deb/repo instead of upstream has a good
shot at the firmware that gets added into initramfs being signed
properly (one would hope!). I manged the following workaround, but my
case is still legacy BIOS.

curl -OL 
http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.197.3_all.deb
sudo dpkg -i linux-firmware_1.197.3_all.deb

Extra hint: maybe download the deb from your closest mirror because this
package is almost 200MB large.

P.S. While most firmware is hopefully decoupled and backward compatible
to use with older kernel modules/drivers, one never knows if a bug might
show up by using very new firmware with much older modules, since you
stray into a untested path between the firmware and the kernel modules.
Hence I tried to match the Ubuntu release, kernel versions, and tested-
at-the-time firmware more closely than just jumping to latest upstream
firmware versions.

Its similar but a kinda upside version of the older proprietary graphics
driver blob hell that plagued Linux over the previous decade. Firmware
is the other way round where the in-tree admgpu driver needs the
firmware to provide a stable interface. Can't recall if Linux ever
solved the lack of a stable in-kernel/versioned ABI between drivers and
binary driver blobs. It's why AMD FGLRX proprietary drivers blobs were
always hell, and AMD failed to keep up with ABI changes on the kernel
and often didn't work with newer kernels, hence amdgpu became the new
middle layer/foundation to bridge this ABI gap and add create a
stable/presumably versioned ABI for AMD that the kernel developers never
bothered to provide. Now AMD-pro software and extended driver blobs can
rely on the opensource amdgpu parts to be less of a moving target as ABI
changes on the kernel core will need to update/include required changes
to amdgpu because amdgpu is now in-tree and should be tested in lockstep
with other kernel changes.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-firmware in Ubuntu.
https://bugs.launchpad.net/bugs/1953249

Title:
  UVD firmware for AMD Southern Islands (GCN 1) GPUs is missing

Status in linux-firmware package in Ubuntu:
  Confirmed

Bug description:
  Release: up-to-date Focal LTS (20.04.3)
  Package-version: linux-firmware 1.187.20
  Hardware model: [AMD/ATI] Chelsea LP [Radeon HD 7730M]

  With the latest kernel upgrade (5.4 --> 5.11, if I recall correctly),
  my laptop's discrete graphics stopped working. Looking at the logs, I
  found these messages:

  -- snippet --
  kernel: [1.492908] [drm] amdgpu: dpm initialized
  kernel: [1.492932] [drm] AMDGPU Display Connectors
  kernel: [1.492951] amdgpu :01:00.0: Direct firmware load for 
amdgpu/verde_uvd.bin failed with error -2
  kernel: [1.492954] amdgpu :01:00.0: amdgpu: amdgpu_uvd: Can't load 
firmware "amdgpu/verde_uvd.bin"
  kernel: [1.492957] [drm:amdgpu_device_ip_init [amdgpu]] *ERROR* sw_init 
of IP block  failed -2
  kernel: [1.493196] amdgpu :01:00.0: amdgpu: amdgpu_device_ip_init 
failed
  kernel: [1.493198] amdgpu :01:00.0: amdgpu: Fatal error during GPU 
init
  kernel: [1.493200] amdgpu :01:00.0: amdgpu: amdgpu: finishing device.
  -- snippet --

  In fact, file '/lib/firmware/amdgpu/verde_uvd.bin' was missing.
  Running '$ dpkg -L linux-firmware | sort' gives this:

  -- snippet --
  /lib/firmware/amdgpu/vegam_uvd.bin
  /lib/firmware/amdgpu/vegam_vce.bin
  /lib/firmware/amdgpu/verde_ce.bin
  /lib/firmware/amdgpu/verde_k_smc.bin
  /lib/firmware/amdgpu/verde_mc.bin
  /lib/firmware/amdgpu/verde_me.bin
  /lib/firmware/amdgpu/verde_pfp.bin
  /lib/firmware/amdgpu/verde_rlc.bin
  /lib/firmware/amdgpu/verde_smc.bin
  /lib/firmware/amdgpu/yellow_carp_asd.bin
  /lib/firmware/amdgpu/yellow_carp_ce.bin
  -- snippet --

  Copying the file from upstream
  (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
  firmware.git/tree/amdgpu/verde_uvd.bin) didn't work on my system,
  probably because I use UEFI and the module wasn't signed (error
  below):

  -- snippet --
  kernel: [  502.174932] amdgpu :01:00.0: amdgpu: amdgpu_uvd: Can't 
validate firmware "amdgpu/verde_uvd.bin"
  kernel: [  502.174992] [drm:amdgpu_device_ip_init 

[Kernel-packages] [Bug 1716857] Re: nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external monitors detected by Xorg

2020-05-03 Thread Jean-Pierre van Riel
Another correction. For the one workaround, switching to discrete
graphics in the BIOS only seemed to get past the initial gnome login.
But resuming from DPMS off/suspend, the same error loop happens even
when hybrid graphics is disabled in the BIOS.

Even worse, seems hardware acceleration ends up being disabled:

$ journalctl --no-hostname -b -p warning _COMM=gnome-shell
-- Logs begin at Wed 2019-02-06 14:13:52 SAST, end at Sun 2020-05-03 16:09:45 
SAST. --
May 03 14:51:40 org.gnome.Shell.desktop[2284]: glamor: 'wl_drm' not supported
May 03 14:51:40 org.gnome.Shell.desktop[2284]: Missing Wayland requirements for 
glamor GBM backend
May 03 14:51:40 org.gnome.Shell.desktop[2284]: Failed to initialize glamor, 
falling back to sw
...
May 03 14:53:25 gnome-shell[6549]: setup_framebuffers: assertion 'width > 0' 
failed

The "EGL failed to allocate resources" error stops happening probably
because gnome-shell isn't even using hardware acceleration now.

I've also disabled all gnome shell extensions to avoid noise/errors in
the logs and will try weed out the problem better.

I checked `grep -C2 -E '(EE)|(WW)' /var/log/Xorg.0.log` and things seem
fine:

[45.181] (II) NVIDIA dlloader X Driver  440.59  Thu Jan 30 01:08:17 UTC 2020
[45.181] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
--
[45.182] (II) LoadModule: "ramdac"
[45.182] (II) Module "ramdac" already built-in
[45.183] (WW) Falling back to old probe method for modesetting
[45.183] (II) NVIDIA(0): Creating default Display subsection in Screen 
section
"Default Screen Section" for depth/fbbpp 24/32
--
[46.392] (==) NVIDIA(0): Silken mouse enabled
[46.392] (==) NVIDIA(0): DPMS enabled
[46.393] (WW) NVIDIA(0): Option "PrimaryGPU" is not used
[46.393] (II) Loading sub module "dri2"
[46.393] (II) LoadModule: "dri2"

Note, I've done no customisation to X config - trying to stick to
defaults.

xrandr confirms only one provider / hybrid is indeed off and Intel not
in use:

$ xrandr --listproviders 
Providers: number : 1
Provider 0: id: 0x218 cap: 0x1, Source Output crtcs: 4 outputs: 6 associated 
providers: 0 name:NVIDIA-0

I'm guessing the Lenovo P53 impliments a mux/switch to connect the
laptop panel to the NVidia card so that Intel is disabled in this mode.

And double checking, also no i915 modules are loaded:

$ lsmod | grep '^drm'
drm_kms_helper180224  1 nvidia_drm
drm   491520  10 drm_kms_helper,nvidia_drm

So there seems to be, on current Ubuntu 18.04.4 LTS (fully up to date as
of today), a 4K / UHD 60Hz issue with Nvidia, as seen in X log

[45.228] (II) NVIDIA GLX Module  440.59  Thu Jan 30 01:05:38 UTC
2020

Lastly, I think due to `needs_root_rights=yes` in
/etc/X11/Xwrapper.config, X logs to /var/log/Xorg.0.log again instead of
the X without root which used to log at  ~/.local/share/xorg/Xorg.0.log

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-418 in Ubuntu.
https://bugs.launchpad.net/bugs/1716857

Title:
  nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external
  monitors detected by Xorg

Status in gdm3 package in Ubuntu:
  Opinion
Status in nvidia-graphics-drivers-375 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-418 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Context:
  17.10 development packages, nvidia binary driver 375, modeset=1 for the 
nvidia driver.
  ubuntu desktop (gnome shell), fresh install
  ThinkPad W520 in Nvidia Optimus bios mode.
  Nvidia profile.

  Result:
  no external monitors are detected.
  xrandr does not even list them as disconnected (normally it would list five 
external disconnected monitors)

  
  lsmod 
  shows that nvidia driver is loaded
  and the modesetting is working at some level because there is no tearing on 
the laptop panel

  
  Note: modeset=1 is the only way to get flicker-free graphics on the laptop 
panel. modeset=1 is not the default setting but it is highly desirable. 

  It works if lightdm is used which is why I have reported this against gdm3
  My sessions in this configuration have mostly crashed after a few minutes 
with a gdm3 fail whale message in syslog but nothing else looks interesting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1716857] Re: nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external monitors detected by Xorg

2020-05-03 Thread Jean-Pierre van Riel
Here's the script I run to workaround the intital failure of gnome to
use the external display after unlocking or resuming from DPMS
suspend/off.

** Attachment added: "fix-hdmi-uhd.sh"
   
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+attachment/5365719/+files/fix-hdmi-uhd.sh

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-418 in Ubuntu.
https://bugs.launchpad.net/bugs/1716857

Title:
  nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external
  monitors detected by Xorg

Status in gdm3 package in Ubuntu:
  Opinion
Status in nvidia-graphics-drivers-375 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-418 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Context:
  17.10 development packages, nvidia binary driver 375, modeset=1 for the 
nvidia driver.
  ubuntu desktop (gnome shell), fresh install
  ThinkPad W520 in Nvidia Optimus bios mode.
  Nvidia profile.

  Result:
  no external monitors are detected.
  xrandr does not even list them as disconnected (normally it would list five 
external disconnected monitors)

  
  lsmod 
  shows that nvidia driver is loaded
  and the modesetting is working at some level because there is no tearing on 
the laptop panel

  
  Note: modeset=1 is the only way to get flicker-free graphics on the laptop 
panel. modeset=1 is not the default setting but it is highly desirable. 

  It works if lightdm is used which is why I have reported this against gdm3
  My sessions in this configuration have mostly crashed after a few minutes 
with a gdm3 fail whale message in syslog but nothing else looks interesting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1716857] Re: nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external monitors detected by Xorg

2020-05-03 Thread Jean-Pierre van Riel
Apologies, continuing the comment above (mistakenly posted when adding
the log attachment). Let me retry.

Failure loop observed:

- Failed to blit shared framebuffer: EGL failed to allocate resources for the 
requested operation.
- Failed to set CRTC mode 3840x2160: No such file or directory

To summarise and share my experience of it on a Lenovo P53 and some
quirks/workarounds:

- `sudo ubuntu-drivers autoinstall` got Nvidia 440.59 drivers installed.
- However, Nvidia modeset was not enabled as yet.

$ sudo cat /sys/module/nvidia_drm/parameters/modeset
N

- Blank external screen occurs with modeset=0 (disabled)
- Then, using `prime-select nvidia`, I tried to ensure nvidia was primary
- `prime-select nvidia` sets `options nvidia-drm modeset=1` but it's not 
effective, even after I rebooted

~$ cat /lib/modprobe.d/nvidia-kms.conf
# This file was generated by nvidia-prime
# Set value to 0 to disable modesetting
options nvidia-drm modeset=1

- To make it effective, because modeset is done during initramfs part of boot, 
I ran `sudo update-initramfs -u -k all`. 
- It seems the prime-select option fails to trigger a intiramfs update 
(probably should be filed as a separate bug)
- Regardless, the blank screen issue occured on my Lenovo P53 with or without 
Nvidia KMS modeset enabled
- But one benefit of KMS modeset for Nvida is now the external display gets 
properly recognised.  /sys/class/drm/card1-HDMI-A-1/ now exists (was missing 
with Ubuntu 18.04.4 LTS default proprietary install) including the EDID data 
being read properly and X getting the actual DPI of the screen correctly.

Without nvidia modeset, as seen in `journalctl -b _COMM=gdm-x-session |
grep -C2 -E '(EE)|(WW)'`:

(WW) NVIDIA(0): Unable to get display device for DPI computation.

With nvidia modeset:

(II) NVIDIA(0): Validated MetaModes:
(II) NVIDIA(0): "DFP-3:nvidia-auto-select"
(II) NVIDIA(0): Virtual screen size determined to be 3840 x 2160
(--) NVIDIA(0): DPI set to (139, 140); computed from "UseEdidDpi" X config

I've also found two workarounds to my issue.

1. Run a script that sets the frequency to 30HZ and then back to 60HZ
2. Switch to discrete only graphics in the BIOS

In most cases, when one is using a 2nd display, there's usually a
powersource available so the complexity of hybrid graphics isn't worth
it and I went with simply disabling hybrid graphics in the BIOS.

It's quite interesting that toggling the display refresh rate down to
30HZ and then back up to 60HZ seems to work around the problem of gnome-
shell mutter's "EGL failed to allocate resources for the requested
operation" bug.

To conclude, even with the root access workaround in place:

$ tail -n 2 /etc/X11/Xwrapper.config
# Added by xserver-xorg-video-nvidia-440
needs_root_rights=yes

I still had external display connection issues with 4K 60Hz.

This might need to be logged as different bug? I'm unsure it's GDM3s
fault given the root workaround was in place, but it's highly
related/similar.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-418 in Ubuntu.
https://bugs.launchpad.net/bugs/1716857

Title:
  nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external
  monitors detected by Xorg

Status in gdm3 package in Ubuntu:
  Opinion
Status in nvidia-graphics-drivers-375 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-418 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Context:
  17.10 development packages, nvidia binary driver 375, modeset=1 for the 
nvidia driver.
  ubuntu desktop (gnome shell), fresh install
  ThinkPad W520 in Nvidia Optimus bios mode.
  Nvidia profile.

  Result:
  no external monitors are detected.
  xrandr does not even list them as disconnected (normally it would list five 
external disconnected monitors)

  
  lsmod 
  shows that nvidia driver is loaded
  and the modesetting is working at some level because there is no tearing on 
the laptop panel

  
  Note: modeset=1 is the only way to get flicker-free graphics on the laptop 
panel. modeset=1 is not the default setting but it is highly desirable. 

  It works if lightdm is used which is why I have reported this against gdm3
  My sessions in this configuration have mostly crashed after a few minutes 
with a gdm3 fail whale message in syslog but nothing else looks interesting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1716857] Re: nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external monitors detected by Xorg

2020-05-03 Thread Jean-Pierre van Riel
Hi, thanks to everyone, especially Daniel for unpacking this issue.

I have had a very similar issue, where gnome shell fails to run my
external 4K/UHD display at 60HZ and I see the following failure loop
triggered in  `journalctl -b -p warning _COMM=gnome-shell`:

May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to blit shared 
framebuffer: EGL failed to allocate resources for the requested operation.
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 
3840x2160: No such file or directory
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to flip: Device or 
resource busy
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 
3840x2160: No such file or directory
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to blit shared 
framebuffer: EGL failed to allocate resources for the requested operation.
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 
3840x2160: No such file or directory
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to blit shared 
framebuffer: EGL failed to allocate resources for the requested operation.
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 
3840x2160: No such file or directory
...


 While not sure it's exactly the same, it should still inform the
overall discussion about dealing with GDM3 + Mutter + proprietary Nvidia
drivers modeset problems.

To summarise and share my experience of it on a Lenovo P53 and some
quirks/workarounds:

- `sudo ubuntu-drivers autoinstall` got Nvidia 440.59 drivers installed.
- However, Nvidia modeset was not enabled as yet. 

$ sudo cat /sys/module/nvidia_drm/parameters/modeset
N

-

- Using prime-select

- For laptops like mine, seems the external port is connected to the Nvidia GPU.
- Using the proprietary Nvidia drivers seems to then bump into a 


** Attachment added: "gnome-shell_journal_warnings_egl_resource_failed.txt"
   
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+attachment/5365716/+files/gnome-shell_journal_warnings_egl_resource_failed.txt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-418 in Ubuntu.
https://bugs.launchpad.net/bugs/1716857

Title:
  nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external
  monitors detected by Xorg

Status in gdm3 package in Ubuntu:
  Opinion
Status in nvidia-graphics-drivers-375 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-418 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Context:
  17.10 development packages, nvidia binary driver 375, modeset=1 for the 
nvidia driver.
  ubuntu desktop (gnome shell), fresh install
  ThinkPad W520 in Nvidia Optimus bios mode.
  Nvidia profile.

  Result:
  no external monitors are detected.
  xrandr does not even list them as disconnected (normally it would list five 
external disconnected monitors)

  
  lsmod 
  shows that nvidia driver is loaded
  and the modesetting is working at some level because there is no tearing on 
the laptop panel

  
  Note: modeset=1 is the only way to get flicker-free graphics on the laptop 
panel. modeset=1 is not the default setting but it is highly desirable. 

  It works if lightdm is used which is why I have reported this against gdm3
  My sessions in this configuration have mostly crashed after a few minutes 
with a gdm3 fail whale message in syslog but nothing else looks interesting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1669620] Re: Reboot when resume from suspend

2017-06-03 Thread Jean-Pierre van Riel
Apologises, I think I'm conflating a resume from hibernate issue vs a
resume from suspend issue, so the previous comment is probably not that
relevant.

-- 
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/1669620

Title:
  Reboot when resume from suspend

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  When I resume my computer from suspend2ram, after about 2 seconds it
  shutdowns and after about 3 seconds swithces on, and system starts to
  boot from GRUB as it was poweroff.

  But if I resume my computer right away after it was suspended, it
  resumes properly. I occur this problem if some amount of time passed
  between suspend and resume.

  And I didn't reproduce this problem when lightdm was stopped (but the
  screen is black after resume, but I can login via SSH). But with
  launched X Server the problem occurs both with nouveau and Nvidia
  proprietary driver.

  There is not this problem on Ubuntu 14.04 (it is installed on this
  computer too but without madm and root partition encryption).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-generic 4.4.0.64.68
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tim2077 F pulseaudio
  CurrentDesktop: XFCE
  Date: Fri Mar  3 02:43:35 2017
  EcryptfsInUse: Yes
  IwConfig:
   tun0  no wireless extensions.

   lono wireless extensions.

   enp4s0no wireless extensions.
  MachineType: Gigabyte Technology Co., Ltd. EP43-DS3L
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic 
root=UUID=77b30501-4b3e-4223-8e1c-ee51e9f214d7 ro
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-64-generic N/A
   linux-backports-modules-4.4.0-64-generic  N/A
   linux-firmware1.157.8
  RfKill:

  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/08/2008
  dmi.bios.vendor: Award Software International, Inc.
  dmi.bios.version: F5
  dmi.board.name: EP43-DS3L
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.chassis.type: 3
  dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
  dmi.modalias: 
dmi:bvnAwardSoftwareInternational,Inc.:bvrF5:bd07/08/2008:svnGigabyteTechnologyCo.,Ltd.:pnEP43-DS3L:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnEP43-DS3L:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
  dmi.product.name: EP43-DS3L
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1669620/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1669620] Re: Reboot when resume from suspend

2017-06-03 Thread Jean-Pierre van Riel
No sure if this will help, but there are plenty of debian bugs related
to this to check

If you are relying on the `resume=` kernel parameter with
/etc/default/grub, that might well be ignored. According to the message
below, there are various bugs in upstream debian (and I'm not sure if
Ubuntu patches/changes this):

https://lists.debian.org/debian-kernel/2017/04/msg00348.html

After installed, I noted `/etc/initramfs-tools/conf.d/resume` uses a
UUID, but I had issues getting resume to work, possibly because I
recreated my swap partition. As far as I could tell, Ubuntu 16.04.2 LTS
seems to ignore the `resume=` kernel parameter as a UUID or LABEL.

`apt-cache show initramfs-tools` shows Ubuntu 16.04.2 LTS currently has
`Version: 0.122ubuntu8.8`, so it should be free of the bug/regression
that caused UUID or LABEL to be ignored in `conf.d/resume`

-- 
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/1669620

Title:
  Reboot when resume from suspend

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  When I resume my computer from suspend2ram, after about 2 seconds it
  shutdowns and after about 3 seconds swithces on, and system starts to
  boot from GRUB as it was poweroff.

  But if I resume my computer right away after it was suspended, it
  resumes properly. I occur this problem if some amount of time passed
  between suspend and resume.

  And I didn't reproduce this problem when lightdm was stopped (but the
  screen is black after resume, but I can login via SSH). But with
  launched X Server the problem occurs both with nouveau and Nvidia
  proprietary driver.

  There is not this problem on Ubuntu 14.04 (it is installed on this
  computer too but without madm and root partition encryption).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-generic 4.4.0.64.68
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tim2077 F pulseaudio
  CurrentDesktop: XFCE
  Date: Fri Mar  3 02:43:35 2017
  EcryptfsInUse: Yes
  IwConfig:
   tun0  no wireless extensions.

   lono wireless extensions.

   enp4s0no wireless extensions.
  MachineType: Gigabyte Technology Co., Ltd. EP43-DS3L
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic 
root=UUID=77b30501-4b3e-4223-8e1c-ee51e9f214d7 ro
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-64-generic N/A
   linux-backports-modules-4.4.0-64-generic  N/A
   linux-firmware1.157.8
  RfKill:

  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/08/2008
  dmi.bios.vendor: Award Software International, Inc.
  dmi.bios.version: F5
  dmi.board.name: EP43-DS3L
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.chassis.type: 3
  dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
  dmi.modalias: 
dmi:bvnAwardSoftwareInternational,Inc.:bvrF5:bd07/08/2008:svnGigabyteTechnologyCo.,Ltd.:pnEP43-DS3L:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnEP43-DS3L:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
  dmi.product.name: EP43-DS3L
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1669620/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1629512] Re: HDD failed command: SET FEATURES error

2017-03-23 Thread Jean-Pierre van Riel
I too see this error for Seagate 'ST3500418AS' SATA drives via 88SE9123
PCIe SATA 6.0 Gb/s controller (Ubuntu 16.04.2, latest 4.8 Kernel)


```
exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0
irq_stat 0x4001
failed command: SET FEATURES
cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 4
status: { DRDY ERR }
error: { ABRT }
```

Note:

- `Emask 0x1` = "device reported error"
- `status: { DRDY ERR }` = device ready, but with error

If it relates to other posts on the internet, it might be benign and
simply failed power management setting attempts, or the like via the
Marvel controller.

To note, I have other SSD drives in the system that are connected via a
different controller (SB850) and also don't support APM, but they don't
exhibit this error!


`cmd ef/05:fe:00:00:00/00:00:00:00:00/40` requires understanding ATA commands 
to know what the above command is attempting. As per the "Enable/disable 
advanced power management" section of the ATA.8 standard:

- "Subcommand code `05h` allows the host to enable Advanced Power Management."
- `FEh` = Maximum performance

So this confirms:

- ATA command = ef = SET FEATURE
- ATA Feature = 05 = Advanced Power Management4
- ATA NSect = fe = 254 = Maximum performance
- remainder of string ":00:00:00/00:00:00:00:00/40" is addressing 

SOMETHING during boot is trying to set APM on drives that don't support
it!!!

I checked udev rules - this doesn't seem to be udev...

```
$ grep -r hdparm /lib/udev/*
/lib/udev/hdparm:. /lib/hdparm/hdparm-functions
/lib/udev/hdparm:   if grep -wq nohdparm /proc/cmdline ; then
/lib/udev/hdparm:OPTIONS=$(hdparm_options $DEVNAME)
/lib/udev/hdparm:   /sbin/hdparm $OPTIONS $DEVNAME 2>/dev/null
/lib/udev/rules.d/85-hdparm.rules:ACTION=="add", SUBSYSTEM=="block", 
KERNEL=="[sh]d[a-z]", RUN+="/lib/udev/hdparm"
```

Tracing the udev -> hdparm scritping, I found that in 
`/lib/hdparm/hdparm-functions`, there is `hdparm_options()` and 
`hdparm_try_apm()`, which might default to `hdparm_set_option -B254`
```

and

```
hdparm_try_apm()
{
# set our default global apm policy here.
if [ -z "$ID_PATH" ]; then
local ID_PATH="$(udevadm info -n "$1" -q property 2>/dev/null | sed -n 
's/^ID_PATH=//p')" || true
fi
case $ID_PATH in
pci-*-ieee1394-*|pci-*-usb-*)
return 1
;;
esac
return 0
}
```

But in my case, when I query udev properties for the device, I see this

```
$ udevadm info -n /dev/sdg
...
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=1
...
```

But I do not see `ID_ATA_FEATURE_SET_APM=1` so udev is, or it shouldn't
be setting APM on my drive that doesn't support it...

So if it's not the normal system udev rules, I wondered if it might be
something about the init on initramfs trying to enable this, given that
does try to load block device drivers and probably runs udev rules in
preparation for mounting root. I uncompressed initramfs, but failed to
identify anything that sets the APM on drives that don't support it.

So it's still a mystery why APM is attempted when, clearly, it's obvious
the drives don't support it, and also, why only the HDD drives on the
marvel controller vs other SSDs (not on Marvel) that don't have APM?

Also, if I force `sudo hdparm -B 254 /dev/sdg` and tail
/var/log/kern.log, I can't trigger that same error seen during boot.

-- 
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/1629512

Title:
  HDD failed command: SET FEATURES error

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  When my computer boots, i get a screen with following errors

  [9.470860] ata6.00: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0
  [9.470880] ata6.00: irq_stat 0x4001
  [9.470893] ata6.00: failed command: SET FEATURES
  [9.470908] ata6.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 29
  [9.470908]  res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 
(device error)
  [9.470942] ata6.00: status: { DRDY ERR }
  [9.470954] ata6.00: error: { ABRT }
  [9.506904] ata5.00: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0
  [9.506944] ata5.00: irq_stat 0x4001
  [9.506974] ata5.00: failed command: SET FEATURES
  [9.507008] ata5.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 26
  [9.507008]  res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 
(device error)
  [9.507083] ata5.00: status: { DRDY ERR }
  [9.507110] ata5.00: error: { ABRT }

  I stays there for like a minute before continue booting.

  It started after i upgrade to Ubuntu 16.04, i had no such errors with
  both HDD on Ubuntu 14.04

  The HDDs are western digital WDC WD20EZRX-00D. Both purchased same time.
  --- 
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  boby   2509 F pulseaudio
   /dev/snd/pcmC0D0p:   boby 

[Kernel-packages] [Bug 1512848] Re: Radeon VCE Init Error

2017-01-08 Thread Jean-Pierre van Riel
It's still happening to me on 16.04 (Xenial), fully up to date.

@madbiologist, thanks, good to know where the cause might be.

Still, having to rebuild a kernel with one commit reverted is a fairly
cumbersome work-around and painful given fairly frequent kernel
updates...

As far as I can see, no fixes have been worked on? 0 commits to
vce_v1_0.c (my graphics card is only VCE 1 capable) `CHIP_PITCAIRN`

https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/radeon/vce_v1_0.c

https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/radeon/radeon_vce.c

However, there might be a way to disable VCE (I need to look into it
more)

https://github.com/torvalds/linux/commit/fabb5935871db1f31fcd2684fd154e24de04d917
#diff-9bc1b4aaf15dd521a1991717e4e2a2e0

-- 
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/1512848

Title:
  Radeon VCE Init Error

Status in Linux:
  Unknown
Status in linux package in Ubuntu:
  Incomplete
Status in linux package in Debian:
  New
Status in linux package in Fedora:
  Unknown

Bug description:
  Since upgrading to Ubuntu 15.10, I have encountered graphics
  performance issues, and have occasionally experienced lockups during
  boot.

   dmesg | grep -E 'drm|radeon'
  [2.164605] [drm] Initialized drm 1.1.0 20060810
  [2.192852] [drm] radeon kernel modesetting enabled.
  [2.201268] [drm] Memory usable by graphics device = 2048M
  [2.201274] fb: switching to inteldrmfb from EFI VGA
  [2.201394] [drm] Replacing VGA console driver
  [2.204234] radeon :01:00.0: enabling device ( -> 0003)
  [2.207919] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
  [2.207921] [drm] Driver supports precise vblank timestamp query.
  [2.242929] fbcon: inteldrmfb (fb0) is primary device
  [3.529125] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
has_drrs (expected 1, found 0)
  [3.529141] WARNING: CPU: 1 PID: 195 at 
/home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:12700 
intel_modeset_check_state+0x5aa/0x870 [i915]()
  [3.529150] Modules linked in: hid_logitech_hidpp hid_logitech_dj usbhid 
hid rtsx_usb_sdmmc rtsx_usb amdkfd amd_iommu_v2 i915(+) radeon(+) i2c_algo_bit 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops psmouse r8169 
ahci drm libahci mii fjes wmi video
  [3.529201]  [] drm_atomic_commit+0x37/0x60 [drm]
  [3.529206]  [] drm_atomic_helper_set_config+0x1bf/0x420 
[drm_kms_helper]
  [3.529212]  [] drm_mode_set_config_internal+0x62/0x100 
[drm]
  [3.529215]  [] restore_fbdev_mode+0xb3/0x110 
[drm_kms_helper]
  [3.529219]  [] 
drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
  [3.529221]  [] drm_fb_helper_set_par+0x2d/0x50 
[drm_kms_helper]
  [3.529253]  [] drm_fb_helper_initial_config+0x250/0x3e0 
[drm_kms_helper]
  [3.535608] i915 :00:02.0: fb0: inteldrmfb frame buffer device
  [3.546293] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
minor 0
  [3.546469] [drm] initializing kernel modesetting (OLAND 0x1002:0x6600 
0x144D:0xC0E6).
  [3.546483] [drm] register mmio base: 0xF7E0
  [3.546484] [drm] register mmio size: 262144
  [3.574408] [drm] GPU not posted. posting now...
  [3.587216] radeon :01:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)
  [3.587218] radeon :01:00.0: GTT: 2048M 0x4000 - 
0xBFFF
  [3.587220] [drm] Detected VRAM RAM=1024M, BAR=256M
  [3.587220] [drm] RAM width 128bits DDR
  [3.587314] [drm] radeon: 1024M of VRAM memory ready
  [3.587315] [drm] radeon: 2048M of GTT memory ready.
  [3.587322] [drm] Loading oland Microcode
  [3.587398] [drm] Internal thermal controller without fan control
  [3.587450] [drm] probing gen 2 caps for device 8086:151 = 261ad03/e
  [3.593155] [drm] radeon: dpm initialized
  [3.594806] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
  [3.594811] [drm] GART: num cpu pages 524288, num gpu pages 524288
  [3.595617] [drm] probing gen 2 caps for device 8086:151 = 261ad03/e
  [3.595620] [drm] enabling PCIE gen 3 link speeds, disable with 
radeon.pcie_gen2=0
  [4.815819] [drm] PCIE GART of 2048M enabled (table at 0x002E8000).
  [4.815912] radeon :01:00.0: WB enabled
  [4.815914] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0x880416408c00
  [4.815916] radeon :01:00.0: fence driver on ring 1 use gpu addr 
0x4c04 and cpu addr 0x880416408c04
  [4.815917] radeon :01:00.0: fence driver on ring 2 use gpu addr 
0x4c08 and cpu addr 0x880416408c08
  [4.815918] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0x880416408c0c
  [4.815919] radeon :01:00.0: fence driver on 

[Kernel-packages] [Bug 1598394] Re: intel_pstate has too aggressive frequency selection

2017-01-04 Thread Jean-Pierre van Riel
Notable upstream bugs with related issues

alegidly patched: https://bugzilla.kernel.org/show_bug.cgi?id=115771
maybe not patched yet: https://bugzilla.kernel.org/show_bug.cgi?id=93521

Workaround (to help other who find this bug)

Add `intel_pstate=disable` to `GRUB_CMDLINE_LINUX_DEFAULT` in
/etc/default/grub and update-grub. This will revert to the acpi-cpufreq
driver and ondemand (default) policy.

check with `cpupower frequency-info`

I've observed more sane scaling of CPU frequencies, and better fan speed
and temperature on Haswell. E.g. acpi-cpufreq vs pstate (while
relatively idle)

* temp: ~52 vs 70 degrees
* fan: ~3800 rpm  vs 4600 rpm

pstate will very often turbo boost many cores and seldom drop below
standard max frequency even when lightly loaded per core. When loaded,
temp would bounce up to 89 degrees quickly. I suspect the CPU kept
needing to throttle back often.


** Bug watch added: Linux Kernel Bug Tracker #115771
   http://bugzilla.kernel.org/show_bug.cgi?id=115771

** Bug watch added: Linux Kernel Bug Tracker #93521
   http://bugzilla.kernel.org/show_bug.cgi?id=93521

-- 
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/1598394

Title:
  intel_pstate has too aggressive frequency selection

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I was recently upgrading from Ubuntu Gnome 15.10 to 16.04 on my
  ThinkPad. Before the frequency-scaling chose the minimum possible
  frequency when the system was on low load. Now, when I allow the CPU
  to choose anything between the lowest and highest possible frequency,
  it sticks to the highest frequency for 90% of time and only
  occasionally drops to the low frequency.

  I can confirm (htop) that my system load is practically zero. Also the
  CPU Power Manager Applet from Gnome Shell works well, because I can
  force low frequency by reducing the maximum allowed frequency and can
  also switch off Turbo Boost.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-generic 4.4.0.28.30
  ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13
  Uname: Linux 4.4.0-28-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  timeshifter   1768 F pulseaudio
   /dev/snd/controlC1:  timeshifter   1768 F pulseaudio
  CurrentDesktop: GNOME
  Date: Sat Jul  2 12:11:42 2016
  EcryptfsInUse: Yes
  HibernationDevice: RESUME=UUID=87cca434-274f-4464-9598-97fd7a1338fe
  InstallationDate: Installed on 2016-03-19 (104 days ago)
  InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Release amd64 
(20151021)
  MachineType: LENOVO 20C0003SFR
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/usr/bin/zsh
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-28-generic 
root=UUID=e52c99ea-9646-4e8a-b8ad-c47b175ac5a3 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-28-generic N/A
   linux-backports-modules-4.4.0-28-generic  N/A
   linux-firmware1.157.1
  SourcePackage: linux
  UpgradeStatus: Upgraded to xenial on 2016-07-02 (0 days ago)
  dmi.bios.date: 11/07/2014
  dmi.bios.vendor: LENOVO
  dmi.bios.version: B0ET24WW (1.11 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20C0003SFR
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0E50510 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrB0ET24WW(1.11):bd11/07/2014:svnLENOVO:pn20C0003SFR:pvrThinkPadS1Yoga:rvnLENOVO:rn20C0003SFR:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 20C0003SFR
  dmi.product.version: ThinkPad S1 Yoga
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1598394/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1540406] Re: warning: file-aligned section .text extends beyond end of file

2016-12-01 Thread Jean-Pierre van Riel
Same, here, this message makes me fear that my system won't be able to
boot with the new kernel.

Setting up linux-signed-image-4.4.0-51-generic (4.4.0-51.72) ...
warning: file-aligned section .text extends beyond end of file
warning: checksum areas are greater than image size. Invalid section table?

This seems related? https://bugs.launchpad.net/launchpad/+bug/1071562

This suggests it isn't as serious as it sounds? http://www.rodsbooks.com
/efi-bootloaders/secureboot.html. However, no actual explanation.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1540406

Title:
  warning: file-aligned section .text extends beyond end of file

Status in linux-signed package in Ubuntu:
  Confirmed

Bug description:
  When running a dist-upgrade, I received the following warning:

  Setting up linux-signed-image-4.4.0-2-generic (4.4.0-2.16) ...
  warning: file-aligned section .text extends beyond end of file
  warning: checksum areas are greater than image size. Invalid section table?

  Note: I've tried booting the kernel with dmesg enabled, it seems to
  boot just fine. See
  https://launchpadlibrarian.net/235948033/CurrentDmesg.txt for when I
  booted it.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-signed-image-4.4.0-2-generic 4.4.0-2.16
  ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3
  Uname: Linux 4.3.0-7-generic x86_64
  ApportVersion: 2.19.4-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Feb  1 15:58:45 2016
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-11-28 (65 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151127)
  SourcePackage: linux-signed
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1540406/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1389305] Re: sudo doesn't work on unprivileged lxc container on top of ecryptfs

2016-09-13 Thread Jean-Pierre van Riel
Update on the previous comment, I realised the issue was the the
partition where /var was mounted to hat nosuid set. Seems /var/lib/lxc
must allow for the suid bit to be set. The problem is that people often
have /home mounted with nosuid as a normal security precaution, so this
effects running unprivileged containers as well.

-- 
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/1389305

Title:
  sudo doesn't work on unprivileged lxc container on top of ecryptfs

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Triaged

Bug description:
  On Ubuntu 14.04 64 bit, after adding a user into an unprivileged
  container, the sudo complains that:

  $ sudo su
  sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 
'nosuid' option set or an NFS file system without root privileges?

  To reproduce:

  1. Download and install the Ubuntu amd64 minimalcd
  2. Install lxc on it and openssh for convenience.
  3. follow 
https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ ; 
specifically do:
   a) sudo usermod --add-subuids 10-165536 $USER
   b) sudo usermod --add-subgids 10-165536 $USER
   c) sudo chmod +x $HOME
   d) create the file  ~/.config/lxc/default.conf with the following 
contents:
  lxc.include = /etc/lxc/default.conf
  lxc.id_map = u 0 10 65536
  lxc.id_map = g 0 10 65536
   e) echo "$USER veth lxcbr0 10" | sudo tee /etc/lxc/lxc-usernet
  (restart is not required)
  4. Create the container with
  lxc-create -t download -n p1 -- -d ubuntu -r trusty -a amd64
  5. Install openssh-server in the container:
  lxc-start -d -n p1
  lxc-attach -n p1 -- apt-get install openssh-server
  6. Add a user "adam" with the group sudo
  lxc-attach -n p1 -- adduser adam sudo
  7. Set a password for the user
  8. Log in via ssh (and provide the password from step 7)
  ssh p1@adam
  9. On the p1:
  adam@p1$ sudo su
  sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 
'nosuid' option set or an NFS file system without root privileges?

  I expected it to make change the user to root.

  lxc version: 1.0.3-0ubuntu3
  $cat ~/.cache/lxc/download/ubuntu/trusty/amd64/default/build_id
  20141101_03:49
  --- 
  ApportVersion: 2.14.1-0ubuntu3.5
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  EcryptfsInUse: Yes
  Package: lxc
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
  Tags:  trusty
  Uname: Linux 3.13.0-39-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1389305/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1389305] Re: sudo doesn't work on unprivileged lxc container on top of ecryptfs

2016-08-18 Thread Jean-Pierre van Riel
It also affected me on Ubuntu 16.04 LTS with /var/lib/lxc mount via
bind.

My original setup only had 8GB for /var, so a bind to directory in /home
was the custom hack I did to give lxc more space.

$ grep lxc /etc/fstab
/home/var/lib/lxc  /var/lib/lxc  nonebind   
 0   0

Once tested without the bind, the error was gone.

-- 
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/1389305

Title:
  sudo doesn't work on unprivileged lxc container on top of ecryptfs

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Triaged

Bug description:
  On Ubuntu 14.04 64 bit, after adding a user into an unprivileged
  container, the sudo complains that:

  $ sudo su
  sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 
'nosuid' option set or an NFS file system without root privileges?

  To reproduce:

  1. Download and install the Ubuntu amd64 minimalcd
  2. Install lxc on it and openssh for convenience.
  3. follow 
https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ ; 
specifically do:
   a) sudo usermod --add-subuids 10-165536 $USER
   b) sudo usermod --add-subgids 10-165536 $USER
   c) sudo chmod +x $HOME
   d) create the file  ~/.config/lxc/default.conf with the following 
contents:
  lxc.include = /etc/lxc/default.conf
  lxc.id_map = u 0 10 65536
  lxc.id_map = g 0 10 65536
   e) echo "$USER veth lxcbr0 10" | sudo tee /etc/lxc/lxc-usernet
  (restart is not required)
  4. Create the container with
  lxc-create -t download -n p1 -- -d ubuntu -r trusty -a amd64
  5. Install openssh-server in the container:
  lxc-start -d -n p1
  lxc-attach -n p1 -- apt-get install openssh-server
  6. Add a user "adam" with the group sudo
  lxc-attach -n p1 -- adduser adam sudo
  7. Set a password for the user
  8. Log in via ssh (and provide the password from step 7)
  ssh p1@adam
  9. On the p1:
  adam@p1$ sudo su
  sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 
'nosuid' option set or an NFS file system without root privileges?

  I expected it to make change the user to root.

  lxc version: 1.0.3-0ubuntu3
  $cat ~/.cache/lxc/download/ubuntu/trusty/amd64/default/build_id
  20141101_03:49
  --- 
  ApportVersion: 2.14.1-0ubuntu3.5
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  EcryptfsInUse: Yes
  Package: lxc
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
  Tags:  trusty
  Uname: Linux 3.13.0-39-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1389305/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1471380] Re: [Fujitsu Lifebook AH532] Installing Ubuntu on a USB-drive locks out firmware access

2015-10-25 Thread Jean-Pierre van Riel
*** This bug is a duplicate of bug 1273060 ***
https://bugs.launchpad.net/bugs/1273060

** This bug has been marked a duplicate of bug 1273060
   [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

-- 
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/1471380

Title:
  [Fujitsu Lifebook AH532] Installing Ubuntu on a USB-drive locks out
  firmware access

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I've been running pre-installed Windows 7 on a Fujitsu AH532 since
  2012.

  Two weeks back, I installed a Live-USB with Ubuntu 14.04. All working
  well, but I struggled getting it persistent, so I decided to do a full
  Ubuntu installation to another USB-drive. Leaving my Windows hard
  drive untouched.

  
  What I did:
  1) I entered my "BIOS" to change boot order, and booting from my Ubuntu 
Live-USB.

  2) I tried following the  installation guide 
https://help.ubuntu.com/community/Installation/UEFI-and-BIOS, but sizes were 
changed to: 
   - 1MB BIOS Boot (pretty sure I left this unformatted,but it now reports as 
Ext4)
   - 666MB EFI System, FAT32
   - 30GB Linux Filesystem, Ext4
   - 999MB Linux Swap, Swap

  3) I installed Ubuntu on a second USB-drive. Leaving my Windows hard-
  drive "intact" (?)

  
  The result:
  Now, I can only boot my machine by inserting my second 
full-installation-USB-drive. 
  I cannot boot Windows, and I cannot boot from my LiveUSB.

  If I boot without inserting my full-installation-USB-drive, I get the
  boot screen telling me I can press F2 or F12. However, none of these
  have any effect, apart from making the beep. Then the computer enters
  the "Boot menu" (as well as the second menu "Application menu").

  
  This bug feels very related to:
  - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418
  - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060
  - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1451387

  
  $ lsb_release -rd
  Description:  Ubuntu 14.04.2 LTS
  Release:  14.04

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.16.0-41-generic 3.16.0-41.55~14.04.1
  ProcVersionSignature: Ubuntu 3.16.0-41.55~14.04.1-generic 3.16.7-ckt11
  Uname: Linux 3.16.0-41-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.7
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat Jul  4 08:05:03 2015
  InstallationDate: Installed on 2015-06-18 (15 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  SourcePackage: linux-lts-utopic
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.14.1-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   vegard 2045 F...m pulseaudio
   /dev/snd/controlC0:  vegard 2045 F pulseaudio
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=b7bfbfab-671b-471c-ba59-210445db2063
  InstallationDate: Installed on 2015-06-18 (16 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  MachineType: FUJITSU LIFEBOOK AH532
  Package: linux (not installed)
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-41-generic.efi.signed 
root=UUID=b9d1f4be-275f-4b97-a68a-ccb2afa41781 ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.16.0-41.55~14.04.1-generic 3.16.7-ckt11
  PulseList:
   Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not 
accessible: Permission denied
   No PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-3.16.0-41-generic N/A
   linux-backports-modules-3.16.0-41-generic  N/A
   linux-firmware 1.127.11
  Tags:  trusty
  Uname: Linux 3.16.0-41-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  dmi.bios.date: 05/22/2012
  dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
  dmi.bios.version: Version 1.09
  dmi.board.name: FJNBB1C
  dmi.board.vendor: FUJITSU
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU
  dmi.modalias: 
dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.09:bd05/22/2012:svnFUJITSU:pnLIFEBOOKAH532:pvr:rvnFUJITSU:rnFJNBB1C:rvr:cvnFUJITSU:ct10:cvr:
  dmi.product.name: LIFEBOOK AH532
  dmi.sys.vendor: FUJITSU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471380/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1273060] Re: [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

2015-10-25 Thread Jean-Pierre van Riel
To summarise, there are at least two other related bug reports (which should 
add motivation given the wider impact of the issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471380

-- 
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/1273060

Title:
  [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware
  access

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  :~$ apt-cache policy grub-efi-amd64
  grub-efi-amd64:
    Installed: 2.00-22
    Candidate: 2.00-22

  EFI installation of Ubuntu clears out the boot entries in firmware leaving 
user with no option but boot Ubuntu. Pressing (F2) to enter BIOS Setup has no 
effect as does pressing (F12) for Boot Order.
  The only way to get back firmware access is to flash the bios using 
manufacturer provided utilities. Unfortunately Fujitsu doesn't provide a BIOS 
flash utility for Linux/Ubuntu. It is to be noted that installed Windows in EFI 
mode on the same system does not clear out firmware access but just adds the 
'Windows Boot Loader' entry at the top of the boot sequence.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.13.0-5-generic 3.13.0-5.20 [modified: 
boot/vmlinuz-3.13.0-5-generic]
  ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
  Uname: Linux 3.13.0-5-generic x86_64
  ApportVersion: 2.13.1-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  satish 1852 F pulseaudio
  CurrentDesktop: Unity
  Date: Mon Jan 27 11:06:37 2014
  HibernationDevice: RESUME=UUID=c73dc7d0-4253-44fa-9589-d8c91c9cac13
  InstallationDate: Installed on 2014-01-26 (0 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140124)
  MachineType: FUJITSU LIFEBOOK LH532
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic.efi.signed 
root=UUID=efd53305-1eac-42ba-b3f9-828b72cb5560 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-5-generic N/A
   linux-backports-modules-3.13.0-5-generic  N/A
   linux-firmware1.122
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/24/2012
  dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
  dmi.bios.version: Version 1.10
  dmi.board.name: FJNBB1E
  dmi.board.vendor: FUJITSU
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU
  dmi.modalias: 
dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.10:bd05/24/2012:svnFUJITSU:pnLIFEBOOKLH532:pvr:rvnFUJITSU:rnFJNBB1E:rvr:cvnFUJITSU:ct10:cvr:
  dmi.product.name: LIFEBOOK LH532
  dmi.sys.vendor: FUJITSU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1082418] Re: [Fujitsu Lifebook AH532] Ubuntu UEFI install locks out UEFI firmware (~bios) access

2015-10-25 Thread Jean-Pierre van Riel
*** This bug is a duplicate of bug 1273060 ***
https://bugs.launchpad.net/bugs/1273060

** Changed in: linux (Ubuntu)
   Status: Expired => Confirmed

** This bug has been marked a duplicate of bug 1273060
   [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

-- 
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/1082418

Title:
  [Fujitsu Lifebook AH532] Ubuntu UEFI install locks out UEFI firmware
  (~bios) access

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  lsb_release -rd
  Description:  Ubuntu 12.10
  Release:  12.10

  apt-cache policy grub-efi-amd64
  grub-efi-amd64:
Installed: 2.00-7ubuntu11
Candidate: 2.00-7ubuntu11

  
  Pheonix Secure Core Tiano bios version 1.09

  New laptop Fujitsu Lifebook AH532. Windows 7 preinstalled. All
  functions worked normally when running Win7. Ubuntu 12.10 installed
  using whole disk. Installation successful Ubuntu boots and runs
  normally, however all access to the bios has now been lost. Pressing
  the default key (f2) during boot up is acknowledged by bios beep, but
  ignored and Ubuntu continues booting. In addition the 'boot choices'
  menu (f12) contains nothing but Ubuntu making it impossible to boot
  from USB or CD/DVD.

  The latter (f12) problem was overcome by opening up the machine,
  removing the ram and shorting the cl1/cl2 posts with a screwdriver.
  This restores the ability to boot from USB/CD by pressing f12 but does
  not restore bios access.

  The following recovery actions have been tried.
  1) Install Boot-Repair, run repair, no change occurred. Boot repair report 
here:
  http://paste.ubuntu.com/1375041/

  2) Restore Windows from Clonezilla disk image (factory settings) -
  result - bios access is no longer possible from windows either, f2 now
  launches the Windows boot menu.

  3) Update all drivers using Fujitsu driver update tool from within
  windows (which included a bios update). Result - no change, no bios.

  4) Restored Ubuntu from Clonezilla disk image - no change.

  5) Added second distro to disk. Installed successfully (uefi mode as
  that is all I have) no change to bios access.

  So overall result I have lost all bios access even from a reinstalled
  Windows. I repeat that bios access was perfectly normal before
  installing Ubuntu.

  I strongly suggest you read the contents of this thread in addition to
  the information here:

  http://ubuntuforums.org/showthread.php?t=2086602

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: grub-efi 2.00-7ubuntu11
  ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
  Uname: Linux 3.5.0-18-generic x86_64
  ApportVersion: 2.6.1-0ubuntu6
  Architecture: amd64
  Date: Fri Nov 23 15:50:07 2012
  InstallationDate: Installed on 2012-11-22 (1 days ago)
  InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
  MarkForUpload: True
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1451387] Re: Ubuntu UEFI install locks out UEFI firmware

2015-10-25 Thread Jean-Pierre van Riel
*** This bug is a duplicate of bug 1082418 ***
https://bugs.launchpad.net/bugs/1082418

** This bug has been marked a duplicate of bug 1273060
   [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

-- 
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/1451387

Title:
  [Fujitsu LIFEBOOK LH532] UEFI firmware becomes locked after installing
  Ubuntu in UEFI mode

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418/comments/74

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.16.0-30-generic 3.16.0-30.40~14.04.1
  ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.7
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon May  4 16:57:39 2015
  InstallationDate: Installed on 2010-01-01 (1949 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  SourcePackage: linux-lts-utopic
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.14.1-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  rut1480 F pulseaudio
rut7079 F pulseaudio
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=d4bb392e-90ed-41a3-9d30-fa457fefb25b
  InstallationDate: Installed on 2010-01-01 (1949 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  MachineType: FUJITSU LIFEBOOK LH532
  Package: linux (not installed)
  ProcFB:
   0 inteldrmfb
   1 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-30-generic.efi.signed 
root=UUID=e8258103-326b-4708-b64f-6306d0eb0a01 ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3
  PulseList:
   Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not 
accessible: Permission denied
   No PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-3.16.0-30-generic N/A
   linux-backports-modules-3.16.0-30-generic  N/A
   linux-firmware 1.127.11
  RfKill:
   0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
  Tags:  trusty
  Uname: Linux 3.16.0-30-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  dmi.bios.date: 05/24/2012
  dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
  dmi.bios.version: Version 1.10
  dmi.board.name: FJNBB1F
  dmi.board.vendor: FUJITSU
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU
  dmi.modalias: 
dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.10:bd05/24/2012:svnFUJITSU:pnLIFEBOOKLH532:pvr:rvnFUJITSU:rnFJNBB1F:rvr:cvnFUJITSU:ct10:cvr:
  dmi.product.name: LIFEBOOK LH532
  dmi.sys.vendor: FUJITSU
  --- 
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  rut2207 F pulseaudio
  DistroRelease: Ubuntu 15.04
  HibernationDevice: RESUME=UUID=8fd2670c-4060-4d14-8f27-b9f806fe2ce7
  InstallationDate: Installed on 2015-05-06 (0 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  MachineType: FUJITSU LIFEBOOK LH532
  Package: linux (not installed)
  ProcFB:
   0 inteldrmfb
   1 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic.efi.signed 
root=UUID=3129a485-81a2-48ef-be95-ef9c9a57be3e ro quiet splash
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  PulseList:
   Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not 
accessible: Permission denied
   No PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-3.19.0-15-generic N/A
   linux-backports-modules-3.19.0-15-generic  N/A
   linux-firmware 1.143
  RfKill:
   0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
  Tags:  vivid
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  Uname: Linux 3.19.0-15-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  dmi.bios.date: 05/24/2012
  dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
  dmi.bios.version: Version 1.10
  dmi.board.name: FJNBB1F
  dmi.board.vendor: FUJITSU
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU
  dmi.modalias: 
dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.10:bd05/24/2012:svnFUJITSU:pnLIFEBOOKLH532:pvr:rvnFUJITSU:rnFJNBB1F:rvr:cvnFUJITSU:ct10:cvr:
  dmi.product.name: LIFEBOOK LH532
  dmi.sys.vendor: FUJITSU

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1082418] Re: [Fujitsu Lifebook AH532] Ubuntu UEFI install locks out UEFI firmware (~bios) access

2015-10-25 Thread Jean-Pierre van Riel
And this bug isn't isolated to just to Fujitsu. The same thing just
happened to me with a Dell.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060

-- 
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/1082418

Title:
  [Fujitsu Lifebook AH532] Ubuntu UEFI install locks out UEFI firmware
  (~bios) access

Status in linux package in Ubuntu:
  Expired

Bug description:
  lsb_release -rd
  Description:  Ubuntu 12.10
  Release:  12.10

  apt-cache policy grub-efi-amd64
  grub-efi-amd64:
Installed: 2.00-7ubuntu11
Candidate: 2.00-7ubuntu11

  
  Pheonix Secure Core Tiano bios version 1.09

  New laptop Fujitsu Lifebook AH532. Windows 7 preinstalled. All
  functions worked normally when running Win7. Ubuntu 12.10 installed
  using whole disk. Installation successful Ubuntu boots and runs
  normally, however all access to the bios has now been lost. Pressing
  the default key (f2) during boot up is acknowledged by bios beep, but
  ignored and Ubuntu continues booting. In addition the 'boot choices'
  menu (f12) contains nothing but Ubuntu making it impossible to boot
  from USB or CD/DVD.

  The latter (f12) problem was overcome by opening up the machine,
  removing the ram and shorting the cl1/cl2 posts with a screwdriver.
  This restores the ability to boot from USB/CD by pressing f12 but does
  not restore bios access.

  The following recovery actions have been tried.
  1) Install Boot-Repair, run repair, no change occurred. Boot repair report 
here:
  http://paste.ubuntu.com/1375041/

  2) Restore Windows from Clonezilla disk image (factory settings) -
  result - bios access is no longer possible from windows either, f2 now
  launches the Windows boot menu.

  3) Update all drivers using Fujitsu driver update tool from within
  windows (which included a bios update). Result - no change, no bios.

  4) Restored Ubuntu from Clonezilla disk image - no change.

  5) Added second distro to disk. Installed successfully (uefi mode as
  that is all I have) no change to bios access.

  So overall result I have lost all bios access even from a reinstalled
  Windows. I repeat that bios access was perfectly normal before
  installing Ubuntu.

  I strongly suggest you read the contents of this thread in addition to
  the information here:

  http://ubuntuforums.org/showthread.php?t=2086602

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: grub-efi 2.00-7ubuntu11
  ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
  Uname: Linux 3.5.0-18-generic x86_64
  ApportVersion: 2.6.1-0ubuntu6
  Architecture: amd64
  Date: Fri Nov 23 15:50:07 2012
  InstallationDate: Installed on 2012-11-22 (1 days ago)
  InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
  MarkForUpload: True
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1273060] Re: [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

2015-10-25 Thread Jean-Pierre van Riel
This bug is high risk! It's effectively bricked a Dell Latitude E6540
:-(

My theory is that, somehow, the update caused a change to the firmware
NVRAM settings and boot entries for UEFI, and the Dell code can't handle
something unexpected. And after I've entered BIOS password, the firmware
code sadly fails to even manage to enter setup (F2) or the one time boot
menu (F12). That's lousy fail-safe coding on the firmware devs part.
Surely if searching NVRAM for boot options fails, that shouldn't keep
the user locked out of the BIOS settings!

Here's what happened in my case:
1. Had a working install of Ubuntu Gnome 15.04 dual booting with Windows 10 and 
BIOS version A15 for this dell.
2. UEFI Secure Boot was enabled. The UEFI boot order priority options were set 
to favour the ubuntu entry (which effectively points to the 
EFI/ubuntu/shimx64.efi entry).
3. I ran the standard upgrade via the GUI from 15.04 to 15.10.
4. Upgrade process reported success, prompted to reboot. After a reboot, the 
system failed to boot into grub or anything else! Even with a UEFI compatible 
install CD or USB drive, I couldn't get it to boot.
5. Both F2 (BIOS setup) and F12 (one time boot menu) no longer work! This is a 
HUGE issue, since now I can't even use the BIOS options to change UEFI settings 
(e.g. look at enabled boot options, priority or disable secure boot, etc)
6. Opened up the laptop, disconnected the coin-cell CMOS battery, pressed the 
power button to discharge and force a BIOS settings reset (I've followed this 
process on many other systems to deal with a bugged out BIOS). Sadly no luck, 
same issue persists (I'm guessing removing the CMOS battery didn't manage to 
reset the NVRAM as I hoped).

What's interesting is I can take the SSD drive out, put it in a similar
laptop, and it boots. It booted into Windows 10 at first, but after
using settings (F2) on the working laptop, I could simply switch to the
EFI/ubuntu/shimx64.efi as the first option and UEFI secure boot into
Ubuntu Gnome 15.10 works fine.

-- 
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/1273060

Title:
  [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware
  access

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  :~$ apt-cache policy grub-efi-amd64
  grub-efi-amd64:
    Installed: 2.00-22
    Candidate: 2.00-22

  EFI installation of Ubuntu clears out the boot entries in firmware leaving 
user with no option but boot Ubuntu. Pressing (F2) to enter BIOS Setup has no 
effect as does pressing (F12) for Boot Order.
  The only way to get back firmware access is to flash the bios using 
manufacturer provided utilities. Unfortunately Fujitsu doesn't provide a BIOS 
flash utility for Linux/Ubuntu. It is to be noted that installed Windows in EFI 
mode on the same system does not clear out firmware access but just adds the 
'Windows Boot Loader' entry at the top of the boot sequence.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.13.0-5-generic 3.13.0-5.20 [modified: 
boot/vmlinuz-3.13.0-5-generic]
  ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
  Uname: Linux 3.13.0-5-generic x86_64
  ApportVersion: 2.13.1-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  satish 1852 F pulseaudio
  CurrentDesktop: Unity
  Date: Mon Jan 27 11:06:37 2014
  HibernationDevice: RESUME=UUID=c73dc7d0-4253-44fa-9589-d8c91c9cac13
  InstallationDate: Installed on 2014-01-26 (0 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140124)
  MachineType: FUJITSU LIFEBOOK LH532
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic.efi.signed 
root=UUID=efd53305-1eac-42ba-b3f9-828b72cb5560 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-5-generic N/A
   linux-backports-modules-3.13.0-5-generic  N/A
   linux-firmware1.122
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/24/2012
  dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
  dmi.bios.version: Version 1.10
  dmi.board.name: FJNBB1E
  dmi.board.vendor: FUJITSU
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU
  dmi.modalias: 
dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.10:bd05/24/2012:svnFUJITSU:pnLIFEBOOKLH532:pvr:rvnFUJITSU:rnFJNBB1E:rvr:cvnFUJITSU:ct10:cvr:
  dmi.product.name: LIFEBOOK LH532
  dmi.sys.vendor: FUJITSU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1273060] Re: [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

2015-10-25 Thread Jean-Pierre van Riel
@Chistopher, thanks, the problem is now that my A15 bios can't even
enter setup mode or boot anything, so I'm not sure how to try flash the
most recent A16 version from (released just a month ago)? Searched the
laptop's manual, and no indication of any jumpers to clear/reset NVRAM
:-(

I agree and understand that firmware should be written in a way that
doesn't allow the nvram boot option changes to cause it to lock up.
Still, this kind of bug (even if attributed to firmware and not Linux)
is occurring across at least two manufactures (Fujitsu and now Dell)
whereby their 'buggy' firmware sees whatever changes ubuntu/Linux made
to the NVRAM as NVRAM corruption and fail to even allow entering setup.

Given changing NVRAM bios settings during an install or update (as was
my case) is high risk, perhaps the install process should at least issue
a warning and allow the user to opt out of of clearing and changing
NVRAM settings (and potentially trigger a nasty firmware bug). I think
it would in some cases be safer for a user to manually go into the BIOS
setup and manage the boot options from within the BIOS.

-- 
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/1273060

Title:
  [Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware
  access

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  :~$ apt-cache policy grub-efi-amd64
  grub-efi-amd64:
    Installed: 2.00-22
    Candidate: 2.00-22

  EFI installation of Ubuntu clears out the boot entries in firmware leaving 
user with no option but boot Ubuntu. Pressing (F2) to enter BIOS Setup has no 
effect as does pressing (F12) for Boot Order.
  The only way to get back firmware access is to flash the bios using 
manufacturer provided utilities. Unfortunately Fujitsu doesn't provide a BIOS 
flash utility for Linux/Ubuntu. It is to be noted that installed Windows in EFI 
mode on the same system does not clear out firmware access but just adds the 
'Windows Boot Loader' entry at the top of the boot sequence.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.13.0-5-generic 3.13.0-5.20 [modified: 
boot/vmlinuz-3.13.0-5-generic]
  ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
  Uname: Linux 3.13.0-5-generic x86_64
  ApportVersion: 2.13.1-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  satish 1852 F pulseaudio
  CurrentDesktop: Unity
  Date: Mon Jan 27 11:06:37 2014
  HibernationDevice: RESUME=UUID=c73dc7d0-4253-44fa-9589-d8c91c9cac13
  InstallationDate: Installed on 2014-01-26 (0 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140124)
  MachineType: FUJITSU LIFEBOOK LH532
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic.efi.signed 
root=UUID=efd53305-1eac-42ba-b3f9-828b72cb5560 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-5-generic N/A
   linux-backports-modules-3.13.0-5-generic  N/A
   linux-firmware1.122
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/24/2012
  dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
  dmi.bios.version: Version 1.10
  dmi.board.name: FJNBB1E
  dmi.board.vendor: FUJITSU
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU
  dmi.modalias: 
dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.10:bd05/24/2012:svnFUJITSU:pnLIFEBOOKLH532:pvr:rvnFUJITSU:rnFJNBB1E:rvr:cvnFUJITSU:ct10:cvr:
  dmi.product.name: LIFEBOOK LH532
  dmi.sys.vendor: FUJITSU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp