[Bug 2056697] Re: Ubuntu Studio should prefer realtime kernel
OK, fine, all valid points. I'm not so sure about the "placebo effect", though. I played the same piece a dozen times on my MIDI keyboard in various configurations, with the following results: realtime alsa: xruns 0, 0, 0 realtime jack: xruns 11, 0, 0 lowlatency jack: xruns 25, 5, 5, 6, 8 Admittedly, it was a small test, but I made some effort to actually test it and concluded that I was getting better performance from the realtime kernel. I think some more investigation is required. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056697 Title: Ubuntu Studio should prefer realtime kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/2056697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2056697] Re: Ubuntu Studio should prefer realtime kernel
I'm not suggesting that Ubuntu Studio should ship with the realtime kernel as of yet. I'm suggesting that after "pro enable realtime-kernel", it should be at the top of the boot priority. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056697 Title: Ubuntu Studio should prefer realtime kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/2056697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2056697] [NEW] Ubuntu Studio should prefer realtime kernel
Public bug reported: Now that Ubuntu has released a realtime kernel, I suggest that Ubuntu Studio's boot preference should be: 1. realtime 2. lowlatency 3. default I've been running the realtime kernel for a week, haven't had any problems with it, and am seeing noticeably fewer xruns in Ardour. ** Affects: os-prober (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/2056697 Title: Ubuntu Studio should prefer realtime kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/2056697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974100] Re: qemu ide/sata disks do not work well with discard/trim
@Christian, I haven't tried all of your combinations, but when I mount a second disk using the growpart/e2fsck/resize2fs sequence that you suggest and then mount it, it grows to 725 MB and then zerofree reports what you observed: baccala@osito:~/NPDC/GNS3/bug$ sudo zerofree -v /dev/nbd0p1 3/5963617/6525179 But when I use an identical disk as the root filesystem, it grows to 789 MB and then zerofree reports this: baccala@osito:~/NPDC/GNS3/bug$ sudo zerofree -v /dev/nbd0p1 1524/5953550/6525179 Both virtual disks are ubuntu 20.04 cloudimgs extended to 25 GB. I used the procedure I described on May 20 (cloudinit.iso on a virtual CD-ROM) with the one disk as root and the other one as /dev/sdb. Both were identical when I booted the VM. You mentioned that "all tools that make it easy for me to deploy one also pick virtio by default"; can you run qemu from the command line on a bare metal system? If so, I thought my May 20 procedure was pretty simple. If not, then I guess it's harder to verify this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1974100 Title: qemu ide/sata disks do not work well with discard/trim To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1974100/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1975744] Re: purging cloud-init doesn't remove its network configuration files
I like the idea of working this into cloud-init clean. My use case is that I use cloud-init to initially configure an instance that will later be manually configured, so I don't want files lying around that say things like "if you edit this file it will be overwritten on the next boot" (I forget the exact wording) when that's not the case. On Wed, Jun 1, 2022 at 7:50 PM Chad Smith <1975...@bugs.launchpad.net> wrote: > Thanks for the bug and triage folks. > > While this is confirmed/known behavior, I don't think cloud-init should > be automatically removing core configuration files that are not packaged > by cloud-init's deb package especially if removal of those config files > can have catastrophic consequences on the ability to connect to the > system. If the networking service happens to be restarted outside of > the perview of the admin purging the cloud-init package it would be very > surprising for the unsuspecting admin to see the system drop. > > Also we are aware of use-cases where folks may expect to use cloud-init > once, and have attempted to remove cloud-init deb package after initial > system configuration is correctly performed to ensure cloud-init no > longer acts to reconfigure the system in the future. > > While this use-case above is probably less desirable that just disabling > cloud-init via `sudo touch /etc/cloud/cloud-init.disabled` it does allow > image creators to reduce the overall size of their image if they are > trying to generate customized images with cloud-init and remove cloud- > init and any other dependencies on which cloud-init relies. > > > I'd prefer we avoid addressing this in packaging specifically, though we > could grow this functionality in cloud-init clean to clean up network > config artifacts generated by cloud-init. This would at least make it > easier for your use-case of cleaning up all network config files that > cloud-init generated on a system. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1975744 > > Title: > purging cloud-init doesn't remove its network configuration files > > Status in cloud-init package in Ubuntu: > Confirmed > > Bug description: > cloud-init creates /etc/netplan/50-cloud-init.yaml during its network > configuration step. > > However, "apt purge cloud-init" leaves this file intact. > > I've seen this behavior on Ubuntu 18, 20, and 22. > > I can always remove the file manually, but I'm left wondering what > other files cloud-init might have left lingering around on the system. > > Shouldn't a purge remove all files associated with a package? > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1975744/+subscriptions > > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1975744 Title: purging cloud-init doesn't remove its network configuration files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1975744/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1455967] Re: NM disables accept_ra for an IPv6 connection, where it should enable it!
I'm still seeing this behavior on Ubuntu 20.04.4 LTS -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1455967 Title: NM disables accept_ra for an IPv6 connection, where it should enable it! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1455967/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1975744] Re: purging cloud-init doesn't remove its network configuration files
It also seems to leave build.info in /etc/cloud and doesn't remove that directory for that reason. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1975744 Title: purging cloud-init doesn't remove its network configuration files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1975744/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1975744] [NEW] purging cloud-init doesn't remove its network configuration files
Public bug reported: cloud-init creates /etc/netplan/50-cloud-init.yaml during its network configuration step. However, "apt purge cloud-init" leaves this file intact. I've seen this behavior on Ubuntu 18, 20, and 22. I can always remove the file manually, but I'm left wondering what other files cloud-init might have left lingering around on the system. Shouldn't a purge remove all files associated with a package? ** Affects: cloud-init (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/1975744 Title: purging cloud-init doesn't remove its network configuration files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1975744/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974100] Re: qemu ide/sata disks do not work well with discard/trim
@Christian - my lsblk output looks very similar to yours. In particular, all device types are reporting discard support; the only difference is the reported discard sizes. I would suggest that at the end of your tests you check the disk with "debugfs -R dump_unused". I'm seeing disk blocks filled with garbage. I expected them to be filled with zeros. So, I don't think it's just a feature request. Not only has the device announced discard support, but when you read the blocks back they are not zero filled. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1974100 Title: qemu ide/sata disks do not work well with discard/trim To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1974100/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974100] Re: inode lazy init in a VM fills virtual disk with garbage
Incidentally, I was able to fix my immediate problem by switching the disk type to scsi, based on the suggestions given by Christian Ehrhardt. It's still an open bug that could cause other people some grief. It sure caused me plenty. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1974100 Title: inode lazy init in a VM fills virtual disk with garbage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1974100/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974100] Re: inode lazy init in a VM fills virtual disk with garbage
I've come up with a more minimal test that doesn't require the whole
GNS3 infrastructure.
1. Create a one-line 'meta-data' file:
{instance-id: ubuntu, local-hostname: ubuntu}
2. Create the following 'user-data' file:
#cloud-config
hostname: ubuntu
network:
config: disabled
resize_rootfs: noblock
users:
- name: ubuntu
plain_text_passwd: foobar
lock_passwd: false
shell: /bin/bash
sudo: ALL=(ALL) NOPASSWD:ALL
3. Build a CIDATA image acceptable to cloud-init:
genisoimage -input-charset utf-8 -o cloudinit.iso -l -relaxed-filenames
-V cidata -graft-points meta-data user-data
4. With a copy of Ubuntu's cloudimg in the current directory, create a 1
TB thin provisioned disk:
qemu-img create -f qcow2 -b ubuntu-20.04-server-cloudimg-amd64.img
test.qcow2 1T
5. Start qemu with a VNC server on whatever port you'd like (you must be
in group kvm):
qemu-system-x86_64 -enable-kvm -cdrom cloudinit.iso -drive
file=test.qcow2,if=ide,media=disk,discard=on -m 4G -vnc 0.0.0.0:88 -net
none
I can change ide to virtio, but if I change it to scsi it either hangs
during boot (Ubuntu 18 host) or complains "machine type does not support
if=scsi,bus=0,unit=0" (Ubuntu 20 host).
I can do the following to get scsi:
qemu-system-x86_64 -enable-kvm -cdrom cloudinit.iso -device virtio-scsi-
pci,id=scsi -drive file=test.qcow2,id=root-img,if=none,discard=on
-device scsi-hd,drive=root-img -m 4G -vnc 0.0.0.0:88 -net none
For any drive type, you start it running, let it sit there at a boot
prompt, and watch the size of test.qcow2. The bad behavior is that it
grows into the 30-40 GB range.
On a Ubuntu 18 host, I see the bad behavior for drive types ide and
virtio. scsi seems to be OK.
On an Ubuntu 20 host, I only see the bad behavior for drive type ide.
virtio and scsi seem OK.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1974100
Title:
inode lazy init in a VM fills virtual disk with garbage
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1974100/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974100] Re: inode lazy init in a VM fills virtual disk with garbage
best guess as to the package ** Package changed: ubuntu => qemu (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1974100 Title: inode lazy init in a VM fills virtual disk with garbage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1974100/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974100] [NEW] inode lazy init in a VM fills virtual disk with garbage
Public bug reported: I encountered this problem using this script to create a GNS3 appliance: https://github.com/BrentBaccala/NPDC/blob/master/GNS3/ubuntu.py I'm running a stock gns3-server on Ubuntu 18. I called it like this: ./ubuntu.py -r 20 -s $((1024*1024)) --vnc --boot-script opendesktop.sh This uses the Ubuntu 20 server cloudimg to create a new GNS3 appliance with a thin provisioned disk resized to 1024*1024 MB = 1 TB. Although the disk holds less than 5 GB of data once the installation scripts finishes, the qcow2 disk file balloons to over 35 GB, and watching the processes running in the virtual machine shows that the culprit is "ext4lazyinit". I posted a question about this at https://unix.stackexchange.com/questions/700050 Shutting down the instance, mounting the disk using qemu-nbd, and running "debugfs -R dump_unused" on the first partition shows all kind of junk in the unused blocks. Running "zerofree" on the partition shows hundreds of thousands of blocks being zeroed Then using "qemu-img convert -O qcow2" to copy the disk image to another qcow2 file and discard zero blocks reduces its size to 4.3 GB. I tried modifying gns3 to set discard=on option on the qemu command line; this seems to have no effect. Here's an actual qemu command line (called from gns3): /usr/bin/qemu-system-x86_64 -name ubuntu -m 4096M -smp cpus=1,sockets=1 -enable-kvm -machine smm=off -boot order=c -cdrom /home/gns3/GNS3/projects/29706745-5a53-44bf-9313-c8e78089c2f5/29706745-5a53-44bf-9313-c8e78089c2f5_ubuntu.iso -drive file=/home/gns3/GNS3/projects/29706745-5a53-44bf-9313-c8e78089c2f5/project- files/qemu/1deb3b2f-421e-460b-91df- eb36b13d17e9/hda_disk.qcow2,if=ide,index=0,media=disk,id=drive0,discard=on -uuid 1deb3b2f-421e-460b-91df-eb36b13d17e9 -vnc 0.0.0.0:5 -monitor tcp:127.0.0.1:40269,server,nowait -net none -device virtio-net- pci,mac=0c:eb:3b:2f:00:00,netdev=gns3-0 -netdev socket,id=gns3-0,udp=127.0.0.1:20015,localaddr=127.0.0.1:20014 The qemu disk image was created by "qemu-img create", backed by ubuntu-20.04-server-cloudimg-amd64.img, and resizing it with "qemu-img resize". My best guess is that this is a bug in qemu's handling of disk DISCARD operations. ** Affects: 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/1974100 Title: inode lazy init in a VM fills virtual disk with garbage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1974100/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1809815] Re: renamed VPN doesn't change name in GUI
It's Ubuntu 18.04.1 LTS: LSB Version:core-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch Distributor ID: Ubuntu Description:Ubuntu 18.04.1 LTS Release:18.04 Codename: bionic Desktop is Unity. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1809815 Title: renamed VPN doesn't change name in GUI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1809815/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1809815] [NEW] renamed VPN doesn't change name in GUI
Public bug reported: after changing the name of a VPN (using "Edit Connections..."), the name change isn't immediately reflected in the "VPN connections" submenu from the pull down network menu. After five minutes or so (the time it took to file this bug report), the name change had taken effect. ** Affects: network-manager-applet (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/1809815 Title: renamed VPN doesn't change name in GUI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1809815/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1723219] [NEW] iSCSI installation with static IP address doesn't boot
Public bug reported: I installed Ubuntu 17.04 server on a Cisco UCS configured to boot from iSCSI with a static IP addresses. I ran through the standard installation, configured the network interface with a manually assigned IP address, logged in to the iSCSI target and configured the disk partitioning from there. Everything went fine, then I rebooted, the boot reached the point where it said "Begin: Mounting root file system", then it began looping with messages "IP-Config: no response after x seconds - giving up". I fixed the problem by editing first the grub commands, then /etc/default/grub (after I got the system to boot), adding a kernel option to set the IP address manually: ip=10.250.1.108::10.250.1.254:255.255.255.0:blade8:enp10s0:off The installation script probably needs to add something like this, since the network has to be configured in order to load the root filesystem. ** Affects: initramfs-tools-ubuntu-touch (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/1723219 Title: iSCSI installation with static IP address doesn't boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-touch/+bug/1723219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1388353] Re: package initramfs-tools 0.103ubuntu4.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
I saw this symptom, but for a different reason. Installing and removing initramfs-tools-ubuntu-touch removes /usr/sbin /flash-touch-initrd, but leaves the script /etc/initramfs/post-update.d /zz-flash-touch-initrd, which attempts to call /usr/sbin/flash-touch- initrd and fails. My solution was to purge, not simply remove, initramfs-tools-ubuntu- touch. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1388353 Title: package initramfs-tools 0.103ubuntu4.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/initramfs-tools/+bug/1388353/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1462553] [NEW] script file can call non-existent program
Public bug reported: Installing and then removing initramfs-tools-ubuntu-touch leaves a configuration file /etc/initramfs/post-update.d/zz-flash-touch-initrd that calls /usr/sbin/flash-touch-initrd, which was removed when the package was removed. This causes initramfs-tools to fail during its post-installation script. ** Affects: initramfs-tools-ubuntu-touch (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/1462553 Title: script file can call non-existent program To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-touch/+bug/1462553/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
