@apt-ghetto
Thanks for you're analysis. I have no option to boot in legacy mode...
@apt-ghetto said:
> ..you can install Ubuntu in BIOS mode simply by booting the installer in
> the BIOS mode.
> (Depending on the UEFI you have and how you created the USB stick, this is
> not always a simple
Is this a "grub-installer" bug -or- is the use of grub in "ubiquity" the
problem ???
If the latter, then this bug should be assigned to the "ubiquity"
package...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
> Is this really a bug?
When the previous LTS had not problems in these situations, then it's
not only a bug but a regression as well.
When a large portion of your user-base is experiencing trouble where
they don't expect it and/or had none before, it should be fixed.
Especially when a fix is (ea
@oldfred; I understand your argument, but this doesn't take reality in
account. I've looked for similar bugs (very likely duplicates of this
one or visa versa) and there are more than 250 reports regarding grub
failures at the end of the installation or upgrade. In theory you are
right, in practice
Although the bug is a bit different, the workaround in the bug below is
quite generic. Maybe you could try it or adapt it to your needs:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1771651
I hope this helps, regards,
Onno
--
You received this bug notification because you are a
Could you try the workaround found here:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1771651 ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1771675
Title:
Ubuntu18.04 fail to inst
For the people who are looking for a workaround; I think you have three
options:
- Use a GPT partition table on the disk
- Boot the installer in legacy mode
- When both are not an option (or fail), use the workaround described in:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/17716
Can anybody confirm that the workaround in the bug report below works?
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1771651
If so, then it could be a duplicate...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
Public bug reported:
Release: Ubuntu 18.04 LTS (Bionic Beaver)
Summary: The installation fails with a "GRUB installation failed" message.
Workaround available, see below.
Since 16.04 installed fine, you could see this as a regression...
* System setup (relevant part only)
- UEFI enable
*** This bug is a duplicate of bug 1132063 ***
https://bugs.launchpad.net/bugs/1132063
A also experience the bug in Ubuntu 16.04 final beta. Using a Logitech
wireless optical mouse.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Yes. :) I definitely made sure it was using OpenGL and that I was
running it on my HD4000 and not the nVidia chipset.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1180646
Title:
cairo-dock render
I also tested with edgers 10.2 packages, like k3mist, and it is still
working perfectly. I too rebooted and checked multiple times that
everything is good.
I found other bugs with the current 10.1 packages in trusty, but they're
not related to this issue.
--
You received this bug notification b
Excellent! It appears this bug is fixed in Mesa 10.1 and later, and can
finally be closed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1180646
Title:
cairo-dock rendering issues using openGL back
I've been seeing the same glitches, starting when the updated mesa
packages were pushed out on 2/20:
http://ubuntuforums.org/showthread.php?t=2206883
At exactly the same time the glitches appeared, the primus bridge quit
working for Bumblebee: https://github.com/amonakov/primus/issues/133
Backle
I can hardly believe my eyes, but this bug appears to be FIXED under the
current libraries in the Trusty beta.
evil@clevo:~$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version stri
Bug also occurs with Mesa 9.2.2, in Ubuntu 14.04 pre-alpha:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.2
OpenGL core profile shading language version string: 1
Problem still occurs with Mesa 9.2.1
evil@clevo:~$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.1
OpenGL core profile shading language vers
I can also recreate it at 9.2.0 (using Ubuntu 13.10 beta).
Symptoms appear same as the original when using cairo-dock.
-
evil@clevo:~/src/clevokbledui$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI
I've also been able to recreate this issue while running cairo-dock on a
Clevo P150EM (Intel HD4000).
I see the status is NEEDINFO. I've worked around the issue for myself
by just using the cairo back end, but is there any info/testing I can
provide to help resolve the issue when using OpenGL?
e
Please add an option (command-line or config file) to make the X server
stop lying about the physical DPI of the display device. I understand
all the arguments for pegging DPI at 96, but *I* still want my X server
to report the actual DPI as read from the EDID.
Maybe add an -autodpi command-line
It's apparmor. See /var/log/syslog
Aug 1 22:37:19 magna kernel: [119350.467189] type=1400
audit(1343853439.594:46): apparmor="DENIED" operation="mknod"
parent=15003 profile="/usr/sbin/mysqld" name="/run/tmp/ibQJ1cz5"
pid=15094 comm="mysqld
Note: I've symlinked /tmp to /run/tmp ...
To fix, edit:
Even if floppies are rare on the general desktop, I would sure like to
see this fixed. Floppies still have a strong niche in specialty
equipment. I have a bunch of machines here with floppy drives.
Is there a work-around? Older version that works? Udisks2? Other?
--
You received this bug no
I can confirm the findings of "FernanAguero".
The fix is:
- delete the home dir
- remove from /etc/group
- remove from /etc/gshadow
Now you can recreate a user you have deleted.
Good starting point for the devs.
Regards,
OE
--
creating new user account silently fails when UID is al
23 matches
Mail list logo
