(New kernel is still compiling...)
I just did a test with a fully-patched, newly spun-up Ubuntu Server
14.04 AWS instance, and the behavior seems to be present with kernel
3.13.0-107. I can't verify all of the symptoms described by the
reporter, because I don't have physical access; but I get
Thanks for your attention on this bug, Joseph. I'm compiling the new
kernel, now, and will let you know as soon as I have a test result.
As far as I know, all 16.04 kernel versions exhibit this problem; but I
haven't done any testing on Ubuntu 15.X.
--
You received this bug notification
I've tested this with kernel 4.10-rc3 in a local VirtualBox VM (Ubuntu
Server 16.04), with the same fstab error as above, and am able to
confirm most of the symptoms described by the reporter.
When attempting to 'mount -a', it presents the expected "wrong
filesystem type" error, but doesn't
Public bug reported:
OS VERSION
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.04
DISTRIB_CODENAME=zesty
DISTRIB_DESCRIPTION="Ubuntu 17.04"
UPOWER VERSION
upower:
Installed: 0.99.4-4
Candidate: 0.99.4-4
Version table:
*** 0.99.4-4 500
500 http://us.archive.ubuntu.com/ubuntu zesty/main amd64
Issue persists in 18.04. All OS upgrades installed as of June 25, 2018.
Dell XPS 13" L321X Mini Displayport -> HDMI adapter -> HDMI cable -> LG
43lx570h television.
Interestingly, I was able to get this setup to work on a different model
of television, just a few days earlier. I don't
I've also been having this problem since 16.04. Dell XPS 13" 2015,
model L321X. The issue persists in Ubuntu 18.04 LTS, as well as Ubuntu
Mint 18.04 LTS. Dell's support page indicates that this issue existed
in 14.04, but disappeared in 15.04. This may be a regression.
Could fstab default mount options be changed so that, unless otherwise
specified, failed mount attempts would skip that filesystem and keep
booting (logging an error), instead of dropping to an inaccessible
recovery console? This would let the fstab be fixed with minimal hassle
in a headless
Public bug reported:
Tested on Linux Mint 19.1 AMD64 Cinnamon (Ubuntu 18.04 LTS base).
When copying an audio CD (didn't test with other media), this error
causes the writing process to abort before beginning:
/usr/bin/wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK
limits.
I'm seeing this bug in Linux Mint 19.1 (Ubuntu 18.04 base). The audio
devices do not appear and disappear in the "Sounds" GUI. The workaround
I've found is to do this in a terminal:
pulseaudio -k && sleep 5 ; pulseaudio -D
Sometimes this works for hours, and sometimes it works for minutes,
I'm seeing this bug in Linux Mint 19.1 (Ubuntu 18.04 base). The audio
devices do not appear and disappear in the "Sounds" GUI. The workaround
I've found is to do this in a terminal:
pulseaudio -k && sleep 5 ; pulseaudio -D
Sometimes this works for hours, and sometimes it works for minutes,
@Chris Guiver Thank-you for taking the time to respond to this bug
report!
I've done some upgrades, since I posted the original report, but after
uninstalling and reinstalling K3B and Wodim, the symptoms are the same
(partial log output, with error, below). The "chmod +r /usr/bin/wodim"
trick
Yes, this looks like the same thing. The root of the problem is that
/usr/bin/wodim is lacking the u+s (where user=root) permission.
Fixing it might just be a matter of changing the permissions of this
file in the .deb package. However, if upstream expects wodim to be
installed in the home
12 matches
Mail list logo
