[Bug 2060695] Re: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk
I think I know what is happening here. In Ubuntu 20.04 and 22.04, the grub-pc.postinst has a chunk of code that was designed to deal with bug #1889556 by skipping running grub-install on package updates. The initial commit comment by Steve Langasek says: debian/postinst.in: Avoid calling grub-install on upgrade of the grub-pc package, since we cannot be certain that it will install to the correct disk and a grub-install failure will render the system unbootable. LP: #1889556 (commit 3aabdc6fe0ab3b6e129fc5b64238c45cbfd0de47 I believe) This code is, in its final form in 22.04: elif dpkg --compare-versions "$2" ge 2.04-1ubuntu26 && [ -z "$DEBCONF_RECONFIGURE" ]; then # Avoid the possibility of breaking grub on SRU update # due to ABI change : 2.04-1ubuntu26 was the initial grub2 version in 20.04. This version was not updated for 22.04 to the 22.04 base version, but the effect was the same (since they were all more recent than the 20.04 base version). If you force a 22.04 machine to explicitly reconfigure grub-pc with 'dpkg- reconfigure grub-pc', it will fail with the same error message as in 24.04 (until you select the real devices). The reason 24.04 fails here is that the 20.04/22.04 change to grub- pc.postinst wasn't carried forward to 24.04, the way it was for 22.04 (in commit 00e473f4e2b2e7e607b3aad58cb0c085b1f0561a I believe), so grub- pc always tries to run grub-install on package updates and fails here. I don't know if this is a grub-pc 24.04 problem by itself. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060695 Title: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/2060695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060695] Re: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk
I didn't change grub-pc/install-devices, and on our 22.04 BIOS MBR + mirrored software RAID servers (of which we have a lot), it has the same value (or the same sort of value, naming the md device). A random 22.04 server install is also using 'super 1.2' for its root /dev/md0 device superblock format, which will have come from the installer since we don't change or customize that. We have some remaining 20.04 LTS servers as well with this same mirrored software RAID root and they are also superblock 1.2 format and the same grub-pc/install_devices setting. I think it has been this way in Ubuntu server installs for a long time (for BIOS MBR, UEFI is slightly different in that it also sets grub- efi/install_devices to the UEFI partitions on the boot disks). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060695 Title: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/2060695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060695] Re: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk
Both 'dpkg-reconfigure grub-pc' then selecting the /dev/vd* disks and manually running 'grub-install /dev/vda' (and then /dev/vdb) do work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060695 Title: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2060695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060695] Re: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk
Also, here's sgdisk output (the two disks have identical output apart from names): isk /dev/vda: 83886080 sectors, 40.0 GiB Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 08D25DA2-9B12-45EA-B7EE-0978D2780899 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 83886046 Partitions will be aligned on 2048-sector boundaries Total free space is 4029 sectors (2.0 MiB) Number Start (sector)End (sector) Size Code Name 120484095 1024.0 KiB EF02 2409683884031 40.0 GiB8300 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060695 Title: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2060695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060695] Re: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk
The RAID is on partitions, but there is no LVM involved. The layout was set up through the 24.04 server installer with custom storage layout, selecting both disks as boot disks, and then using all of their space as a single partition for the software RAID. The software RAID itself is unpartitioned. /proc/mdstat: md0 : active raid1 vdb2[1] vda2[0] 41906176 blocks super 1.2 [2/2] [UU] /proc/partitions: 2530 41943040 vda 2531 1024 vda1 2532 41939968 vda2 253 16 41943040 vdb 253 17 1024 vdb1 253 18 41939968 vdb2 90 41906176 md0 /proc/self/mounts of the root filesystem: /dev/md0 / ext4 rw,relatime 0 0 I get this test VM into a state with a post-install grub2 update because I typically work by going through the server installer once, snapshotting the result, and then working from the snapshot to test our post-install actions, which involve updating all packages. This grub-pc problem has happened before several times and previously I've made it go away by rebuilding the initial install using the current daily server ISO. This time I'm reporting a bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060695 Title: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2060695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060695] [NEW] 24.04 grub-pc cannot upgrade on mirrored software RAID root disk
Public bug reported: I am testing the 24.04 pre-beta in a libvirt virtual machine with two /dev/vd* disks set up as a single mirrored software RAID device, /dev/md0, that is used for the root filesystem. Since this is a libvirt install, it is using BIOS booting, not UEFI (maybe someday libvirt will support snapshots of UEFI based VMs). When I attempt to install Ubuntu updates, the grub-pc install fails with: grub-pc: Running grub-install ... Installing for i386-pc platform. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. grub-install: error: diskfilter writes are not supported. grub-install failure for /dev/md0 You must correct your GRUB install devices before proceeding: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1 'debconf-show' reports (changed) settings as: * grub-efi/cloud_style_installation: false * grub-pc/install_devices: /dev/disk/by-id/md-name-ubuntu-server:0 * grub-pc/install_devices_empty: false The same mirrored root filesystem configuration works on 22.04 LTS. ** 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/2060695 Title: 24.04 grub-pc cannot upgrade on mirrored software RAID root disk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2060695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1969625] Re: ERROR: Could not resolve symbol: /proc/self/exec:BEGIN_trigger
It appears that you can work around this by installing the bpftrace debugging symbols. After following the general directions of https://wiki.ubuntu.com/Debug%20Symbol%20Packages I installed bpftrace- dbgsym and now bpftrace appears 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/1969625 Title: ERROR: Could not resolve symbol: /proc/self/exec:BEGIN_trigger To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bpftrace/+bug/1969625/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1969625] Re: ERROR: Could not resolve symbol: /proc/self/exec:BEGIN_trigger
This is apparently because the bpftrace binary is stripped. An issue reporting a similar problem in the upstream is https://github.com/iovisor/bpftrace/issues/954 ** Bug watch added: github.com/iovisor/bpftrace/issues #954 https://github.com/iovisor/bpftrace/issues/954 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1969625 Title: ERROR: Could not resolve symbol: /proc/self/exec:BEGIN_trigger To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bpftrace/+bug/1969625/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1788004] Re: File System inaccessible after 18.04 upgrade
Based on inspecting the ZFS source code, this looks like a ZFS inode where there is a mismatch between the claimed size of the inode's (ZFS) ACL and how it's stored. If you're willing to do some work, it might be possible to narrow this down to identify a specific inode and what's wrong with it, which could help fixing this (in Ubuntu and upstream). Unfortunately this will be a somewhat involved process involving zdb, because you need to dump on-disk structures. If you're interested and willing to tackle this, your best approach is probably to ask for help on the ZFS on Linux mailing list, because it will be easier to give the details there. It is possible that a 'zfs send | zfs receive' sequence will allow you to recover a usable version of the filesystem (and I believe you can do this without the filesystem being mounted and thus without the risk of panic). If you have, say, a spare external USB drive, it might be worth trying this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1788004 Title: File System inaccessible after 18.04 upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1788004/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1785268] [NEW] In 18.04, amrecover doesn't work unless amanda-server package is installed
Public bug reported:
If you have an Ubuntu 18.04 Amanda client machine, you have probably
only installed the amanda-client package (and then amanda-common, which
it depends on). If you try to run 'amrecover' on such a machine, you
will get a failure:
# amrecover -s -t -C
AMRECOVER Version 3.5.1. Contacting server on ...
[request failed: amrecover: error [exec /usr/lib/amanda/ambind: No such file or
directory]]
This happens because the ambind program is packaged in the amanda-server
package, which is not installed by default when you install amanda-
client. The current Debian testing packages for Amanda also appear to
have this issue, so Ubuntu's packages may have inherited it from
upstream.
The Amanda package version is '1:3.5.1-1build2'. This is on Ubuntu 18.04
('bionic'); amrecover works fine in 16.04, but then 16.04 has Amanda
3.3.6, which is before Amanda introduced the ambind program.
(My apologies for an initial incomplete submission of this report;
bugs.launchpad.net decided to submit it when I was adding tags.)
** Affects: amanda (Ubuntu)
Importance: Undecided
Status: New
** Tags: bionic
** Description changed:
- If you have an Amanda client machine, you have probably only installed
- the amanda-client package (and then amanda-common, which it depends on).
- If you try to run 'amrecover' on such a machine, you will get a failure:
+ If you have an Ubuntu 18.04 Amanda client machine, you have probably
+ only installed the amanda-client package (and then amanda-common, which
+ it depends on). If you try to run 'amrecover' on such a machine, you
+ will get a failure:
# amrecover -s -t -C
AMRECOVER Version 3.5.1. Contacting server on ...
[request failed: amrecover: error [exec /usr/lib/amanda/ambind: No such file
or directory]]
+
+ This happens because the ambind program is packaged in the amanda-server
+ package, which is not installed by default when you install amanda-
+ client. The current Debian testing packages for Amanda also appear to
+ have this issue, so Ubuntu's packages may have inherited it from
+ upstream.
+
+ The Amanda package version is '1:3.5.1-1build2'. This is on Ubuntu 18.04
+ ('bionic'); amrecover works fine in 16.04, but then 16.04 has Amanda
+ 3.3.6, which is before Amanda introduced the ambind program.
+
+ (My apologies for an initial incomplete submission of this report;
+ bugs.launchpad.net decided to submit it when I was adding tags.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1785268
Title:
In 18.04, amrecover doesn't work unless amanda-server package is
installed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/amanda/+bug/1785268/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611945] Re: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks
Thanks for your encouragement. I've now filed this as an issue with upstream systemd as https://github.com/systemd/systemd/issues/3943 . ** Bug watch added: github.com/systemd/systemd/issues #3943 https://github.com/systemd/systemd/issues/3943 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1611945 Title: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611945] Re: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks
I've confirmed this behavior on the yakkety live build you linked to above, with systemd 231 according to its dpkg output. I gathered as much data about it as I could think of (and I can go back for more if necessary). Would you rather I pass the data to you here for you to file an upstream bug with, or should I go file one directly against upstream? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1611945 Title: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611945] Re: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks
In 16.04 (and I think everywhere), /sys is sysfs, so its contents are generated by the kernel, device drivers, and so on. Udev looks at sysfs in order to determine device information (eg ATA port number) that it uses to create everything else. How hardware is represented in sysfs can change over kernel versions, as we see here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1611945 Title: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611945] Re: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks
Here is the full 'udevadm test' output for two disks on the same port
multiplier channel. I can do a disk on a different channel as well if
you want.
On 12.04, the sysfs path of the same disk slot is
/sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/host8/target8:0:0/8:0:0:0/block/sdk
(the sdN numbering is inconsistent from boot to boot, which is why we
want /dev/disk/by-path names for all of them). We don't have any 14.04
hosts with a port multiplier, so I don't know when the kernel started
putting the hostN directory in the /ataN/ directory and thus triggering
udev's special ATA disk handling.
('udevadm test /sys/class/block/sdk' on the 12.04 machine says that udev
sees this as an ATA and SATA disk; ID_ATA and ID_ATA_SATA are both 1 and
ID_BUS is ata. But it winds up with
ID_PATH=pci-:02:00.0-scsi-2:0:0:0, instead of an ata variant.)
I agree with your analysis that this is affects systemd HEAD. As far as
I can see HEAD has nothing in handle_scsi_ata() that would give
different names to multiple disks behind the same ATA port. Sadly we
have no systems that are running a recent enough systemd that I can
report it to them, based on their reporting policies. Is there a
bootable live CD of the in-progress next Ubuntu versions? That might
have a recent enough systemd that I could boot it on the system in
question, verify that its systemd isn't generating the right /dev/disk
/by-path results, and report it upstream.
** Attachment added: "full-out"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+attachment/4719114/+files/full-out
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1611945
Title:
/dev/disk/by-path not properly populated for (e)SATA port multiplier
disks
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611945] [NEW] /dev/disk/by-path not properly populated for (e)SATA port multiplier disks
Public bug reported: We have a just-installed Ubuntu 16.04 LTS machine with a number of disks behind port-multiplier eSATA ports, all of them driven by a SiI 3124 controller (sata_sil24 kernel driver). Our machine sees all disks on all channels, however under 16.04 only one disk from each channel shows up in /dev/disk/by-path/ (all disks show up in /dev/disk/by-id and /dev/disk/by-uuid). For our usage this is a severe defect because we rotate disks in and out of the external enclosure and rely on mounting specific slots in the external enclosure through /dev/disk/by-path. This did not happen in Ubuntu 12.04 LTS, the release that this machine was previously running. According to 'udevadm info --export-db' and 'udevadm test-builtin path_id' and so on, systemd's udev stuff is assigning all drives behind the same port the same disk/by-path data (ID_PATH et al). In 'udevadm info /sys/block/sdX', the 'P:' and 'E: DEVPATH=' values show a difference in the target portion of PCI path, eg: P: /devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:0:0/0:0:0:0/block/sda P: /devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:1:0/0:1:0:0/block/sdb However the 'S: disk/by-path', 'E: DEVLINKS=', and 'E: ID_PATH' portions do not. For both devices above, we see: S: disk/by-path/pci-:02:00.0-ata-1 E: ID_PATH=pci-:02:00.0-ata-1 Naturally only one device can have a /dev/disk/by- path/pci-:02:00.0-ata-1 symlink, so instead of four disks per channel in /dev/disk/by-path we see one. Ubuntu release: 16.04 Package versions from 'apt-cache policy udev systemd': udev: Installed: 229-4ubuntu7 systemd: Installed: 229-4ubuntu7 'journalctl -b' reports that during boot systemd does report some 'appeared twice with different sysfs paths' notes, eg: Aug 10 13:34:21 verdandi systemd[1]: dev-disk-by\x2dpath- pci\x2d:02:00.0\x2data\x2d1\x2dpart1.device: Dev dev-disk-by \x2dpath-pci\x2d:02:00.0\x2data\x2d1\x2dpart1.device appeared twice with different sysfs paths /sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:3:0/0:3:0:0/block/sdd/sdd1 and /sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 However it doesn't seem to be reporting this for all port-multiplier drives and their partitions. If it would be useful I can attach full 'udevadm info --export-db' output or the like. ** Affects: systemd (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/1611945 Title: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1605687] Re: package mysql-server-5.7 5.7.13-0ubuntu0.16.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
When this happened to us during a mysql-server upgrade, the root cause is that we had mysql (the server) disabled, ie 'systemctl disable mysql'. When you do this, 'invoke-rc.d mysql start' winds up doing nothing and not starting the server, which causes mysql_upgrade to fail because it requires a running server. Explicitly starting mysql before you do the upgrade doesn't help, because the mysql-server-5.7 postinst script starts out by shutting it down. What does work around the issue is re-enabling mysql beforehand: 'systemctl enable mysql', do the upgrade, then 'systemctl disable mysql; systemctl stop mysql'. (Invoke-rc.d does not directly ask systemd for the status of mysql. Instead it looks at /etc/rc5.d/ S* and K* symlinks, which systemctl manipulates for systemd services that also have an /etc/init.d script, which mysql does. Finding this takes tracing through a lot of layers.) A correct bugfix for our issue would be for the mysql-server postinst script to unconditionally start mysql using eg 'service mysql start', instead of relying on invoke-rc.d. The ideal sequence would be to explicitly start mysql, run mysql_upgrade, shut mysql down, and then run 'invoke-rc.d mysql start' to restart it only if it's been enabled. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1605687 Title: package mysql-server-5.7 5.7.13-0ubuntu0.16.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1605687/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 790538] Re: pam update causes cron to stop working with Module is unknown error
Not all aspects of this PAM failure can be fixed easily, since daemons other than cron were also affected. Cron can be restarted without user impact, but something like xdm cannot be. (Since we got hurt by the xdm issue, not by the cron issue, I am rather sensitive about this.) I personally think that we were quite lucky that the Ubuntu sshd was not affected by this, although it uses PAM. (I am not sure why it was unaffected, since sshd has libpam loaded and requires pam_env.so in a normal Ubuntu config.) I also hope that Ubuntu will conduct a real root cause analysis on this. 'Cron locked up after a PAM upgrade' is only the surface problem and addressing and detecting just it would be only addressing the most obvious symptom of the real problem. The real problem was 'a PAM update was not ABI compatible'; the broken processes were simply a symptom of this. I would like Ubuntu to change things so that they detect this if it happens again, not merely instances of the root cause where cron helpfully locks up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/790538 Title: pam update causes cron to stop working with Module is unknown error -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 790538] Re: pam update causes cron to stop working with Module is unknown error
This PAM issue also affects xdm, which no longer allows people to log in (it syslogs the same error message). This has caused us serious problems on our multiuser login servers, because of course we cannot simply reboot the machines and restarting xdm has the pleasant side effect of instantly logging off all xdm-based users. It has probably broken other daemons as well, some of them depending on details of their configuration. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/790538 Title: pam update causes cron to stop working with Module is unknown error -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 790538] Re: pam update causes cron to stop working with Module is unknown error
@Marc: the previous libpam version (1.1.1-2ubuntu5 for 10.04 LTS) doesn't seem to be available any more, or at least 'apt-get' can't find it, which makes downgrading hard. We would have to roll all the way back to 1.1.1-2ubuntu2 ... which is missing a root escalation CVE (CVE-2010-0832, root priv escalation via symlink following). This is not something we are in a position to do on multiuser systems. (Nor is it in /var/cache/apt/archives on our machines.) I am trying 'apt-get -u install libpam-modules=1.1.1-2ubuntu5'. Possibly this is the wrong thing. ** CVE added: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2010-0832 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/790538 Title: pam update causes cron to stop working with Module is unknown error -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 790538] Re: pam update causes cron to stop working with Module is unknown error
We have an Ubuntu 10.04 machine with the original update applied where xdm had not been restarted and was thus rejecting login attempts. I can confirm that applying the just-released PAM update made xdm accept logins again. The update also did not break cron, which had been restarted and so was using all of the updated PAM stuff. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/790538 Title: pam update causes cron to stop working with Module is unknown error -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 787755] [NEW] Samba does not notice added or removed CUPS printers
Public bug reported:
Binary package hint: samba
Our environment uses a CUPS server that is separate from the machine
running Samba; the Samba machine has an /etc/cups/client.conf with
the ServerName of the CUPS server. In this setting, Samba does not
notice when you add or remove a CUPS printer, although 'lpstat -v'
and so on on the machine running Samba will show the changed printer
list. Reloading Samba (smbd) does not change this situation; only
restarting smbd makes Samba update the printer list.
It is possible that this bug also happens if the CUPS server is
running on the same machine as the Samba server, but I have not
tested that.
Ubuntu release: Ubuntu 10.04 LTS 32-bit x86, with all current updates.
Samba version: 2:3.4.7~dfsg-1ubuntu3.6
CUPS version: 1.4.3-1ubuntu1.3
(This probably reproduces on all architectures, but I haven't tested.)
How to reproduce:
- configure a CUPS server machine and set up a printer.
- install a stock Ubuntu 10.04 machine. Create an /etc/cups/client.conf
on it that has 'ServerName IP-of-CUPS-server'. Verify that Unix
printing works.
- Install Samba: 'apt-get install samba smbclient'
- edit /etc/samba/smb.conf to add 'printcap cache time = 10' to the
'[ global ]' section. Restart Samba.
- Use 'smbclient -L localhost' to verify that you see the printer from
your CUPS server.
- add a printer to your CUPS server. Wait 30 seconds and run
'smbclient -L localhost' again, and see that it does not show the new
printer. 'lpstat -v' and printing to it from Unix will work, though.
- optionally, 'reload smbd' and repeat the 'smbclient -L localhost' to
demonstrate that the reload did not change the situation.
- 'service smbd restart', repeat 'smbclient -L localhost', and the new
printer is now present.
- delete the printer on the CUPS server, and rerun 'smbclient -L localhost';
Samba still lists the printer.
(The convenient way to add a new printer is just to add a new name for
your existing printer, duplicating destination settings and so on.)
What I expected to happen: 'smbclient -L localhost' lists the new
printer when it is added and does not list it when it is removed.
This behavior is a regression from Ubuntu 8.04 (samba version
3.0.28a-1ubuntu4.14). I have not tested intermediate non-LTS
releases to determine where the problem first appears.
Since your Samba bug reporting page specifically asks for this
information:
$ dpkg-query -W -f='${Package} ${Version} ${Source} ${Status}\n' | grep samba
libsmbclient 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
libwbclient0 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
samba 2:3.4.7~dfsg-1ubuntu3.5 install ok installed
samba-common 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
samba-common-bin 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
smbclient 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
The Samba log files in /var/log/samba contain no information; log.smbd
and log.nmbd have only startup notices, and the log.client file is
empty (0 length). I can include them if you really need them.
I'm attaching 'smbclient -L' output, and also /etc/samba/smb.conf
and 'testparm -s' output, although the latter two will probably be
mostly pointless (since I've given instructions on how to construct
the smb.conf above).
** Affects: samba (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/787755
Title:
Samba does not notice added or removed CUPS printers
--
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 787755] Re: Samba does not notice added or removed CUPS printers
** Attachment added: smbclient -L output https://bugs.launchpad.net/bugs/787755/+attachment/2141346/+files/cksvm-smbclient -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/787755 Title: Samba does not notice added or removed CUPS printers -- 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 787755] Re: Samba does not notice added or removed CUPS printers
(this is the smb.conf constructed as described in the reproduction section) ** Attachment added: /etc/samba/smb.conf https://bugs.launchpad.net/ubuntu/+source/samba/+bug/787755/+attachment/2141365/+files/smb.conf -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/787755 Title: Samba does not notice added or removed CUPS printers -- 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 787755] Re: Samba does not notice added or removed CUPS printers
** Attachment added: testparm -s output https://bugs.launchpad.net/ubuntu/+source/samba/+bug/787755/+attachment/2141366/+files/testparm-s -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/787755 Title: Samba does not notice added or removed CUPS printers -- 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 787755] [NEW] Samba does not notice added or removed CUPS printers
Public bug reported:
Binary package hint: samba
Our environment uses a CUPS server that is separate from the machine
running Samba; the Samba machine has an /etc/cups/client.conf with
the ServerName of the CUPS server. In this setting, Samba does not
notice when you add or remove a CUPS printer, although 'lpstat -v'
and so on on the machine running Samba will show the changed printer
list. Reloading Samba (smbd) does not change this situation; only
restarting smbd makes Samba update the printer list.
It is possible that this bug also happens if the CUPS server is
running on the same machine as the Samba server, but I have not
tested that.
Ubuntu release: Ubuntu 10.04 LTS 32-bit x86, with all current updates.
Samba version: 2:3.4.7~dfsg-1ubuntu3.6
CUPS version: 1.4.3-1ubuntu1.3
(This probably reproduces on all architectures, but I haven't tested.)
How to reproduce:
- configure a CUPS server machine and set up a printer.
- install a stock Ubuntu 10.04 machine. Create an /etc/cups/client.conf
on it that has 'ServerName IP-of-CUPS-server'. Verify that Unix
printing works.
- Install Samba: 'apt-get install samba smbclient'
- edit /etc/samba/smb.conf to add 'printcap cache time = 10' to the
'[ global ]' section. Restart Samba.
- Use 'smbclient -L localhost' to verify that you see the printer from
your CUPS server.
- add a printer to your CUPS server. Wait 30 seconds and run
'smbclient -L localhost' again, and see that it does not show the new
printer. 'lpstat -v' and printing to it from Unix will work, though.
- optionally, 'reload smbd' and repeat the 'smbclient -L localhost' to
demonstrate that the reload did not change the situation.
- 'service smbd restart', repeat 'smbclient -L localhost', and the new
printer is now present.
- delete the printer on the CUPS server, and rerun 'smbclient -L localhost';
Samba still lists the printer.
(The convenient way to add a new printer is just to add a new name for
your existing printer, duplicating destination settings and so on.)
What I expected to happen: 'smbclient -L localhost' lists the new
printer when it is added and does not list it when it is removed.
This behavior is a regression from Ubuntu 8.04 (samba version
3.0.28a-1ubuntu4.14). I have not tested intermediate non-LTS
releases to determine where the problem first appears.
Since your Samba bug reporting page specifically asks for this
information:
$ dpkg-query -W -f='${Package} ${Version} ${Source} ${Status}\n' | grep samba
libsmbclient 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
libwbclient0 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
samba 2:3.4.7~dfsg-1ubuntu3.5 install ok installed
samba-common 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
samba-common-bin 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
smbclient 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
The Samba log files in /var/log/samba contain no information; log.smbd
and log.nmbd have only startup notices, and the log.client file is
empty (0 length). I can include them if you really need them.
I'm attaching 'smbclient -L' output, and also /etc/samba/smb.conf
and 'testparm -s' output, although the latter two will probably be
mostly pointless (since I've given instructions on how to construct
the smb.conf above).
** Affects: samba (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/787755
Title:
Samba does not notice added or removed CUPS printers
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 787755] Re: Samba does not notice added or removed CUPS printers
** Attachment added: smbclient -L output https://bugs.launchpad.net/bugs/787755/+attachment/2141346/+files/cksvm-smbclient -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/787755 Title: Samba does not notice added or removed CUPS printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 787755] Re: Samba does not notice added or removed CUPS printers
(this is the smb.conf constructed as described in the reproduction section) ** Attachment added: /etc/samba/smb.conf https://bugs.launchpad.net/ubuntu/+source/samba/+bug/787755/+attachment/2141365/+files/smb.conf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/787755 Title: Samba does not notice added or removed CUPS printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 787755] Re: Samba does not notice added or removed CUPS printers
** Attachment added: testparm -s output https://bugs.launchpad.net/ubuntu/+source/samba/+bug/787755/+attachment/2141366/+files/testparm-s -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/787755 Title: Samba does not notice added or removed CUPS printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 543617] Re: Unmount of an fs with dirty cache buffers causes pathological slowdown
I can report that the proposed kernel resolves what is either this issue or a closely related issue. On our Ubuntu 10.04 machines, unmounting an NFS filesystem takes a significant amount of time, on the order of several seconds to tens of seconds; my test machine runs between 15 seconds and 25 seconds per filesystem. This happens even with a 'sync' run immediately before the unmount. (This happens on both 2.6.32-24-generic-pae i686 and 2.6.32-24-server x86_64. One unpleasant consequence is that shutting down a machine takes a very long time, as we have more than 200 NFS mounts and the shutdown scripts do the unmounts serially.) The proposed kernel solves the problem on at least x86_64; unmounting a NFS filesystem is almost instant (time says 0.16 seconds real) and the machine shuts down or reboots immediately when requested. -- Unmount of an fs with dirty cache buffers causes pathological slowdown https://bugs.launchpad.net/bugs/543617 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 407459] Re: Procmail opens $HOME/.procmailrc before dropping setuid permissions
** Changed in: procmail (Ubuntu) Status: Invalid = New -- Procmail opens $HOME/.procmailrc before dropping setuid permissions https://bugs.launchpad.net/bugs/407459 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 407459] Re: Procmail opens $HOME/.procmailrc before dropping setuid permissions
Even if procmail closes and reopens the file later as non-root, there are still two problems here. First, procmail has opened (and closed) a file with root permissions. There are 'files' where merely opening (and closing) them have side effects; for example, pointing $HOME/.procmailrc at a rewindable tape device, where an open/close will cause the tape to rewind. I believe that this is a security issue. Second, manifestly the attempts to work around NFS issues don't work. If you run procmail with it setuid root, your users have home directories on NFS, and your users don't make their homedir and their .procmailrc readable to the world, procmail's attempt to open their .procmailrc as root will fail with EACCESS and it will *not* retry as non-root. This is a plain bug; we have seen it here (since 8.04 installs procmail as setuid root). (I cannot follow the twisting maze of dense procmail code to see why it is going wrong, but it clearly is; we have the mis-delivered mail and the strace/SystemTap traces to show it.) -- Procmail opens $HOME/.procmailrc before dropping setuid permissions https://bugs.launchpad.net/bugs/407459 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 406957] Re: lighttpd makes /usr/share/doc visible to everyone
Whoops, I effectively got the version number and Ubuntu release
wrong, because I missed that we are still using a Dapper-derived
lighttpd.conf on our Hardy machines. (My apologies for the
confusion; I should have checked to be sure.)
The dapper lighttpd.conf says:
$HTTP[host] == localhost {
global {
alias.url += (
/doc/ = /usr/share/doc/,
/images/ = /usr/share/images/
)
}
dir-listing.activate = enable
}
This is from the current lighttpd_1.4.11-3ubuntu3.8_i386.deb
package for dapper (6.06 LTS).
Arguably this is still not a bug because the config file also
binds lighttpd only to localhost. But it doesn't match the
comment, and it's dangerous if you change that to
let lighttpd talk to the world without knowing that you need
to change other things in the configuration.
--
lighttpd makes /usr/share/doc visible to everyone
https://bugs.launchpad.net/bugs/406957
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 406957] [NEW] lighttpd makes /usr/share/doc visible to everyone
Public bug reported:
Binary package hint: lighttpd
Ubuntu release: hardy (8.04)
Version: 1.4.19-0ubuntu3.1
The normal Ubuntu lighttpd configuration file exposes /usr/share/doc to
everyone who can talk to your web server, as the /doc/ URL, not just
people on the same machine
The lighttpd configuration file claims:
handle Debian Policy Manual, Section 11.5. urls
and by default allow them only from localhost
and then sets up aliases for /usr/share/doc and
/usr/share/images. However, contrary to the comment
in the file, it does not restrict them to requests from
localhost, as you can easily verify, because it puts
the 'alias.url +=' directive inside a 'global' section.
Removing the 'global { ... }' around the alias directive
fixes the problem; /doc/ and /images/ remain accessible
from localhost but stop being accessible from the outside
world.
(I don't know if this should be considered a security bug,
so I'm opting to not mark it as such.)
** Affects: lighttpd (Ubuntu)
Importance: Undecided
Status: New
--
lighttpd makes /usr/share/doc visible to everyone
https://bugs.launchpad.net/bugs/406957
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
