[Bug 1969945] [NEW] Update background preference for 22.04 (jammy)
Public bug reported: The vanilla-gnome-default-settings package does not revert the Ubuntu background/screensaver images to gnome behavior in 22.04. vanilla-gnome-default-settings contains the file /usr/share/glib-2.0/schemas/20_vanilla-gnome-default- settings.gschema.override for reinstating most gnome default settings. The keys org.gnome.desktop.background.picture-uri and org.gnome.desktop.screensaver.picture-uri currently point to the file /usr/share/backgrounds/gnome/adwaita-timed.xml, which was removed from the gnome-backgrounds package in 22.04. The removal appears to be related to a change in the way Gnome 42 handles background images in the context of light/dark theme preferences. gnome-control-center seems to be in a halfway migrated state between Gnome 41 and 42, so I'm not completely sure I understand what the right fix here should be... Simply updating the keys to point to (what appears to be the new equivalent file?) /usr/share/gnome-background- properties/adwaita.xml doesn't change anything. I think a minimal (short term?) fix is to set [org.gnome.desktop.background] picture-uri='file:///usr/share/backgrounds/gnome/adwaita-l.jpg' picture-uri-dark='file:///usr/share/backgrounds/gnome/adwaita-d.jpg' There is not an equivalent 'dark' version of the key for the screensaver portion, though... There are also some new 'primary-color', 'secondary- color' keys which should probably be considered (their upstream gnome values appear to be '#023c88' and '#5789ca' respectively). ** Affects: ubuntu-gnome-default-settings (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1969945 Title: Update background preference for 22.04 (jammy) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1969945/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1960080] Re: libgcc_s.so.1 must be installed for pthread_exit to work
*** This bug is a duplicate of bug 1958594 *** https://bugs.launchpad.net/bugs/1958594 ** This bug has been marked a duplicate of bug 1958594 Boot error: libgcc_s.so.1 must be installed for pthread_exit to work -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1960080 Title: libgcc_s.so.1 must be installed for pthread_exit to work To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1960080/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1960080] [NEW] libgcc_s.so.1 must be installed for pthread_exit to work
Public bug reported: I'm unable to decrypt my root partition at boot using the cryptsetup- initramfs package currently in jammy (2:2.4.2-1ubuntu4). I get the askpass prompt, but after entering the password, decryption fails with the error message: libgcc_s.so.1 must be installed for pthread_exit to work and I'm prompted to retry. This library indeed seems to be missing from the initrd file: lsinitramfs /boot/initrd.img-5.15.0-18-generic | grep libgcc Compared with an identically configured image running impish: lsinitramfs /boot/initrd.img-5.13.0-28-generic | grep libgcc usr/lib/x86_64-linux-gnu/libgcc_s.so.1 I noticed the following line in the jammy changelog: * cryptsetup-initramfs now requires initramfs-tools 0.137 or later and no longer copies libgcc_s.so.1 to the initrd since recent initramfs-tools take care of it. And found the following lines in the impish version of /usr/share/initramfs-tools/hooks/cryptroot: # libargon2 uses pthread_cancel for so in $(ldconfig -p | sed -nr 's/^\s*libgcc_s\.so.*=>\s*//p'); do copy_exec "$so" done Which are not in the jammy version. Adding an explicit copy_exec line for this library and rebuilding the initrd file fixes the problem. I'm not exactly sure which binary in the cryptsetup initrd inclusion requires this library (it doesn't appear to be the askpass nor cryptsetup binaries), but whatever it is doesn't seem to be properly declaring its dependency for inclusion. I also don't completely understand the changelog message that implies inclusion of this library is now the responsibility of initramfs- tools... ** Affects: cryptsetup (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1960080 Title: libgcc_s.so.1 must be installed for pthread_exit to work To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1960080/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577800] Re: Frequent disconnects with Intel 8260 wireless NIC
I haven't had any problems since upgrading to yakkety: 4.8.0-30-generic #32-Ubuntu driver: iwlwifi version: 4.8.0-30-generic firmware-version: 22.361476.0 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577800 Title: Frequent disconnects with Intel 8260 wireless NIC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577800/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1336663] Re: lightdm uses wrong ccache name on pam_krb5 credentials refresh
FWIW, this issue is also present using gdm3 in Ubuntu 16.04. With pam_krb5's debug option set, I see the following during initial login (with successful credential cache construction): gdm-password]: pam_krb5(gdm-password:auth): pam_sm_authenticate: entry gdm-password]: pam_krb5(gdm-password:auth): (user cgallek) attempting authentication as cgal...@.com gdm-password]: pam_krb5(gdm-password:auth): user cgallek authenticated as cgal...@.com gdm-password]: pam_krb5(gdm-password:auth): (user cgallek) temporarily storing credentials in /tmp/krb5cc_pam_LB8CeL gdm-password]: pam_krb5(gdm-password:auth): pam_sm_authenticate: exit (success) gdm-password]: pam_krb5(gdm-password:setcred): pam_sm_setcred: entry (establish) gdm-password]: pam_krb5(gdm-password:setcred): (user cgallek) initializing ticket cache FILE:/tmp/krb5cc_1000_3BiTY0 gdm-password]: pam_krb5(gdm-password:setcred): pam_sm_setcred: exit (success) When unlocking the screen, I see the following successful credential refresh, but to the wrong cache filename (/tmp/krb5cc_0): gdm-password]: pam_krb5(gdm-password:auth): pam_sm_authenticate: entry gdm-password]: pam_krb5(gdm-password:auth): (user cgallek) attempting authentication as cgal...@angrydoughnuts.com gdm-password]: pam_krb5(gdm-password:auth): user cgallek authenticated as cgal...@.com gdm-password]: pam_krb5(gdm-password:auth): (user cgallek) temporarily storing credentials in /tmp/krb5cc_pam_Dkg5Ip gdm-password]: pam_krb5(gdm-password:auth): pam_sm_authenticate: exit (success) gdm-password]: pam_krb5(gdm-password:setcred): pam_sm_setcred: entry (reinit) gdm-password]: pam_krb5(gdm-password:setcred): (user cgallek) refreshing ticket cache /tmp/krb5cc_0 gdm-password]: pam_krb5(gdm-password:setcred): pam_sm_setcred: exit (success) The _0 cache that is created has the correct new credential in it, but is obviously not known by any other process as it does not match the earlier version of $KRB5CCNAME. I imagine this is the same issue described above where the $KRB5CCNAME environment variable is not available in the gdm context which unlocks the screen. It's worth noting that in the GDM case, there appears to be a per- session helper process (gdm-session-worker) used to communicate with the GDM service. This process _does not_ have the $KRB5CCNAME variable set in its environment. Would storing the value in this processes environment fix the problem? ~: ps -ef | grep gdm-session-worker root 11364 11203 0 Jun25 ?00:00:00 gdm-session-worker [pam/gdm-password] ~: cat /proc/11364/environ LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binGDM_SESSION_DBUS_ADDRESS=unix:abstract=/tmp/dbus-oTnmcExV ** Also affects: gdm Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1336663 Title: lightdm uses wrong ccache name on pam_krb5 credentials refresh To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1336663/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577800] Re: Frequent disconnects with Intel 8260 wireless NIC
I'm not sure I would say it worked well, but it did fix one of two problems. The second was only fixed after both driver and firmware upgrades. I'm no longer running the 19.ucode version. Would apport data for the 21 version with the updated driver be useful? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577800 Title: Frequent disconnects with Intel 8260 wireless NIC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577800/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577800] Re: Frequent disconnects with Intel 8260 wireless NIC
I used version Core18 of the iwlwifi backports repository:
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/?h=release/LinuxCore18
and the current ubuntu 4.4 kernel with the following dkms.conf:
MAKE="'make' -j 12 KERNELDIR=/lib/modules/${kernelver}/build"
CLEAN="/bin/true"
PACKAGE_NAME=iwlwifi
PACKAGE_VERSION=Core18
REMAKE_INITRD=yes
BUILT_MODULE_NAME[0]=compat
BUILT_MODULE_LOCATION[0]=compat
DEST_MODULE_LOCATION[0]=/kernel/compat
BUILT_MODULE_NAME[1]=cfg80211
BUILT_MODULE_LOCATION[1]=net/wireless
DEST_MODULE_LOCATION[1]=/kernel/net/wireless
BUILT_MODULE_NAME[2]=mac80211
BUILT_MODULE_LOCATION[2]=net/mac80211
DEST_MODULE_LOCATION[2]=/kernel/net/mac80211
BUILT_MODULE_NAME[3]=iwlwifi
BUILT_MODULE_LOCATION[3]=drivers/net/wireless/intel/iwlwifi
DEST_MODULE_LOCATION[3]=/kernel/drivers/net/wireless/intel/iwlwifi
BUILT_MODULE_NAME[4]=iwlmvm
BUILT_MODULE_LOCATION[4]=drivers/net/wireless/intel/iwlwifi/mvm
DEST_MODULE_LOCATION[4]=/kernel/drivers/net/wireless/intel/iwlwifi/mvm
BUILT_MODULE_NAME[5]=iwlxvt
BUILT_MODULE_LOCATION[5]=drivers/net/wireless/intel/iwlwifi/xvt
DEST_MODULE_LOCATION[5]=/kernel/drivers/net/wireless/intel/iwlwifi/xvt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1577800
Title:
Frequent disconnects with Intel 8260 wireless NIC
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577800/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577800] Re: Frequent disconnects with Intel 8260 wireless NIC
It did indeed fix the problem I was seeing in this bug report. However, I started having another less frequent issue shortly after (also disconnects, but completely different errors). I was only able to solve that one by getting the newest firmware (-21.ucode) AND rebuilding the iwlwifi modules with the latest version of the upstream driver code. I'm not sure exactly which change in the driver fixed my issue, though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577800 Title: Frequent disconnects with Intel 8260 wireless NIC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577800/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577800] Re: Frequent disconnects with Intel 8260 wireless NIC
Please see the upstream bug report for all of the necessary debugging logs. However, the bug has already been identified and the issue here is really just deciding how to package the fix. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577800 Title: Frequent disconnects with Intel 8260 wireless NIC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577800/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577800] [NEW] Frequent disconnects with Intel 8260 wireless NIC
Public bug reported: This issue has been resolved upstream and is described in https://bugzilla.kernel.org/show_bug.cgi?id=117391 The current Ubuntu Xenial Xerus kernel (4.4.0-21.37) is built with a version of the iwlwifi driver which supports firmware version up to iwlwifi-8000C-19.ucode. However, the matching linux-firmware package ships with the -16.ucode version of the firmware, which contains this bug. The next stable version of the firmware after -16.ucode is -21.ucode, but is not supported by the version of the iwlwifi driver in the 4.4.0 kernel. In order to fix this issue, either the minor version of the firmware (-19.ucode) needs to be included in the linux-firmware package or the iwlwifi driver in the kernel package needs to be upgraded with a backport of the iwlwifi driver new enough to support the -21.ucode firmware. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577800 Title: Frequent disconnects with Intel 8260 wireless NIC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577800/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1475954] Re: grub does not validate kernel signature during secure boot
** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1475954 Title: grub does not validate kernel signature during secure boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1475954/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1475954] Re: grub does not validate kernel signature during secure boot
Thanks for the update. Do you know if it's even possible to use grub to verify the signatures of the currently distributed signed Ubuntu kernels? As far as I can tell, grub only supports gpg detached signatures. The Ubuntu kernels seem to be signed using sbsigntool with an X509 certificate and private key. If not, I believe the only way to actually use secure boot with an Ubuntu kernel is to directly load the kernel from the EFI without using grub... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1475954 Title: grub does not validate kernel signature during secure boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1475954/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1279116] Re: Missing tmp directory for GSSAPI authentication
Thanks for the quick response. I started poking around in the debian bugs database and found a similar issue described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606007 I submitted a comment asking to have the tmp directory added to the chroot tree. ** Bug watch added: Debian Bug tracker #606007 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606007 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to postfix in Ubuntu. https://bugs.launchpad.net/bugs/1279116 Title: Missing tmp directory for GSSAPI authentication To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1279116/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1279116] Re: Missing tmp directory for GSSAPI authentication
Thanks for the quick response. I started poking around in the debian bugs database and found a similar issue described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606007 I submitted a comment asking to have the tmp directory added to the chroot tree. ** Bug watch added: Debian Bug tracker #606007 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606007 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1279116 Title: Missing tmp directory for GSSAPI authentication To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1279116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1279116] [NEW] Missing tmp directory for GSSAPI authentication
Public bug reported: I had some trouble getting GSSAPI authentication in postfix working when moving my mail system to a new machine. GSSAPI is a bit complicated with postfix since it runs in a chroot jail. There are several guides available for this process (in particular, getting the keytab and krb5.conf files in the right place), and I did have it working on my previous machine, so I was pretty sure I had the configuration correct and that there was something wrong with the newly installed system. Postfix was producing the following errors in the system log: postfix/smtpd[5099]: warning: SASL authentication failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () postfix/smtpd[5099]: warning: host[x.x.x.x]: SASL GSSAPI authentication failed: generic failure. That error was not terribly useful, but strace-ing the smtpd process produced the source of the real error: lstat(/var/tmp/smtp_118, 0x7fffcafd42f0) = -1 ENOENT (No such file or directory) unlink(/var/tmp/smtp_118) = -1 ENOENT (No such file or directory) open(/var/tmp/smtp_118, O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = -1 ENOENT (No such file or directory) unlink(/var/tmp/smtp_118) = -1 ENOENT (No such file or directory) The process was unable to create a credential cache because the /var/tmp directory did not exist under the chroot filesystem. Creating the directory /var/spool/postfix/var/tmp with postfix-writeable permissions fixed the problem and GSSAPI authentication started working. I'm not exactly sure why the gssapi library was using /var/tmp instead of /tmp (which didn't exist either). kerberos credentials for the rest of my system are stored in /tmp. I think the postfix package should be altered to include a /var/tmp directory in the chroot file hierarchy. If that is not possible, the gssapi configuration within the chroot should be setup to use a different directory for the credential cache, which does exist and has the proper permissions. ** Affects: postfix (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to postfix in Ubuntu. https://bugs.launchpad.net/bugs/1279116 Title: Missing tmp directory for GSSAPI authentication To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1279116/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1279116] [NEW] Missing tmp directory for GSSAPI authentication
Public bug reported: I had some trouble getting GSSAPI authentication in postfix working when moving my mail system to a new machine. GSSAPI is a bit complicated with postfix since it runs in a chroot jail. There are several guides available for this process (in particular, getting the keytab and krb5.conf files in the right place), and I did have it working on my previous machine, so I was pretty sure I had the configuration correct and that there was something wrong with the newly installed system. Postfix was producing the following errors in the system log: postfix/smtpd[5099]: warning: SASL authentication failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () postfix/smtpd[5099]: warning: host[x.x.x.x]: SASL GSSAPI authentication failed: generic failure. That error was not terribly useful, but strace-ing the smtpd process produced the source of the real error: lstat(/var/tmp/smtp_118, 0x7fffcafd42f0) = -1 ENOENT (No such file or directory) unlink(/var/tmp/smtp_118) = -1 ENOENT (No such file or directory) open(/var/tmp/smtp_118, O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = -1 ENOENT (No such file or directory) unlink(/var/tmp/smtp_118) = -1 ENOENT (No such file or directory) The process was unable to create a credential cache because the /var/tmp directory did not exist under the chroot filesystem. Creating the directory /var/spool/postfix/var/tmp with postfix-writeable permissions fixed the problem and GSSAPI authentication started working. I'm not exactly sure why the gssapi library was using /var/tmp instead of /tmp (which didn't exist either). kerberos credentials for the rest of my system are stored in /tmp. I think the postfix package should be altered to include a /var/tmp directory in the chroot file hierarchy. If that is not possible, the gssapi configuration within the chroot should be setup to use a different directory for the credential cache, which does exist and has the proper permissions. ** Affects: postfix (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1279116 Title: Missing tmp directory for GSSAPI authentication To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1279116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1188364] [NEW] grub-install will install a misconfigured EFI image on removable media when /boot is also on the removable media
Public bug reported: With vanilla grub, grub-install with the --removable flag will install in the grubx64.efi file in the EFI/BOOT directory of an efi partition. If the --boot-directory flag is used, grub-install will also generate a configuration file in EFI/BOOT which will try to source the grub.cfg file from the supplied boot directory. For example, in my case, the following grub.cfg file is generated: search.fs_uuid e83c44ec-cedd-11e2-874f-4c72b927200b root hd1,msdos1 set prefix=($root)/grub configfile $prefix/grub.cfg Here, the UUID is the boot partition of my system and that the prefix used is relative to the supplied boot directory and does not contain the string 'boot'. The standard grubx64.efi generated by grub-mkimage (specifically, not using the -c option to include a configuration file) uses a heuristic to try to find a configuration file. The first step of this heuristic is to look in the local directory. Using a vanilla grubx64.efi built with grub-mkimage, grub-install correctly installs the efi boot loader, the above configuration file, and the system boots by sourcing the real grub.cfg file on the referenced boot partition. In this change: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/grub2/raring/revision/154 A script was added to the ubuntu packaging of grub which builds custom versions of the grub efi boot loader image. Specifically, the 'gcd' version of the loader built with grub-mkimage on line 62 is built with a default configuration in it labeled Skeleton configuration file which finds the real boot disk. This configuration unconditionally sets the prefix to ($root)/boot/grub and makes the assumption that the grub directory will be in a directory called boot on the root partition rather than on a dedicated partition. Further, it assumes that the root partition will contain an info or a mini-info file. This breaks the chain loading described above by removing the part of the configuration search heuristic that looks in the local directory. I don't completely understand why the grub-install script uses the gcd loader in the removable case (http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/raring/grub2/raring/view/head:/util/grub- install.in#L837). I also don't completely understand why the ubuntu customization of the gcd loader needs to include a default configuration (the same configuration could have been used by placing the file in the install directory, just like grub-install does for its customizations). The assumption of directory structure is certainly wrong in the ubuntu customization at least for the general case, but I'm not sure if the fix for my situation is to fix the gcd file that gets generated, or to change grub-install to use the non-customized version of the efi loader. ** Affects: grub2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1188364 Title: grub-install will install a misconfigured EFI image on removable media when /boot is also on the removable media To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1188364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 630748] Re: iwlagn degrades quickly during normal wifi session
I've tested the experimental firmware (iwlwifi-5000-exp-8.83.5.1) with a 5300 card and kernel 2.6.36.2. Initially it seems to have solved the problem. iwconfig reported bit rate maxes out at 300 Mb/s (though it drops to 6 Mb/s during inactivity). File transfer rates are significantly greater than they were with N disabled. There are quite a few of the following messages in the syslog, but that may be expected given the kernel debugging options necessary in order to run the experimental firmware. iwlagn :03:00.0: Aggregation not enabled for tid 0 because load = 1 iwlagn :03:00.0: iwlagn_tx_agg_start on ra = xx:xx:xx:xx:xx:xx tid = 0 iwlagn :03:00.0: Aggregation not enabled for tid 0 because load = 2 iwlagn :03:00.0: iwlagn_tx_agg_start on ra = xx:xx:xx:xx:xx:xx tid = 0 iwlagn :03:00.0: iwlagn_tx_agg_start on ra = xx:xx:xx:xx:xx:xx tid = 0 However, after about 10 minutes of inactivity, the connection becomes inoperable. Reloading the module fixes the problem temporarily, but it hasn't held a connection for more than 15 minutes at a time. This is significantly longer than without the experimental firmware, but it doesn't seem to have completely fixed the problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/630748 Title: iwlagn degrades quickly during normal wifi session -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 630748] Re: iwlagn degrades quickly during normal wifi session
Sorry, missed the upstream link above... https://bugzilla.kernel.org/show_bug.cgi?id=16691#c82 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/630748 Title: iwlagn degrades quickly during normal wifi session -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 517060] Re: hardy-lucid upgrade using linux-image-xen breaks systems running in PV mode under xen/xenserver
I agree. Ubuntu is def. the Linux distribution of choice for our servers, and now that we have a XenServer setup it is a bit frustrating that the later distributions of Ubuntu seem to be the only ones that lack a simple a way to get it running paravirtualized under Xen. -- hardy-lucid upgrade using linux-image-xen breaks systems running in PV mode under xen/xenserver https://bugs.launchpad.net/bugs/517060 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 421530] [NEW] Cover art plungin - Amazon product advertising API now requires signature
Public bug reported: Binary package hint: rhythmbox Requests made by the cover art plugin are failing with HTTP response code 400 and the following response: ?xml version=1.0? ItemSearchErrorResponse xmlns=http://ecs.amazonaws.com/doc/2005-10-05/;ErrorCodeMissingParameter/CodeMessageThe request must contain the parameter Signature./Message/ErrorRequestID04dd4563-2250-4635-af70-cb27059ede36/RequestID/ItemSearchErrorResponse The API has apparently changed to require a signature. See http://developer.amazonwebservices.com/connect/ann.jspa?annID=476 http://apisigning.com/ The change happened about 2 weeks ago, but I couldn't find any Ubuntu nor upstream bugs. ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 9.04 ExecutablePath: /usr/bin/rhythmbox Package: rhythmbox 0.12.0-0ubuntu4 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: rhythmbox Uname: Linux 2.6.30 i686 ** Affects: rhythmbox (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 -- Cover art plungin - Amazon product advertising API now requires signature https://bugs.launchpad.net/bugs/421530 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 421530] Re: Cover art plungin - Amazon product advertising API now requires signature
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/31014439/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/31014440/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/31014441/ProcStatus.txt -- Cover art plungin - Amazon product advertising API now requires signature https://bugs.launchpad.net/bugs/421530 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
