Custom Query (1145 matches)
Results (37 - 39 of 1145)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1512 | fixed | Disable the stupid GRUB diskfilter error message | jdreed | |
Description |
Because GRUB still can't deal with LVM in 2014, but tries to anyway, you get an annoying "diskfilter writes are not supported" error and booting is delayed by 5 seconds. We can trivially fix this on cluster (which is the only place we really care about) by scribbling over recordfail() entirely. |
|||
#1510 | fixed | 3partysw new package request | alexp | |
Description |
ChemE teaching faculty hjkulik request for avogadro package, for 10.437 in Fall |
|||
#1508 | duplicate | File OpenAFS bug about apparmor | jdreed | |
Description |
In some cases, apparmor is convinced that a user process is directly accessing the OpenAFS cache, and prior to debathena-apparmor-config 1.2.9, would deny it. apparmor's denial causes OpenAFS to think the fileserver went down, and then it immediately comes back up, but parts of the user's homedirectory still give weird ENOENT/EACCES errors until an fs flushv. Jul 7 10:08:36 jdreed-vmware-4 kernel: [ 94.060284] audit_printk_skb: 66 call backs suppressed Jul 7 10:08:36 jdreed-vmware-4 kernel: [ 94.060287] type=1400 audit(1404752916.705:92): apparmor="DENIED" operation="file_perm" profile="/usr/bin/evince" name="/var/cache/openafs/D3/V7476" pid=3192 comm="evince" requested_mask="r" denied_mask="r" fsuid=7263 ouid=0 Jul 7 10:08:36 jdreed-vmware-4 kernel: [ 94.060384] afs: Lost contact with file server 18.9.60.152 in cell athena.mit.edu (code -13) (all multi-homed ip addresses down for the server) Jul 7 10:08:36 jdreed-vmware-4 kernel: [ 94.060385] afs: Lost contact with file server 18.9.60.152 in cell athena.mit.edu (code -13) (all multi-homed ip addresses down for the server) Jul 7 10:08:37 jdreed-vmware-4 kernel: [ 95.064175] afs: failed to store file (network problems) Jul 7 10:08:41 jdreed-vmware-4 kernel: [ 98.855523] afs: file server 18.9.60.152 in cell athena.mit.edu is back up (code 0) (multi-homed address; other same-host interfaces may still be down) Anders notes: OpenAFS should never be accessing /var/cache/openafs with the credentials of a random user process. However, there have been bugs of that form before, and they tend to break SELinux and AppArmor. We should try to file it. So somebody who understands AFS better than me and has free time should look into this and report the bug. This is consistently reproducible on stock Trusty, with login-graphical installed, and the stock upstream apparmor-config (which means uninstall apparmor-config, or use manual-config). |