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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
@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
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
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,
** 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
(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
** 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.
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,
** 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
(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,
** 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
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
** 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
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
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 {
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
33 matches
Mail list logo
