[Bug 2061529] [NEW] NameError: name 'yubikey' is not defined
Public bug reported: Running ykman-gui on 22.04 currently shows the following. ykman works fine. NameError: name 'yubikey' is not defined ) qml: qrc:/qml/YubiKey.qml:208: TypeError: Cannot read property 'success' of undefined "PyOtherSide error: Traceback (most recent call last):\n\n File \"\", line 1, in \n\nNameError: name 'yubikey' is not defined\n" qml: Function not found: 'yubikey.controller.refresh' (Traceback (most recent call last): File "", line 1, in NameError: name 'yubikey' is not defined ) qml: qrc:/qml/YubiKey.qml:208: TypeError: Cannot read property 'success' of undefined "PyOtherSide error: Traceback (most recent call last):\n\n File \"\", line 1, in \n\nNameError: name 'yubikey' is not defined\n" qml: Function not found: 'yubikey.controller.refresh' (Traceback (most recent call last): File "", line 1, in NameError: name 'yubikey' is not defined ) qml: qrc:/qml/YubiKey.qml:208: TypeError: Cannot read property 'success' of undefined ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: yubikey-manager-qt 1.2.5-1build2 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Apr 15 09:56:39 2024 InstallationDate: Installed on 2024-01-19 (87 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: yubikey-manager-qt UpgradeStatus: Upgraded to noble on 2024-03-06 (40 days ago) ** Affects: yubikey-manager-qt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug noble -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061529 Title: NameError: name 'yubikey' is not defined To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/yubikey-manager-qt/+bug/2061529/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1968782] [NEW] CHROOT_SESSION_PURGE is set to false without union-type, so 90apt-sources does not render
Public bug reported: I'm not sure if this is incorrect behavior in schroot or incorrect assumption in sbuild-launchpad-chroot. I have a system where I was not able to use union, so the focal-amd64 config that was built by sbuild-launchpad-chroot looks like below. When attempting to build from it (sbuild --dist=focal --arch=amd64 --arch- all package.dsc), CHROOT_SESSION_PURGE is set to false. That causes me to take the 'exit 0' path in https://git.launchpad.net/~motu/ubuntu/+source/sbuild-launchpad- chroot/tree/etc/schroot/setup.d/90apt-sources#n39 . The end result is the 'apt.default.mirror' setting is not honored. If you set 'union-type=overlay', then you'll get CHROOT_SESSION_PURGE set to true and it will work as desired. % cat /etc/schroot/chroot.d/focal-amd64 [focal-amd64] type=directory directory=/var/lib/schroot/chroot/focal-amd64 description=Ubuntu focal/amd64 sbuild root-groups=root,sbuild profile=sbuild launchpad.dist=ubuntu launchpad.series=focal launchpad.arch=amd64 launchpad.url=http://launchpadlibrarian.net/475801990/livecd.ubuntu-base.rootfs.tar.gz apt.enable=true aliases=focal-security-amd64,focal-security+main-amd64,focal-security+restricted-amd64,focal-security+universe-amd64,focal-security+multiverse-amd64,focal-updates-amd64,focal-updates+main-amd64,focal-updates+restricted-amd64,focal-updates+universe-amd64,focal-updates+multiverse-amd64,focal-proposed-amd64,focal-proposed+main-amd64,focal-proposed+restricted-amd64,focal-proposed+universe-amd64,focal-proposed+multiverse-amd64,focal-backports-amd64,focal-backports+main-amd64,focal-backports+restricted-amd64,focal-backports+universe-amd64,focal-backports+multiverse-amd64 apt.default.mirror=MY_MIRROR ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sbuild-launchpad-chroot 0.17ubuntu0.20.10.1~20.04.1 ProcVersionSignature: Ubuntu 5.13.0-28.31~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-28-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Apr 12 15:53:54 2022 InstallationDate: Installed on 2020-01-15 (817 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sbuild-launchpad-chroot UpgradeStatus: Upgraded to focal on 2020-04-17 (725 days ago) modified.conffile..etc.schroot.setup.d.90apt-sources: [modified] mtime.conffile..etc.schroot.setup.d.90apt-sources: 2022-04-12T15:23:14.405987 ** Affects: sbuild-launchpad-chroot (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968782 Title: CHROOT_SESSION_PURGE is set to false without union-type, so 90apt- sources does not render To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1968782/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1859506] Re: swtpm fails in focal with apparor
** Summary changed: - swtmp fails in focal with apparor + swtpm fails in focal with apparor -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1859506 Title: swtpm fails in focal with apparor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1859506/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947311] Re: Unexpected partition growth on first boot on impish for raspberry pi
@Noah, cloud-init isn't doing anything wrong. Its working as designed. 'growroot', which is provided by cloud-initramfs-tools (upstream [1], package [2]) also didn't do anything wrong. It's sole purpose in the initramfs is to do what it is doing. I'm not sure what code creates the image you've pointed to. That is the code that included growroot into the image. Thats what Juerg was saying. It should not be necessary with any kernel newer than 3.8 (~10 years ago). If growroot was *not* present, then the user-data you have provided would tell cloud-init not to grow the partition. -- [1] https://code.launchpad.net/cloud-initramfs-tools [2] https://launchpad.net/ubuntu/+source/cloud-initramfs-tools -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1947311 Title: Unexpected partition growth on first boot on impish for raspberry pi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1947311/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947311] Re: Unexpected partition growth on first boot on impish for raspberry pi
> I thought cloud-initramfs-growroot was solely used with old kernels that > can't resize mounted > filesystems but I could be wrong. Wondering though why we install that > package all of a sudden. that is another option, to remove cloud-initramfs-growroot from the image/initrd. The problem with that is that you're then relying on cloud-init to grow the rootfs, and if you disable cloud-init you don't get the grow. I'm not exactly sure what the purpose of these images is. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1947311 Title: Unexpected partition growth on first boot on impish for raspberry pi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1947311/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947311] Re: Unexpected partition growth on first boot on impish for raspberry pi
@Noah,
The image you pointed at there has the package 'cloud-initramfs-growroot'
in its initramfs. cloud-initramfs-growroot is going to run growpart on the
root filesystem during the initramfs unless one of the following files
exists on the root filesystem:
/var/lib/cloud/instance/root-grown
/etc/growroot-disabled
/etc/growroot-grown
So the easiest to do is to create one of those files. You have mentioned
above that MacOS does not have ext4 filesystem support. So you can't easily
do it natively.
Here are some other options:
1. use libguestfs/guestfish or some other mechanism to boot a linux in which
you could create one of those files.
2. Improve growpart to read a kernel command line option to disable
itself.
3. Improve growpart to further look for a "disable" file on a vfat
filesystem labelled 'system-boot' (lets just say 'growroot-disabled'), and
then use MacOS support of vfat to create the file there.
4. Further partition the image before booting. Growpart can only grow the
root filesystem until the next partition boundary.
Further exploring option '4', here is some information about the image:
a.) there are 2 partitions,
* 1 : 256M partition with VFAT filesystem labelled 'system-boot'.
* 2 : ~3.9GB partition with ext4 filesystem labelled 'writable'
b.) there is 16676864 bytes of unpartitioned space after partition 2.
c.) These are just rants:
* The second partition starts on a MiB boundary, but does not end on one.
So when you create another partition on that disk you're likely
* The partition table type really should be GPT, not dos. 10 years ago
GPT would have been the right decision and it still is today.
* I wonder why 16676864 bytes (32572 sectors) of unused space. that is an
strange number.
So something you probably can do is to add a partition of minimal size
directly after the last partition. You could use fdisk to do this
interactively or sfdisk like below:
If I were trying to do this right, I'd end my mini-partition on a MiB
boundary so that the fourth partition would start on a MiB boundary.
MiB boundary just make sense for alignment (or even 4MiB boundary, for
LVM extent alignment. Maybe it isn't completely necessary, but why not?).
But for simplicitly sake, lets just add a partition right at the end of the
previous one.
Info is attached and at https://paste.ubuntu.com/p/SmQKM2qCXX/ .
Below is the fdisk session inline here (launchpad doesn't format things
like that well, so I put it in attachemnt and pastebin also).
The end result is we have a partition (number 4) that starts right where
the second partition ends, so that:
a.) you can use partition 3 as you wanted before.
b.) growpart can't grow anything.
-
$ fdisk jammy-preinstalled-server-arm64+raspi.img
Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk jammy-preinstalled-server-arm64+raspi.img: 4.18 GiB, 4483710976 bytes,
8757248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x755644c9
Device Boot Start End Sectors Size Id
Type
jammy-preinstalled-server-arm64+raspi.img1 * 2048 526335 524288 256M c
W95
jammy-preinstalled-server-arm64+raspi.img2 526336 8722627 8196292 3.9G 83
Linu
Command (m for help): n
Partition type
p primary (2 primary, 0 extended, 2 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 4
First sector (8722628-8757247, default 8724480): 8722628
Last sector, +/-sectors or +/-size{K,M,G,T,P} (8722628-8757247, default
8757247): +2047
Created a new partition 4 of type 'Linux' and of size 1 MiB.
Command (m for help): w
The partition table has been altered.
Syncing disks.
** Attachment added: "info.txt : disk layout info and partitioning"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1947311/+attachment/5561442/+files/info.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1947311
Title:
Unexpected partition growth on first boot on impish for raspberry pi
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1947311/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1959324] Re: sbuild-launchpad-chroot does not notice tar extract failures
** Also affects: sbuild-launchpad-chroot (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: sbuild-launchpad-chroot (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1959324 Title: sbuild-launchpad-chroot does not notice tar extract failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1959324/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1959324] [NEW] sbuild-launchpad-chroot does not notice tar extract failures
Public bug reported: Nothing is checking exit code of tar when the downloaded tarball is extracted. Tar could fail for many reasons including permission or filesystem full. If tar failed, sbuild-launchpad-chroot would just continue on. The user would likely fail in a less obvious way later on. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sbuild-launchpad-chroot 0.17ubuntu0.20.10.1~20.04.1 ProcVersionSignature: Ubuntu 5.11.0-46.51~20.04.1-generic 5.11.22 Uname: Linux 5.11.0-46-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Thu Jan 27 12:22:26 2022 InstallationDate: Installed on 2020-01-15 (742 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sbuild-launchpad-chroot UpgradeStatus: Upgraded to focal on 2020-04-17 (650 days ago) ** Affects: sbuild-launchpad-chroot (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: sbuild-launchpad-chroot (Ubuntu Focal) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug focal ** Changed in: sbuild-launchpad-chroot (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1959324 Title: sbuild-launchpad-chroot does not notice tar extract failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1959324/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1784713] Re: cloud-init profile.d files use bash-specific builtin "local"
@Eli,
I can recreate your problem, but it looks to me like a bug in ksh. ksh
complains that 'local can only be used in a function, when as shown
below it *is* being used in a function.'
My suggestion is to file a bug with ksh2020.
root@focal1:~# ksh -c 'foo() { local a=1; echo $?; }; foo'
ksh: local: local can only be used in a function
1
root@focal1:~# ksh2020 -c 'foo() { local a; echo $?; }; foo'
ksh2020: local: local can only be used in a function
1
also oddly, ksh seems to report itself in '$SHELL' as /bin/sh.
root@focal1:~# /usr/bin/ksh2020 -c 'foo() { local a=1; echo $?; }; echo
$SHELL; foo'
/bin/sh
/usr/bin/ksh2020: local: local can only be used in a function
1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784713
Title:
cloud-init profile.d files use bash-specific builtin "local"
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1784713/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1940711] [NEW] sign-efi-sig-list uses PKCS7 for variable updates
Public bug reported: When building some software (https://github.com/puzzleos/uefi-dev) I ran into a problem/bug in efitools 'sign-efi-sig-list'. The end result in my case was that an attempt to update the PK variable in uefi (ovmf files from 20.04 with qemu from 20.04) resulted in an exit code of 26 (EFI_SECURITY_VIOLATION). FS0:\> sb_setup.efi SB_SETUP: attempting to configure UEFI Secure Boot SB_SETUP: system is in Setup Mode SB_SETUP: KEK installed SB_SETUP: db installed SB_SETUP: unable to set the PK variable (26) sign-efi-sig-list was used to generate an update to PK in the build process. The fix upstream is https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/commit/?id=e57bafc268511ad54598627b663a7ae86bd856f5 Unfortunately it does not easily cherry-pick to 1.8.1 (20.04's version). There is only a small amount of changes from 1.8.1 to 21.04's version (1.9.2), so the easiest/safest fix may be to just update. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: efitools 1.8.1-0ubuntu2 ProcVersionSignature: Ubuntu 5.8.0-63.71~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-63-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Aug 20 14:55:19 2021 InstallationDate: Installed on 2020-01-15 (582 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: efitools UpgradeStatus: Upgraded to focal on 2020-04-17 (490 days ago) ** Affects: efitools (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: efitools (Ubuntu Focal) Importance: Medium Status: Confirmed ** Tags: amd64 apport-bug focal third-party-packages ** Description changed: When building some software (https://github.com/puzzleos/uefi-dev) I ran into a problem/bug in efitools 'sign-efi-sig-list'. The end result in my case was that an attempt to update the PK variable in uefi (ovmf files from 20.04 with qemu from 20.04) resulted in an exit code of 26 (EFI_SECURITY_VIOLATION). + FS0:\> sb_setup.efi + SB_SETUP: attempting to configure UEFI Secure Boot + SB_SETUP: system is in Setup Mode + SB_SETUP: KEK installed + SB_SETUP: db installed + SB_SETUP: unable to set the PK variable (26) - FS0:\> sb_setup.efi - SB_SETUP: attempting to configure UEFI Secure Boot - SB_SETUP: system is in Setup Mode - SB_SETUP: KEK installed - SB_SETUP: db installed - SB_SETUP: unable to set the PK variable (26) + sign-efi-sig-list was used to generate an update to PK in the build + process. - - The fix upstream is https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/commit/?id=e57bafc268511ad54598627b663a7ae86bd856f5 + The fix upstream is + https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/commit/?id=e57bafc268511ad54598627b663a7ae86bd856f5 Unfortunately it does not easily cherry-pick to 1.8.1 (20.04's version). - There is only a small amount of changes from 1.8.1 to 21.04's version (1.9.2), so - the easiest/safest fix may be to just update. + There is only a small amount of changes from 1.8.1 to 21.04's version + (1.9.2), so the easiest/safest fix may be to just update. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: efitools 1.8.1-0ubuntu2 ProcVersionSignature: Ubuntu 5.8.0-63.71~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-63-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Aug 20 14:55:19 2021 InstallationDate: Installed on 2020-01-15 (582 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) ProcEnviron: - TERM=screen.xterm-256color - PATH=(custom, no user) - XDG_RUNTIME_DIR= - LANG=en_US.UTF-8 - SHELL=/bin/bash + TERM=screen.xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=en_US.UTF-8 + SHELL=/bin/bash SourcePackage: efitools UpgradeStatus: Upgraded to focal on 2020-04-17 (490 days ago) ** Also affects: efitools (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: efitools (Ubuntu) Status: New => Fix Released ** Changed in: efitools (Ubuntu Focal) Status: New => Confirmed ** Changed in: efitools (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1940711 Title: sign-efi-sig-list uses PKCS7 for variable updates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/efitools/+bug/1940711/+subscriptions --
[Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup
Marking this fix-released in focal as bug 1923232 was released to focal. So this should be fixed in '1:4.0.6-0ubuntu1~20.04.1'. ** Changed in: lxc (Ubuntu Focal) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1707222] Re: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean
Norman, Thanks for the comment. On first pass, it looks like you've diagnosed a failure correctly. Please open another bug and add output of 'cloud-init collect-logs'. thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1707222 Title: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1707222/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)
lxc auto package tests show green for 4.0.6-0ubuntu1 other than i386, which failed previously. * amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/l/lxc/20210525_040935_c4b64@/log.gz * arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/l/lxc/20210525_041453_b8cfc@/log.gz * armhf: (skipped) https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/l/lxc/20210525_035510_ea5c7@/log.gz * i386: (failed) https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/i386/l/lxc/20210525_035427_d5ede@/log.gz * ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/l/lxc/20210525_040452_d2faa@/log.gz * s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/l/lxc/20210525_040245_aea9b@/log.gz Given the comments above from bdmurray and stgraber, and also the '[Test Case]' section in the SRU template, I think that should qualify as 'verification-done'. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923232 Title: SRU of LXC 4.0.6 to focal (upstream bugfix release) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1923232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup
** Description changed: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 I think my only options to get that via packaging are a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? The fix is not in 4.0.5, so I marked this as affecting Groovy (currently 1:4.0.4-0ubuntu3) without testing. + + + Related bugs: + * #1923232: SRU of LXC 4.0.6 to focal (upstream bugfix release) ** Description changed: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 I think my only options to get that via packaging are a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? The fix is not in 4.0.5, so I marked this as affecting Groovy (currently 1:4.0.4-0ubuntu3) without testing. - Related bugs: - * #1923232: SRU of LXC 4.0.6 to focal (upstream bugfix release) + * bug 1923232: SRU of LXC 4.0.6 to focal (upstream bugfix release) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup
Just fwi, this is in 4.0.6 which is up for SRU in LP: #1923232. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)
This would fix LP: #1918955. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923232 Title: SRU of LXC 4.0.6 to focal (upstream bugfix release) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1923232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup
** Description changed: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 - I think my only options to get that via packaging are - a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master - b.) build my own. + I think my only options to get that via packaging are + a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master + b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? + + The fix is not in 4.0.5, so I marked this as affecting Groovy (currently + 1:4.0.4-0ubuntu3) without testing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1918955] [NEW] SRU network: fix LXC_NET_NONE cleanup
Public bug reported: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 I think my only options to get that via packaging are a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? ** Affects: lxc (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: lxc (Ubuntu Focal) Importance: Undecided Status: Confirmed ** Affects: lxc (Ubuntu Groovy) Importance: Undecided Status: Confirmed ** Affects: lxc (Ubuntu Hirsute) Importance: Undecided Status: Fix Released ** Also affects: lxc (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: lxc (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: lxc (Ubuntu Groovy) Status: New => Confirmed ** Changed in: lxc (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1693900] Re: apt-get update should return exit code != 0 on error
For reference, ubuntu-devel post about '-o APT::Update::Error-Mode=any' at https://lists.ubuntu.com/archives/ubuntu-devel/2021-February/041374.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1693900 Title: apt-get update should return exit code != 0 on error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1693900/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906187] Re: Version tag is not respected when put last
** Description changed:
I've created a 'network-config' file with Terraform's yamldecode() function
that contains (btw. I've tried with the version being a Number w/o quotes and
as well as a String as shown here):
---
"network":
- "ethernets":
- "eth0":
- "gateway4": "192.168.1.1"
- "nameservers":
- "addresses":
- - "192.168.1.74"
- - "192.168.1.104"
- "search":
- - "fritz.box"
- "set-name": "eth0"
- "version": "2"
+ "ethernets":
+ "eth0":
+ "gateway4": "192.168.1.1"
+ "nameservers":
+ "addresses":
+ - "192.168.1.74"
+ - "192.168.1.104"
+ "search":
+ - "fritz.box"
+ "set-name": "eth0"
+ "version": "2"
---
After running on Raspberry Pi 4B with 4 GB, created with
ubuntu-20.04.1-preinstalled-server-arm64+raspi.img.xz, the machine's setup
fails and /var/log/cloud-init.log reveals that:
---
2020-04-01 17:23:48,649 - util.py[DEBUG]: Reading from
/boot/firmware//network-config (quiet=False)
2020-04-01 17:23:48,649 - util.py[DEBUG]: Read 245 bytes from
/boot/firmware//network-config
2020-04-01 17:23:48,650 - util.py[DEBUG]: Attempting to load yaml from string
of length 240 with allowed root types (,)
2020-04-01 17:23:48,652 - util.py[DEBUG]: Attempting to load yaml from string
of length 245 with allowed root types (,)
2020-04-01 17:23:48,656 - DataSourceNoCloud.py[DEBUG]: Top level network key
in network-config but missing 'config' or 'version': {'network': {'ethernets':
{'eth0': {'gateway4': '192.168.1.1', 'nameservers': {'addresses':
['192.168.1.74', '192.168.1.104'], 'search': ['fritz.box']}, 'set-name':
'eth0'}}, 'version': '2'}}
---
The corresponding /var/log/clout-init-output.log reveals the trace and that
Network won't come up.
---
Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~20.04.1 running 'init-local' at Wed,
01 Apr 2020 17:23:48 +. Up 21.71 seconds.
2020-04-01 17:23:48,796 - util.py[WARNING]: failed stage init-local
failed run of stage init-local
Traceback (most recent call last):
- File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in
status_wrapper
- ret = functor(name, args)
- File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in
main_init
- init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
- File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 699, in
apply_network_config
- net.wait_for_physdevs(netcfg)
- File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 523,
in wait_for_physdevs
- physdevs = extract_physdevs(netcfg)
- File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 519,
in extract_physdevs
- raise RuntimeError('Unknown network config version: %s' % version)
+ File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in
status_wrapper
+ ret = functor(name, args)
+ File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in
main_init
+ init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
+ File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 699, in
apply_network_config
+ net.wait_for_physdevs(netcfg)
+ File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 523,
in wait_for_physdevs
+ physdevs = extract_physdevs(netcfg)
+ File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 519,
in extract_physdevs
+ raise RuntimeError('Unknown network config version: %s' % version)
RuntimeError: Unknown network config version: None
Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~20.04.1 running 'init' at Wed, 01
Apr 2020 17:23:50 +. Up 23.69 seconds.
ci-info: +++Net device
info
ci-info:
++---+---+---+---+---+
ci-info: | Device | Up | Address |Mask | Scope | Hw-Address
|
ci-info:
++---+---+---+---+---+
ci-info: | eth0 | False | . | . | . | dc:a6:32:b1:78:8e
|
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | .
|
ci-info: | lo | True | ::1/128 | . | host | .
|
ci-info: | wlan0 | False | . | . | . | dc:a6:32:b1:78:8f
|
ci-info:
++---+---+---+---+---+
ci-info: +++Route IPv6 info+++
ci-info: +---+-+-+---+---+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +---+-+-+---+---+
ci-info: +---+-+-+---+---+
2020-04-01 17:23:50,653 -
[Bug 1798117] Re: juju sends "network" top level key to user.network-config in lxd containers
The change made here seems to be having fallout at
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1906187
** Description changed:
== Short summary ==
- In lxd containers launched by juju,
+ In lxd containers launched by juju,
/var/lib/cloud/seed/nocloud-net/network-config has:
- has:
- network:
-config: disabled
+ has:
+ network:
+ config: disabled
That is invalid content. Cloud-init assumes content in 'network-config'
is already namespaced to 'network'. The correct content would be:
- config: disabled
+ config: disabled
== Easy recreate ==
$ lxc launch ubuntu-daily:bionic \
-"--config=user.network-config={'network': {'config': {'disabled'}}}"
+ "--config=user.network-config={'network': {'config': {'disabled'}}}"
== Longer Info ==
When looking at bug 1651497, I see containers that run cloud-init
- have errors in a container's cloud-init log
+ have errors in a container's cloud-init log
(http://paste.ubuntu.com/p/5mKXC8pMwH/) like:
- AttributeError: 'NoneType' object has no attribute 'iter_interfaces'
+ AttributeError: 'NoneType' object has no attribute 'iter_interfaces'
and
- Failed to rename devices: Failed to apply network config names. Found bad
network config version: None
+ Failed to rename devices: Failed to apply network config names. Found bad
network config version: None
After some looking guessing I realized that juju must be attempting to
disable cloud-init's network configuration via sending the following
into the nocloud seed (/var/lib/cloud/seed/nocloud-net/network-config)
via 'user.network-config'.
cloud-init can clearly handle this better, but juju should not be
sending invalid configuration.
-
Related bugs:
- * bug 1651497: iscsid.service fails to start in container, results in failed
dist-upgrade later on
+ * bug 1651497: iscsid.service fails to start in container, results in failed
dist-upgrade later on
+ * bug 1906187: Version tag is not respected when put last
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: cloud-init 18.3-9-g2e62cb8a-0ubuntu1~18.04.2
ProcVersionSignature: Ubuntu 4.18.0-8.9-generic 4.18.7
Uname: Linux 4.18.0-8-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
CloudName: NoCloud
Date: Tue Oct 16 14:33:12 2018
PackageArchitecture: all
ProcEnviron:
- TERM=xterm-256color
- PATH=(custom, no user)
- LANG=C.UTF-8
+ TERM=xterm-256color
+ PATH=(custom, no user)
+ LANG=C.UTF-8
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)
cloud-init-log-warnings:
- 2018-10-16 14:32:01,706 - stages.py[WARNING]: Failed to rename devices:
Failed to apply network config names. Found bad network config version: None
- 2018-10-16 14:32:01,707 - util.py[WARNING]: failed stage init-local
- AttributeError: 'NoneType' object has no attribute 'version'
- 2018-10-16 14:32:02,366 - stages.py[WARNING]: Failed to rename devices:
Failed to apply network config names. Found bad network config version: None
+ 2018-10-16 14:32:01,706 - stages.py[WARNING]: Failed to rename devices:
Failed to apply network config names. Found bad network config version: None
+ 2018-10-16 14:32:01,707 - util.py[WARNING]: failed stage init-local
+ AttributeError: 'NoneType' object has no attribute 'version'
+ 2018-10-16 14:32:02,366 - stages.py[WARNING]: Failed to rename devices:
Failed to apply network config names. Found bad network config version: None
user_data.txt:
- #cloud-config
- {}
+ #cloud-config
+ {}
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1798117
Title:
juju sends "network" top level key to user.network-config in lxd
containers
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1798117/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1473527] Re: module ssh-authkey-fingerprints fails Input/output error: /dev/console
There are a slew of bugs and apparently random fallout of /dev/console not working. In my opinion, its really *not* helpful to just ignore that 'write' to stdout fails. Ignoring errors is never really a solution. In this case, cloud-init may have specifically opened /dev/console. But in other cases, it just writes to its stdout or stderr. It does not know that that output is destined for /dev/console or a file, and should not just ignore the errors. The real fix for this is to fix the kernel or the OS in some way so that writes to /dev/console always succeed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1473527 Title: module ssh-authkey-fingerprints fails Input/output error: /dev/console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Fix Committed ** Changed in: cloud-init Importance: Undecided => Medium ** Changed in: cloud-init Assignee: (unassigned) => Markus Schade (lp-markusschade) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
@Markus, Can you please provide a link to documentation showing that? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892447] Re: Why ignore new name server if 3 name servers exists
I set back to 'New', Pengpeng's comment does make sense. cloudinit/net/sysconfig.py's render_network_state calls _render_dns. _render_dns then will load the existing file if it is present. So the end result is that if we have a "stale" version of /etc/resolv.conf on the system, then the dns servers provided in networking configuration get appended to that list. That does seem wrong, and results in the desired networking configuration not being applied. ** Changed in: cloud-init (Ubuntu) Status: Expired => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892447 Title: Why ignore new name server if 3 name servers exists To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1892447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1493188] Re: "overlayfs" no longer exists
** Description changed: === Begin SRU Template === [Impact] The 16.10 kernel dropped a legacy kernel module alias that allowed usage of the 'overlay' filesystem via name 'overlayfs'. This broke overlayroot as it explicitly tried to to use 'overlayfs' by name in loading of modules and also in entry in /etc/fstab. Without this fix, overlayroot will simply not work on any upstream kernel or Ubuntu kernel of 16.10 (yakkety) or later. [Test Case] Note, not applying proposed as shown in step 3 below will recreate failure. 1.) Start an instance of a cloud image. 2.) get a suitable 4.8 kernel On 16.10 or later, this is already done. On 16.04, we currently need to install the kernel team's PPA to get one. $ sudo apt-add-repository -y ppa:canonical-kernel-team/ppa $ sudo apt update -q && sudo apt install -y linux-virtual-hwe-16.04-edge http://archive.ubuntu.com/ubuntu $rel-proposed main" | $ sudo tee /etc/apt/sources.list.d/proposed.list $ sudo apt update -qy && sudo apt install -qy overlayroot http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/view/head:/overlayroot/scripts/init-bottom/overlayroot [2] http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/revision/115 === End SRU Template === As mentioned in LP: #1411294, it's now called 'overlay' instead of 'overlayfs'. Ubuntu had patched the kernel for compatibility. The Ubuntu kernels as of 4.8 (16.10 kernel) and possibly a bit before no longer have a overlayfs module either. Thus, this is now affecting yakkety. (The original reporter is @~gpo-9.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1493188 Title: "overlayfs" no longer exists To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1493188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1888858] Re: document manual_cache_clean better
https://github.com/canonical/cloud-init/pull/568 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/158 Title: document manual_cache_clean better To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/158/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1888858] Re: document manual_cache_clean better
** Description changed:
LP: #1885527 raised (not for the first time) a general failure of cloud-init's
documentation to cover 'manual_cache_clean'. In fact, this configuration
value not referenced at all in readthedocs, but only in
- doc/examples/cloud-config.txt
-
https://github.com/canonical/cloud-init/blob/b70aec8e5ed59298e9fbd5da449350dd3d0002d2/doc/examples/cloud-config.txt#L467
+ doc/examples/cloud-config.txt
+
https://github.com/canonical/cloud-init/blob/b70aec8e5ed59298e9fbd5da449350dd3d0002d2/doc/examples/cloud-config.txt#L467
The intent (testing is needed) for manual_cache_clean is:
a.) user-data and system config (/etc/cloud/*.cfg) can set
- manual_cache_clean to true or false. As always user-data overrides system
+ manual_cache_clean to true or false. As always, user-data overrides system
config. vendor-data should also be able to provide the setting.
b.) cloud-init renders /var/lib/cloud/instance/manual-clean
(path_helper.get_ipath_cur("manual_clean_marker")) if
c.) on boot, both ds-identify and cloud-init will check
and respect existance of /var/lib/cloud/instance/manual-clean .
If that file is present, then cloud-init will not make any
attempts to re-discover a metadata service.
So... "unfreeze", if manual_cache_clean was set is just:
- rm -Rf /var/lib/cloud/instance /var/lib/cloud/instance/
+ rm -Rf /var/lib/cloud/instance /var/lib/cloud/instance/
I think it would be good to both test that my intent/understanding are
correct, and document it. Also useful might be documenting use case
that makes this necessary which is described in:
- https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/comments/6
+ https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/comments/6
Related bugs:
- * bug 1885527: cloud-init regenerating ssh-keys
- * bug 1712680: cloud-init re-generates network config every reboot
+ * bug 1885527: cloud-init regenerating ssh-keys
+ * bug 1712680: cloud-init re-generates network config every reboot
** Description changed:
LP: #1885527 raised (not for the first time) a general failure of cloud-init's
documentation to cover 'manual_cache_clean'. In fact, this configuration
value not referenced at all in readthedocs, but only in
doc/examples/cloud-config.txt
https://github.com/canonical/cloud-init/blob/b70aec8e5ed59298e9fbd5da449350dd3d0002d2/doc/examples/cloud-config.txt#L467
The intent (testing is needed) for manual_cache_clean is:
a.) user-data and system config (/etc/cloud/*.cfg) can set
manual_cache_clean to true or false. As always, user-data overrides system
config. vendor-data should also be able to provide the setting.
b.) cloud-init renders /var/lib/cloud/instance/manual-clean
- (path_helper.get_ipath_cur("manual_clean_marker")) if
+ (path_helper.get_ipath_cur("manual_clean_marker"))
c.) on boot, both ds-identify and cloud-init will check
and respect existance of /var/lib/cloud/instance/manual-clean .
If that file is present, then cloud-init will not make any
attempts to re-discover a metadata service.
So... "unfreeze", if manual_cache_clean was set is just:
rm -Rf /var/lib/cloud/instance /var/lib/cloud/instance/
I think it would be good to both test that my intent/understanding are
correct, and document it. Also useful might be documenting use case
that makes this necessary which is described in:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/comments/6
Related bugs:
* bug 1885527: cloud-init regenerating ssh-keys
* bug 1712680: cloud-init re-generates network config every reboot
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/158
Title:
document manual_cache_clean better
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/158/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1893064] Re: sru cloud-init (20.2-45 to 20.3-0) Xenial, Bionic, and Focal
** Changed in: cloud-init (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1893064 Title: sru cloud-init (20.2-45 to 20.3-0) Xenial, Bionic, and Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1893064/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892879] Re: python-ubuntutools package is empty.
See bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev- tools/+bug/1864571 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892879 Title: python-ubuntutools package is empty. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1892879/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864571] Re: SRU ubuntu-dev-tools
I'm pretty sure this change caused bug 1892879 also. basically, the python-ubuntudevtools package is empty. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864571 Title: SRU ubuntu-dev-tools To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1864571/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892879] [NEW] python-ubuntutools package is empty.
Public bug reported: The python-ubuntutools package is empty. root@b1:~# dpkg -L python-ubuntutools /. /usr /usr/share /usr/share/doc /usr/share/doc/python-ubuntutools /usr/share/doc/python-ubuntutools/NEWS.Debian.gz /usr/share/doc/python-ubuntutools/changelog.gz /usr/share/doc/python-ubuntutools/copyright root@b1:~# dpkg-query --show python-ubuntutools python-ubuntutools 0.175~18.04.1 root@b1:~# python -c 'from ubuntutools.misc import host_architecture' Traceback (most recent call last): File "", line 1, in ImportError: No module named ubuntutools.misc This happened between 0.174 and 175~18.04.1. I found this by simply trying to use sbuild-launchpad-chroot to verify bug 1872163. It can be reproduced like this: ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: python-ubuntutools 0.175~18.04.1 ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 Uname: Linux 5.4.0-42-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.16 Architecture: amd64 Date: Tue Aug 25 15:08:07 2020 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SourcePackage: ubuntu-dev-tools UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: ubuntu-dev-tools (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: ubuntu-dev-tools (Ubuntu Bionic) Importance: High Status: Confirmed ** Tags: amd64 apport-bug bionic regression-release uec-images ** Changed in: ubuntu-dev-tools (Ubuntu) Status: New => Fix Released ** Also affects: ubuntu-dev-tools (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: ubuntu-dev-tools (Ubuntu Bionic) Status: New => Confirmed ** Changed in: ubuntu-dev-tools (Ubuntu Bionic) Importance: Undecided => High ** Tags added: regression-release -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892879 Title: python-ubuntutools package is empty. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1892879/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
Verification log of focal. Note 2 things: a.) recent update to the test script b.) if you look closely at the log you'll see '91smoser-schroot-setup' output. That is from https://gist.github.com/smoser/14df5f0cd621e10d2282d7c90345e322 It should not affect the verification of this bug. ** Attachment added: "verification log of focal" https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+attachment/5402547/+files/verify-focal.log.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872163 Title: focal chroots broken due to change in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
** Attachment added: "updated test - adds user, not root to sbuild" https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+attachment/5402546/+files/test-sbuild-launchpad-chroot -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872163 Title: focal chroots broken due to change in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872163 Title: focal chroots broken due to change in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1225922] Re: Support static network configuration even on already configured devices
I'm going to mark this fix-released. The general bug as described in the description is that cloud-init can't correctly apply networking for all interfaces. cloud-init local applies networking configuration to the system, and should apply before the system brings networking up. Thus appearing to the system as if the networkign config was already there, and should be brought up properly as it would be on reboot. If you think this bug is not fixed, its probably best to file a new bug, describe the problem, and attach output of 'cloud-init collect-logs'. ** Changed in: ubuntu Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1225922 Title: Support static network configuration even on already configured devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1225922/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1890803] Re: Groovy amd64 / arm64 / PowerPC deployment seems not working
[ubuntu/groovy-proposed] cloud-initramfs-tools 0.47ubuntu1 (Accepted) ^ landed Ryan's fix (comment #38 mp 389422) ** Merge proposal linked: https://code.launchpad.net/~raharper/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/389422 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890803 Title: Groovy amd64 / arm64 / PowerPC deployment seems not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1890803/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1890803] Re: Groovy amd64 / arm64 / PowerPC deployment seems not working
@Rod I wouldn't bother until you see an image with serial greater than 20200813. If it doesn't have cloud-initramfs-tools > 0.45ubuntu1, its not going to work with groovy. then test that and complain with logs if its not working. On Fri, Aug 14, 2020 at 1:15 PM Rod Smith <1890...@bugs.launchpad.net> wrote: > > FWIW, I tried a deployment on an AMD64-architecture server using an > ASRock MT-C224 motherboard (one of the experimental Orange Box v3 nodes > in 18T), and it failed. I can provide additional logs if required. I > have not attempted to install any of the branches associated with this > bug report. (I'm not entirely sure how I'd do so.) > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1890803 > > Title: > Groovy amd64 / arm64 / PowerPC deployment seems not working > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-init/+bug/1890803/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890803 Title: Groovy amd64 / arm64 / PowerPC deployment seems not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1890803/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1890803] Re: Groovy amd64 / arm64 / PowerPC deployment seems not working
Fixed in groovy at cloud-initramfs-tools 0.46ubuntu1 ** Also affects: cloud-initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-initramfs-tools (Ubuntu) Importance: Undecided => High ** Changed in: cloud-initramfs-tools (Ubuntu) Status: New => Fix Released ** Changed in: cloud-initramfs-tools (Ubuntu) Assignee: (unassigned) => Scott Moser (smoser) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890803 Title: Groovy amd64 / arm64 / PowerPC deployment seems not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1890803/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@Eric, William, I think you're taking a very narrow view on this when a more thoughtful review is needed. Ubuntu should identify a general policy on 'client <-> server' version backwards and forwards compatibility guarantees. That policy should be implemented here. The fact this particular client-server mismatch is somewhat trivial to fix should not really be individually be considered. It is simply not feasible for Ubuntu to support and carry delta from upstream for all clients shipping in 23.10 that do not interoperate with servers shipped in 14.04. @Eric, You are welcome to float the patch upstream. But they *have* intentionally and specifically dropped python 3.4 support. That doesn't seem unreasonable since python 3.4 went end of life in March of 2019. https://github.com/sshuttle/sshuttle/commit/1b50d364c67ae1eb9dc831e312fc11b75f4ad43e -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@Eric, Well... We'd only be carring the change for 20.04. I would not suggest to carry it for 20.10 or beyond. As my change is right now I dont' think I would accept it for upstream. It should be sufficient for a stable release though. I really suspect that if upstream cared about python < 3.5, they'd have maintained it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@all, Please review a MP at https://code.launchpad.net/~smoser/ubuntu/+source/sshuttle/+git/sshuttle/+merge/388062 that will fix this for focal -> trusty and keep focal -> focal working. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@Lukasz sshuttle does not require itself to be installed on the server. Rather it "pushes" itself from the client to the server. So the code that executes on client is the same as that on the server. Maybe the table below will help: client | server | comment trusty | focal | broken due to py3.8 on focal (would need SRU to trusty) bionic | focal | broken due to py3.8 on focal (would need SRU to bionic) focal | focal | was broken, is fixed by 0.78.5-1ubuntu1 focal | bionic | works before and after focal | trusty | broken by 0.78.5-1ubuntu1 trusty | trusty | works -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
** Merge proposal linked: https://code.launchpad.net/~smoser/ubuntu/+source/sshuttle/+git/sshuttle/+merge/388062 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
I opened bug 158 to request better documentation on this feature. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1888858] [NEW] document manual_cache_clean better
Public bug reported:
LP: #1885527 raised (not for the first time) a general failure of cloud-init's
documentation to cover 'manual_cache_clean'. In fact, this configuration
value not referenced at all in readthedocs, but only in
doc/examples/cloud-config.txt
https://github.com/canonical/cloud-init/blob/b70aec8e5ed59298e9fbd5da449350dd3d0002d2/doc/examples/cloud-config.txt#L467
The intent (testing is needed) for manual_cache_clean is:
a.) user-data and system config (/etc/cloud/*.cfg) can set
manual_cache_clean to true or false. As always user-data overrides system
config. vendor-data should also be able to provide the setting.
b.) cloud-init renders /var/lib/cloud/instance/manual-clean
(path_helper.get_ipath_cur("manual_clean_marker")) if
c.) on boot, both ds-identify and cloud-init will check
and respect existance of /var/lib/cloud/instance/manual-clean .
If that file is present, then cloud-init will not make any
attempts to re-discover a metadata service.
So... "unfreeze", if manual_cache_clean was set is just:
rm -Rf /var/lib/cloud/instance /var/lib/cloud/instance/
I think it would be good to both test that my intent/understanding are
correct, and document it. Also useful might be documenting use case
that makes this necessary which is described in:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/comments/6
Related bugs:
* bug 1885527: cloud-init regenerating ssh-keys
* bug 1712680: cloud-init re-generates network config every reboot
** 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/158
Title:
document manual_cache_clean better
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/158/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
@Daniel,
> One convenience we could potentially provide: if cloud-init had a way
> for image creators to express "when next launched, cloud-init should
> treat that instance ID as immutable and permanent" (in a way that could
> be undone on subsequent boots, if a user wants to "unfreeze" an instance
> for image capture) then we might be able to avoid some of this pain, but
> that idea would need more fleshing out before it's clear if it even
> makes sense.
I think you're basically describing "manual_cache_clean".
The intent (testing is needed) for manual_cache_clean is that
a.) user-data and system config (/etc/cloud/*.cfg) can set
manual_cache_clean to true or false. As always user-data overrides system
config. vendor-data should also be able to provide the setting.
b.) cloud-init renders /var/lib/cloud/instance/manual-clean
(path_helper.get_ipath_cur("manual_clean_marker")) if
c.) on boot, both ds-identify and cloud-init will check
and respect existance of /var/lib/cloud/instance/manual-clean
So... "unfreeze", if manual_cache_clean was set is just:
rm -Rf /var/lib/cloud/instance /var/lib/cloud/instance/
I think it would be good to both test that my intent/understanding are
correct, and document it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@William, The fix here does break python < 3.5 (as advertised in the debian/patches/ patch). It is mostly trivial to make this change in a backwards compatible way, so we should probably do that. I wonder what the official policy is on breaking this "client"s interaction with an ubuntu release version that is now under ESM. I didn't see anything that obviously covered this in https://wiki.ubuntu.com/StableReleaseUpdates . -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1491148] Re: growpart doesn't work with mdraid devices
** Changed in: cloud-utils (Ubuntu) Assignee: Scott Moser (smoser) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1491148 Title: growpart doesn't work with mdraid devices To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-utils/+bug/1491148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1491148] Re: growpart doesn't work with mdraid devices
** Changed in: cloud-utils (Ubuntu) Status: In Progress => Confirmed ** Changed in: cloud-utils (Ubuntu Eoan) Status: In Progress => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1491148 Title: growpart doesn't work with mdraid devices To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-utils/+bug/1491148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@Felipe, Two things I think should be changed in your debdiff: a.) version should be 0.78.5-1ubuntu0.1 instead of 0.78.5-1ubuntu1 per https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging . I'm not certain on that though. b.) the referenced commit (9c873579) is not the commit that was added to upstream master. Per your link "This commit does not belong to any branch on this repository." The correct value is 6c21addde97c4582b3dccb22bca64c33af3e5eff [1] which landed in upstream/master. You should update the value in debian/patches/lp1873368.patch . -- [1] https://github.com/sshuttle/sshuttle/commit/6c21addde97c4582b3dccb22bca64c33af3e5eff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
@slashd, Are you suggesting your 'A' (version 1.0.2) for focal? Unless there are other reasons than this bug, that feels like not the right path for SRU. So that means 'B' is the path forward for focal. So I might suggest just doing 'B' for groovy now (adding ubuntu delta). That would then allow ubuntu to move forward, get some easier real-world testing, and satisfy the "fixed in development release" requirement for SRU. Presumably the next upload to debian will have a fix, so that would be a short-term delta and we can do a sync of whatever debian does. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873368 Title: ssshuttle server fails to connect endpoints with python 3.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1873368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
@Valery, Some cloud platforms provide the instance id via some non-network channel (dmi data is common). In those cases, cloud-init will check cached value versus the locally-available instance-id before looking for a network available datasource. So, if Hetzner provides that information in some way, cloud-init can use it. If not, the only options are to for the user to disable cloud-init (touch /etc/cloud/cloud-init.disabled) or set manual_cache_clean (https://bugs.launchpad.net/cloud-init/+bug/1712680/comments/11). I'm not really sold on "what if the metadata service is DOWN" argument. Your cloud should not have its important services just fail. If it does, things are going to break. You could make a similar argument "What if DNS server is down?". I'm not discounting "Design for failure", and cloud-init could definitely do better here, but we need some support from the platform (locally available instance-id) to do better without sacrificing design goals. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
"AGAIN: Why is cloud-init still manipulating the machine *after* initialization and first boot?" Because cloud-init thinks it is a "first boot". A supported use case for cloud-init is: * boot instance on cloud * ssh in * install some packages, prep this instance * stop instance * snapshot disk * register new image from disk * start new instances from this image cloud-init will recognize that these instances are new instances, and initialize them. It recognizes this by comparing the cached value of 'instance-id' versus the current value of 'instance-id'. If they have changed, then you have a new instance. The other reason for cloud-init to "remain active" is that it offers "per-boot" things. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
after replying with collected logs, please set the status back to 'new'. thanks for taking the time to file 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/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
Hi, please attach the output of 'cloud-init collect-logs' when run on a system that demonstrates the problem. cloud-init uses the "instance-id" from the metadata service to indicate a new instance. Some things run once per instance, some things run once per boot. ** Changed in: cloud-init (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1463072] Re: highlighting on left mouse double click ends at : (colon)
this worked for me to set all profiles as I wanted in 20.04 $ val='@ms
[Bug 1573095] Re: Cloud images fail to boot when a serial port is not available
@Guilherme, Simply returning non-error (0) in one function in the initramfs isn't going to solve the problem. Anything that is checking the return value of a write() to its stdout will fail. That could be a shell 'echo', it could be a C write(). In order to take that path completion, you'd have to have all programs ignore errors when writing to stdout, which might happen to be /dev/console. Here's an example of something else (growpart) caring: https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs- tools/+bug/1123220 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1573095 Title: Cloud images fail to boot when a serial port is not available To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1573095/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1796137] Re: huge and slow image 20181002 due to seeded lxd snap
@stgraber, The bug subject says "Huge and slow". Shame on me to make 1 bug for 2 issues. But wrt "is this fixed", groovy images are still dramatically bigger *and* slower to boot than bionic images. a.) Huge. Still looks much bigger, 'Huge' can obviously be argued. 346M for current groovy daily versus 179MB for bionic. $ lxc image list ubuntu-daily: | grep 20.10 | grep x86_64 | g (7 more) | 7a5b11633006 | yes| ubuntu 20.10 amd64 (daily) (20200601) | x86_64 | CONTAINER | 346.31MB | Jun 1, 2020 at 12:00am (UTC) | b.) Slow. groovy is much faster than originally reported, but still >1.5x longer than bionic. bionic booted here in 8.2s and groovy in 15.5s. https://paste.ubuntu.com/p/pjJD6t4YCQ/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1796137 Title: huge and slow image 20181002 due to seeded lxd snap To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1796137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1880704] Re: jump in kernel clock during boot on azure
@Anh Vo, Thanks for looking at this. It almost seemed too perfect for me to believe the pre-provisioning stuff kicked in, and that there were exactly zero journal entries in almost 9 days. I would think it'd be nice for cloud-init to clearly state "pre- provisioned system waited X seconds" or something, but not a big deal. I guess there are two things that are not perfect here, but I don't really know how big a deal they are: a.) I would expect others to be confused by 'uptime' of days on a newly provisioned machine. (and it feels like 9 days of system-idle is a heavy cost of optimization for a few seconds of boot time) b.) I just selected "Ubuntu 18.04" from the "new vm" dialog series. I'd hope that if there was a new image available those that were in the pre-provisioned queue would be cleared. Ie, if I ask for "Ubuntu 18.04" today, that isn't necessarily the same as having done so 9 days earlier. overall, though, Thanks and this looks like it is working well. I'll close this issue. Scott ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1880704 Title: jump in kernel clock during boot on azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1880704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1880704] Re: jump in kernel clock during boot on azure
In my head there are a few possibilities here: a.) azure correctly guessed that I was going to launch an instance and "pre-provisioned" it a week before I did it. this seems unlikely to me for a number of reasons, but I could be convinced that if this happened, everything is working as designed. b.) the kernel 'uptime' is only never-decreasing, but does not guarantee there are no jumps. Then, this is working as advertised. My problem with 'b' is that (now) python3's monotonic clock agrees seems based on uptime: $ cat /proc/uptime ; python3 -c 'import time; print(time.mon otonic())' 771486.80 1542571.64 771486.825732702 python's documentation in pep 418 [1] says: Monotonic clock, i.e. cannot go backward. It is not affected by system clock updates. [1] https://www.python.org/dev/peps/pep-0418/#time-monotonic I would argue that all evidence points to the python.monotonic() output being affected by system clock updates(). (I don't have a output before that jump, so I clearly can't definitively say that, but it is a very strong coincidence otherwise). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1880704 Title: jump in kernel clock during boot on azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1880704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1880704] [NEW] jump in kernel clock during boot on azure
Public bug reported: I launched a new instance on azure and noticed that it had 'uptime' of 8 days. Debugging a bit with Odd_Bloke in #cloud-init, it certainly seems that it is around the time when timesync ran: $ journalctl -o short-monotonic -u systemd-timesyncd.service --no-pager -- Logs begin at Sun 2020-05-17 17:02:46 UTC, end at Tue 2020-05-26 14:25:13 UTC. -- [9.538593] ubuntu systemd[1]: Starting Network Time Synchronization... [9.962555] ubuntu systemd[1]: Started Network Time Synchronization. [766221.957145] smoser00 systemd-timesyncd[725]: Network configuration change d, trying to establish connection. [766222.048914] smoser00 systemd-timesyncd[725]: Network configuration change d, trying to establish connection. [766223.170150] smoser00 systemd-timesyncd[725]: Network configuration change d, trying to establish connection. [766223.266062] smoser00 systemd-timesyncd[725]: Synchronized to time server 91.189.91.157:123 (ntp.ubuntu.com). I did not expect 'uptime' to be affected by ntpd fixes. I guess it is possible that I benefited from the "pre-provisioning" on azure, but that seems unlikely as this account has probably run 5 ubuntu instances for a total of maybe a week over the last year. So it would seem a poor candidate for such a thing, or a really good prediction algorithm. If its the latter, then kudos to Microsoft for guessing that I was going to launch an instance today. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: cloud-init 19.4-33-gbb4131a2-0ubuntu1~18.04.1 ProcVersionSignature: Ubuntu 5.3.0-1020.21~18.04.1-azure 5.3.18 Uname: Linux 5.3.0-1020-azure x86_64 ApportVersion: 2.20.9-0ubuntu7.14 Architecture: amd64 CloudName: Azure Date: Tue May 26 14:24:41 2020 PackageArchitecture: all ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) user_data.txt: ** Affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic uec-images -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1880704 Title: jump in kernel clock during boot on azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1880704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1691772] Re: provide a way to seed NoCloud from network without image modification.
** Description changed:
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
a.) download a cloud image, update its cloud-init
-# see below for 'get-proposed-cloudimg'
-$ release=xenial
-$ get-proposed-cloudimg $release
+ # see below for 'get-proposed-cloudimg'
+ $ release=xenial
+ $ get-proposed-cloudimg $release
b.) boot that image with command line pointing at a 'seed'
-$ img=${release}-server-cloudimg-amd64-proposed.img
-# url has to provide '/user-data' and '/meta-data'
-$
url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
-$ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
- -device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
- -drive "file=$img,if=virtio" \
- -smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
- -nographic
+ $ img=${release}-server-cloudimg-amd64-proposed.img
+ # url has to provide '/user-data' and '/meta-data'
+ $
url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
+ $ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
+ -device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
+ -drive "file=$img,if=virtio" \
+ -smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
+ -nographic
-# note, you can hit 'ctrl-a c' to toggle between the qemu monitor
-# and the serial console in '-nographic' mode.
+ # note, you can hit 'ctrl-a c' to toggle between the qemu monitor
+ # and the serial console in '-nographic' mode.
c.) Log in with 'ubuntu:passw0rd' and check hostname.
-If the above url was correctly used, then:
- * you can log in with 'ubuntu:passw0rd'
- * the hostname will be set to 'nocloud-guest'
- * /run/cloud-init/result.json will show that the url has been used.
+ If the above url was correctly used, then:
+ * you can log in with 'ubuntu:passw0rd'
+ * the hostname will be set to 'nocloud-guest'
+ * /run/cloud-init/result.json will show that the url has been used.
-ubuntu@nocloud-guest:~$ hostname
-nocloud-guest
-ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
-{
- "v1": {
- "datasource": "DataSourceNoCloudNet
[seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net];,
- "errors": []
- }
-}
+ ubuntu@nocloud-guest:~$ hostname
+ nocloud-guest
+ ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
+ {
+ "v1": {
+ "datasource": "DataSourceNoCloudNet
[seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net];,
+ "errors": []
+ }
+ }
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as a
string with data in it. If that field had the string 'ds=nocloud' that was
not intended as consumable for cloud-init, a false positive could occur and
an exception cause the NoCloud datasource to not read data from another
location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
- https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
+ https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
get-proposed-cloudimg is available at [1], it basically downloads an
ubuntu cloud image, enables -proposed and upgrade/installs cloud-init.
--
[1]
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-cloudimg
=== End SRU Template ===
-
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with
cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12
+
+ Related bugs:
+ * bug 1879294: Support fw_cfg data source
+ * bug 1753558: NoCloud should use "OEM Strings" instead of
+system-serial-number
+ * bug 1691772: provide a way to seed NoCloud from network without image
modification.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1691772
Title:
provide a way to seed NoCloud from network without image modification.
To manage
[Bug 1872163] Re: focal chroots broken due to change in sources.list
** Description changed: + - Begin SRU info - + [Impact] + Users of sbuild-launchpad-chroot cannot use chroots created with + sbuild-launchpad-chroot with a build-release of focal or groovy. + An attempt to do so fails during 'apt-get update' as the + /etc/apt/sources.list file that is created is not valid. + + To recreate failure just try build and usage. + + $ sudo apt-get update + $ sudo apt-get install sbuild-launchpad-chroot + $ sudo sbuild-launchpad-chroot create --architecture=amd64 \ + --name=focal-amd64 --series=focal + + Then get a dsc file to build. Any dsc will show the issue, this is only + to have a complete example. + + $ dget https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/cloud-utils/0.31-7-gd99b2d76-0ubuntu1/cloud-utils_0.31-7-gd99b2d76-0ubuntu1.dsc + $ sbuild --dist=focal --arch=amd64 --arch-all cloud-utils_0.31-7-gd99b2d76-0ubuntu1.dsc + ... + +--+ + | Update chroot | + +--+ + + E: Type 'main' is not known on line 5 in source list /etc/apt/sources.list + E: The list of sources could not be read. + E: apt-get update failed + + + [Test Case] + To test: + + * install sbuild-launchpad-chroot. + * Create chroots for bionic (old format) and focal (new format). + * build a package in the chroot. + + Because the mirror differs between amd64 and other arches, you should + also build for a non-amd64 arch. + + The attached script will do all of the above. + + I suggest running like: + + * manually enable -proposed + * ./test-sbuild-launchpad-chroot + + Note that sbuild likely wont work properly in a container, so the + script will exit failure if detected. + + [Regression Potential] + The most likely scenario for regression is in uers with custom scripts in + /etc/schroot.d/setup.d that make assumptions about the format of + /etc/apt/sources.list. + + A user could have: + 1. added a script that ran *before* 90apt-sources that wrote or edited + the /etc/apt/sources.list to modify a mirror or make other changes. + + Since we have changed the code to no longer attempt to edit + sources.list the changes in 1 would likely be destroyed. + + 2. added a script that ran *after* 90apt-sources that made similar changes + and made assumption of the state of that file. + + Assumptions made about the format of this file may be broken and cause + breakage of such scripts. + + Lastly, a user could have relied on 90apt-sources to edit their schroots + during setup. It seems unlikely to me that a user would have desired + this, but the change will no longer modify schroots that were not created + by sbuild-launchpad-chroot. + + Ultimately... it is somewhat unlikely that user-added scripts would have + worked with focal or groovy schroots. + + [Other Info] + The change that caused this failure was in the /etc/apt/sources.list file that + is present in the launchpad schroot. + + A summary of how sbuild-launchpad-chroot works. When a build is requested, the + following happens: + 1. The packagd file /etc/schroot/setup.d/01launchpad-chroot executes. It + will query launchpad for a tarball to use as chroot, and possibly update + the existing one. + + 2. /etc/schroot/setup.d/90apt-sources executes and updates the + exixting /etc/apt/sources.list inside the chroot. The goal of this is + to enable the requested combination of + suite (release, security, ... ) and + component (main, restricted, universe ...) + + The existing code is only able to handle a "one line" version of + /etc/apt/sources.list, that looks like the following: + +deb http://archive.ubuntu.com/ubuntu/ bionic main restricted universe + multiverse + + Focal and groovy chroots now a have a "complete" /etc/apt/sources.list + file as you would see in a lxc container or an installed system. + + The change made was to more fully "own" the writing of + /etc/apt/sources.list. The previous code made a large assumption on the + format of /etc/apt/sources.list in the chroot, and tried to edit it based + on that assumption. When the format of the file changed, its ability to + edit the file failed. + + The new code just declares the settings, which makes it much simpler. + The new code is not expected to be "general purpose". In order to + avoid breaking other schroot's, it is only enabled if this schroot + was set up by launchpad-schroot. + + -- feature added -- + There is one feature added in this patch, now the user can + set the mirror that they would like to use by adding a setting: + apt.default.mirror + To the /etc/schroot/chroot.d/name + + For example: + $ grep apt /etc/schroot.d/focal-amd64 + apt.enable=true + apt.default.mirror=http://us.archive.ubuntu.com/ubuntu + + If no value is set there, then code will use the mirror specified in the +
[Bug 1876139] Re: Groovy cloud-images failing during growpart
** Changed in: cloud-init Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876139 Title: Groovy cloud-images failing during growpart To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1573095] Re: Cloud images fail to boot when a serial port is not available
@wgh, My experience is that it is unfortunately not that simple. It may have worked for you. At the point in which it starts to fail, it repeatedly will fail. But up until some point, writes to stdout work fine. I believe this is because there is a buffer and it only begins failing when it has filled the buffer and tried to flush. I have a script that I had put into the initramfs in one of the other bugs that shows this. Its quite possible that the behavior has changed in 8 years, but before you basically just had to write some amount of data to determine if it would fail. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1573095 Title: Cloud images fail to boot when a serial port is not available To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1573095/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
** Also affects: sbuild-launchpad-chroot (Ubuntu Groovy) Importance: Undecided Status: Confirmed ** Also affects: sbuild-launchpad-chroot (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: sbuild-launchpad-chroot (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: sbuild-launchpad-chroot (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: sbuild-launchpad-chroot (Ubuntu Bionic) Status: New => Confirmed ** Changed in: sbuild-launchpad-chroot (Ubuntu Eoan) Status: New => Confirmed ** Changed in: sbuild-launchpad-chroot (Ubuntu Focal) Status: New => Confirmed ** Changed in: sbuild-launchpad-chroot (Ubuntu Groovy) Status: Confirmed => In Progress ** Changed in: sbuild-launchpad-chroot (Ubuntu Groovy) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872163 Title: focal chroots broken due to change in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
** Merge proposal linked: https://code.launchpad.net/~smoser/ubuntu/+source/sbuild-launchpad-chroot/+git/sbuild-launchpad-chroot/+merge/383600 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872163 Title: focal chroots broken due to change in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1573095] Re: Cloud images fail to boot when a serial port is not available
The real fix here is kernel improvement (or bug fix if you want to consider current kernel behavior a bug). Anything else is just going to push around the failure. That is what was determined in 2013, and its probably still true how. https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1123220/comments/8 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1573095 Title: Cloud images fail to boot when a serial port is not available To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1573095/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1876139] Re: Groovy cloud-images failing during growpart
** Changed in: cloud-utils Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876139 Title: Groovy cloud-images failing during growpart To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1876139] Re: Groovy cloud-images failing during growpart
https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/383431 Merge proposal to upstream cloud-utils ^ ** Also affects: cloud-utils Importance: Undecided Status: New ** Changed in: cloud-utils Status: New => Confirmed ** Changed in: cloud-utils Importance: Undecided => Medium ** Changed in: cloud-utils (Ubuntu) Status: New => Confirmed ** Changed in: cloud-utils (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876139 Title: Groovy cloud-images failing during growpart To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1876139] Re: Groovy cloud-images failing during growpart
I realize this is probably just seen as noise. But I think its important that everyone here understand. Growpart supports using either fdisk or gdisk. But I have recently considered deleting the gdisk support. I'm curious why fdisk is seen as "an old package". fdisk/sfdisk supports GPT partition tables and has for several years. Also, * it is part of util-linux source (which is Essential). * It is maintained and updated (107 commits reference fdisk in util linux since Jan 1, 2019. gpt-fdisk has 25 total commits in that time frame. As much infrastructure is shared with other util-linux tools, that count is not complete). * fdisk (installed 505, size 119712) is smaller than gdisk (installed 860, size 214516) and has fewer dependencies. * In my opinion, sfdisk is dramatically more usable than sgdisk. * I'd even argue that the ui of fdisk is better than gdisk. If the goal is to have one "partitioner", then fdisk/sfdisk is probably the one to keep. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876139 Title: Groovy cloud-images failing during growpart To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1876139] Re: Groovy cloud-images failing during growpart
independent of how sfdisk gets into a cloud-image, cloud-utils should identify its dependency. Something like https://paste.ubuntu.com/p/Fzwkm2PgqF/ ** Also affects: cloud-utils (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/1876139 Title: Groovy cloud-images failing during growpart To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1834875] Re: cloud-init growpart race with udev
@Markus, Please open a bug against cloud-initramfs-growroot and reference it here (and reference this bug there). Please also provide a full console log. fwiw, generally speaking cloud-initramfs-growroot has not been necessary since at least 14.04, quite possibly even beefore. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1718761] Re: It's not possible to use OverlayFS (mount -t overlay) to stack directories on a ZFS volume
I hit this today, and filed bug 1873917 before dupe'ing it to this. I'd think that the main pain points are a.) using overlay in a container that is backed by zfs via lxd b.) using overlay when using zfs root (https://didrocks.fr/2019/10/11/ubuntu-zfs-support-in-19.10-zfs-on-root/) I attached a re-create https://launchpadlibrarian.net/475448177/test- overlay -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1718761 Title: It's not possible to use OverlayFS (mount -t overlay) to stack directories on a ZFS volume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1718761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873917] Re: zfs not supported as upperdir or workdir for overlay mount
*** This bug is a duplicate of bug 1718761 *** https://bugs.launchpad.net/bugs/1718761 ** This bug has been marked a duplicate of bug 1718761 It's not possible to use OverlayFS (mount -t overlay) to stack directories on a ZFS volume -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873917 Title: zfs not supported as upperdir or workdir for overlay mount To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873917/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873917] [NEW] zfs not supported as upperdir or workdir for overlay mount
Public bug reported: zfs cannot be used as a filesystem for an overlay mount's 'upperdir' or 'workdir' arguement. If you have zfs root, or are inside an lxd that uses zfs then you'll not be able to use overlay mounts without working around this bug. It can be worked around by using a tmpfs. $ ./test-overlay container=lxc $ lsb_release -sc focal $ uname -r 5.4.0-25-generic $ id uid=0(root) gid=0(root) groups=0(root) $ df --print-type /tmp/test-dir/mp FilesystemType 1K-blocks Used Available Use% Mounted on default/containers/f2 zfs 14655872 523648 14132224 4% / $ mount -t tmpfs tmpfs /tmp/test-dir/up $ mount -t overlay -o lowerdir=/etc,upperdir=/tmp/test-dir/up,workdir=/tmp/test-dir/wk overlay /tmp/test-dir/mp mount: /tmp/test-dir/mp: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error. [ 1820.65] overlayfs: filesystem on '/tmp/test-dir/wk' not supported as upperdir FAIL ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-25-generic 5.4.0-25.29 ProcVersionSignature: Ubuntu 5.4.0-25.29-generic 5.4.30 Uname: Linux 5.4.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: smoser 6538 F pulseaudio /dev/snd/controlC2: smoser 6538 F pulseaudio /dev/snd/controlC1: smoser 6538 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Apr 20 13:14:37 2020 InstallationDate: Installed on 2020-01-15 (95 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) MachineType: LENOVO 20KGS3Y900 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-25-generic root=UUID=55cf8bc7-4727-47a8-8b30-7ad55bd24635 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.4.0-25-generic N/A linux-backports-modules-5.4.0-25-generic N/A linux-firmware1.187 SourcePackage: linux UpgradeStatus: Upgraded to focal on 2020-04-17 (3 days ago) dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KGS3Y900 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KGS3Y900 dmi.product.sku: LENOVO_MT_20KG_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug focal ** Attachment added: "test-overlay: show the zfs upperdir or workdir issue and some info" https://bugs.launchpad.net/bugs/1873917/+attachment/5357185/+files/test-overlay -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873917 Title: zfs not supported as upperdir or workdir for overlay mount To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873917/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
(updated from the comment) A workaround patch changing 90apt-sources. ** Patch added: "fix/workaround" https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+attachment/5356285/+files/fix-1872163.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872163 Title: focal chroots broken due to change in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872163] Re: focal chroots broken due to change in sources.list
Here is *a* fix/workaround that I'd expect to work for existing releases
and focal
$ diff -u /etc/schroot/setup.d/90apt-sources.dist
/etc/schroot/setup.d/90apt-sources
--- /etc/schroot/setup.d/90apt-sources.dist 2020-04-17 14:26:50.510749407
-0400
+++ /etc/schroot/setup.d/90apt-sources 2020-04-17 14:27:40.814787763 -0400
@@ -113,6 +113,13 @@
APT_COMPONENTS="$comps"
fi
+# LAUNCHPAD_SERIES comes from schroot config 'launchpad.series'
+if [ -n "$LAUNCHPAD_SERIES" ] &&
+[ -n "$APT_COMPONENTS" -o -z "$APT_POCKETS" ]; then
+echo "Setting one-line sources.list (LP: #1873507)"
+echo "deb http://archive.ubuntu.com/ubuntu/ ${LAUNCHPAD_SERIES} main
restricted universe multiverse" > "$sources"
+fi
+
if [ -n "$APT_POCKETS" ]; then
echo "setting apt pockets to 'release $APT_POCKETS' in sources.list"
awk -v pockets="$APT_POCKETS" '
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872163
Title:
focal chroots broken due to change in sources.list
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1873507] [NEW] 90apt-sources breaks sources.list in focal builds
*** This bug is a duplicate of bug 1872163 *** https://bugs.launchpad.net/bugs/1872163 Public bug reported: the file '/etc/schroot/setup.d/90apt-sources' attempts to enable 'APT_POCKETS' (release, security, updates, proposed). It attempts to change the existing /etc/apt/sources.list. sources.list in 'livecd.ubuntu-base.rootfs.tar.gz' releases before have focal an /etc/apt/sources.list with just one line like: $ tar xvzf bionic-livecd.ubuntu-base.rootfs.tar.gz --to-stdout chroot-autobuild/etc/apt/sources.list chroot-autobuild/etc/apt/sources.list deb http://archive.ubuntu.com/ubuntu/ bionic main restricted universe multiverse But focal's has a "full" /etc/apt/sources.list: $ tar xvzf focal-livecd.ubuntu-base.rootfs.tar.gz --to-stdout chroot-autobuild/etc/apt/sources.list | pastebinit chroot-autobuild/etc/apt/sources.list https://paste.ubuntu.com/p/WKJmnBmhC5/ The parsing/updating of APT_POCKETS breaks with the more complicated sources.list Here is the failure recreate: $ sbuild --dist=focal --arch=amd64 --arch-all ../out/cloud-init_20.1-10-g71af48df-0ubuntu4.dsc sbuild (Debian sbuild) 0.79.0 (05 February 2020) on crabapple +===+ | cloud-init 20.1-10-g71af48df-0ubuntu4 (amd64) Fri, 17 Apr 2020 17:22:32 + | +===+ Package: cloud-init Version: 20.1-10-g71af48df-0ubuntu4 Source Version: 20.1-10-g71af48df-0ubuntu4 Distribution: focal Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: 01launchpad-chroot: [focal-amd64] Processing config I: 01launchpad-chroot: [focal-amd64] Already up to date. I: 90apt-sources: setting apt pockets to 'release security updates proposed' in sources.list I: 90apt-sources: setting apt components to 'main universe' in sources.list I: NOTICE: Log filtering will replace 'var/run/schroot/mount/focal-amd64-21104d17-1db3-4a70-bcbd-3479c4d29227' with '<>' I: NOTICE: Log filtering will replace 'build/cloud-init-j9cjIs/resolver-pDIVK5' with '<>' +--+ | Update chroot| +--+ E: Type 'main' is not known on line 5 in source list /etc/apt/sources.list E: The list of sources could not be read. E: apt-get update failed +--+ | Summary | +--+ Build Architecture: amd64 Build Type: binary Build-Space: 0 Build-Time: 0 Distribution: focal Fail-Stage: apt-get-update Host Architecture: amd64 Install-Time: 0 Job: ../out/cloud-init_20.1-10-g71af48df-0ubuntu4.dsc Machine Architecture: amd64 Package: cloud-init Package-Time: 0 Source-Version: 20.1-10-g71af48df-0ubuntu4 Space: 0 Status: failed Version: 20.1-10-g71af48df-0ubuntu4 Finished at 2020-04-17T17:22:32Z Build needed 00:00:00, 0k disk space E: apt-get update failed ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sbuild-launchpad-chroot 0.16 ProcVersionSignature: Ubuntu 5.3.0-46.38~18.04.1-generic 5.3.18 Uname: Linux 5.3.0-46-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Apr 17 13:17:49 2020 InstallationDate: Installed on 2020-01-15 (92 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sbuild-launchpad-chroot UpgradeStatus: Upgraded to focal on 2020-04-17 (0 days ago) ** Affects: sbuild-launchpad-chroot (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal ** This bug has been marked a duplicate of bug 1872163 focal chroots broken due to change in sources.list -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1873507 Title: 90apt-sources breaks sources.list in focal builds To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1873507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1870346] Re: Wifi configuration
In case it wasn't clear above... I don't personally believe that specifying "renderer" should be required or even allowed. Its a hack. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1870346 Title: Wifi configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1870346/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1870346] Re: Wifi configuration
In my opinion, the provider of network configuration to an instance (image) should not have to "know" that the image uses networkd, NetworkManager, ifupdown, wikid They just declare "make the networking like this". The operating system inside implements API. Anything else just cannot work. For example, a cloud provider that implements "bring your own image" can't possibly know what an image uses to configure its networking. cloud-init should either do the right thing, or error saying "Cannot implement network configuration." -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1870346 Title: Wifi configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1870346/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1866563] Re: cloud-init expects sshd service to be available in images should be in the package deps
It seems really like this is Recommends. Its not a hard depends. On Mon, Mar 9, 2020 at 2:55 PM Ryan Harper <1866...@bugs.launchpad.net> wrote: > > In particular, user passed in cloud-config for augmenting ssh > configuration in the guest (setting user ssh keys) however, it was > unknown that the centos/8/cloud image did not have sshd installed. > > If I'm building a template and install cloud-init; I can see either > path, cloud-init does not *require* it to function, but one of the most > common tasks for cloud-init does expect that there is an ssh service > when users supply ssh related config. > > >From a packaging perspective, seems reasonable to depend on it. > Alternatively, for minimal images, cloud-init does not *directly depend > on it, but users can't know before launching an image that if they > supply ssh config, it wont work on an image because sshd is not present > but cloud-init is? > > -- > You received this bug notification because you are subscribed to cloud- > init in Ubuntu. > https://bugs.launchpad.net/bugs/1866563 > > Title: > cloud-init expects sshd service to be available in images should be in > the package deps > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1866563/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1866563 Title: cloud-init expects sshd service to be available in images should be in the package deps To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1866563/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
@Mohammed, Thank you for your help. I dont think we need anything else from you. Scott On Mon, Mar 23, 2020 at 2:10 PM Mohammed Sameer B <1868...@bugs.launchpad.net> wrote: > > @Scott, > > So shall I consider the issue fixed or still some troubleshooting needs > to be done? > > > Thanks > > -- > You received this bug notification because you are subscribed to cloud- > init in Ubuntu. > https://bugs.launchpad.net/bugs/1868077 > > Title: > A new feature in cloud-init identified possible datasources for this > system as:['Ec2', 'None']. However, the datasource used was: Azure > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
@Mohammed, I was hoping for /var/lib/cloud contents *before* running 'cloud-init clean'. The other logs look fine. @Other cloud-init devs, I'd like someone else to hazard a guess at what went on here. The general issue is: * very old cloud-init (0.7.9) booted on azure * migrated to ec2, still thought it was on azure * upgraded and it still happened * cloud-init clean --logs --seed and rm -Rf /var/lib/waagent fixed it. I don't see in code how the issue shoudl have occurred after upgrade. but two things stick out: a.) _is_viable_platform will attempt to log an event even if not on azure. maybe that shouldnt happen. b.) _is_viable_platform will return true even if asset_tag failed, but /var/lib/waagent/ovf-env.xml existed. that seems wrong -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
It really seem slike you still have /var/lib/waagent around. See lines in your log like: 2020-03-21 07:36:37,988 - stages.py[DEBUG]: restored from checked cache:ataSourceAzure [seed=/var/lib/waagent] For reference, could youp lease attach: tar -C /var/lib/ -cvf var-lib-cloud.tar.gz cloud/ The instance should *not* have "restored from checked cache". The above will help us to see what went wrong there. And then you should do: rm -Rf /var/lib/waagent cloud-init clean --logs --seed then try again. And for On Sat, Mar 21, 2020 at 3:50 AM Mohammed Sameer B <1868...@bugs.launchpad.net> wrote: > > @Scott, > > I have removed walinuxagent and deleted /var/lib/waagent. But when I > restart the server, again I am facing the issue. I have attached cloud- > init collect-logs output for our reference. > > > Thanks > > ** Attachment added: "cloud-init.tar.gz" > > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+attachment/5339604/+files/cloud-init.tar.gz > > -- > You received this bug notification because you are subscribed to cloud- > init in Ubuntu. > https://bugs.launchpad.net/bugs/1868077 > > Title: > A new feature in cloud-init identified possible datasources for this > system as:['Ec2', 'None']. However, the datasource used was: Azure > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
@Mohammed, the cloud-init.log clearly shows cloud-init still using the Azure datasource due to the presense of /var/lib/waagent I would suggest removing that directory. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
I'd suggest making the changes, and inserting a ssh key that you have access to into root. Then reboot and see what happens. You should then be able to log in and debug a bit, run 'cloud-init collect-logs' and post here. On Fri, Mar 20, 2020 at 10:20 AM Mohammed Sameer B <1868...@bugs.launchpad.net> wrote: > > @Scott, > > I have the image of server before making that change. > > So Can you assist me on how to fix cloud-init data source > identification? > > > Thanks > > -- > You received this bug notification because you are subscribed to cloud- > init in Ubuntu. > https://bugs.launchpad.net/bugs/1868077 > > Title: > A new feature in cloud-init identified possible datasources for this > system as:['Ec2', 'None']. However, the datasource used was: Azure > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
@Mohammed, If you are using an EBS root, then you can detach the volume and attach to another instance and then collect logs from it. I might suggest that you make a snapshot, then change the volume to and add an ssh key to root's ssh keys and then re-attach that volume to the original instance and start it back up. Its hard for me to guess what might be wrong though at this point. Scott -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
@Mohammed, I would do a 'rm -Rf /var/lib/waagent' before migrating future images. And I'd suggest that you can probably just 'touch /var/lib/cloud/instance/warnings/.skip'. But your system is in a wierd state. @Cloud-init devs, What happened here was: a.) instance booted on Azure b.) instance captured and moved to EC2 c.) new instance on EC2 had: 1. ds-identify recognize that it was on EC2 2. python code path use the old Azure content (seed=/var/lib/waagent). d.) since c.1 and c.2 differed, cloud-init complained. Added to that set of events was that this cloud-init iidentifies itself as 0.7.9. cloud-init version 17.1 (17.1-17-g45d361cb-0ubuntu1_16.04.1) was released to xenial in October of 2017. So this system has not been updated in at least 2 years. I'm not sure if this is bug is still present or not, and I believe that it would not be seen if ds-identify was enabled. But it does seem that in this old version there is discrepency in ds-identify detection of azure and the python path. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1868077] Re: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure
Hi Mohammed, Please attach the output of 'cloud-init collect-logs' and then set this back to New. Thanks. ** Changed in: cloud-init (Ubuntu) Status: New => Incomplete ** Tags added: dsid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868077 Title: A new feature in cloud-init identified possible datasources for this system as:['Ec2', 'None']. However, the datasource used was: Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1868077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1825155] Re: lxc-start crashed with SIGSEGV in cgfsng_payload_create()
I bumped into this yesterday on bionic. The commit 1e04bb71da3ed829 [1] reports to fix it. [1] https://github.com/lxc/lxc/commit/1e04bb71da3ed829761ae8c729c3d021a6a709df Hopefully there will be a 3.0.x update to bionic at some point. ** Also affects: lxc (Ubuntu Focal) Importance: Medium Status: Fix Committed ** Also affects: lxc (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: lxc (Ubuntu Focal) Status: Fix Committed => Fix Released ** Changed in: lxc (Ubuntu Eoan) Status: New => Fix Released ** Changed in: lxc (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1825155 Title: lxc-start crashed with SIGSEGV in cgfsng_payload_create() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1825155/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1866563] Re: cloud-init expects sshd service to be available in images should be in the package deps
It'd also be sane to just *not* depend on sshd. cloud-init doesn't really depend on sshd to my knowledge, but probably does throw some warnings or not function perfectly if its not there. nothing about cloud-init should require sshd though. it'd be good to run without it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1866563 Title: cloud-init expects sshd service to be available in images should be in the package deps To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1866563/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864107] Re: ssh-import-id broken on Focal
** Changed in: ssh-import-id Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864107 Title: ssh-import-id broken on Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ssh-import-id/+bug/1864107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864107] Re: ssh-import-id broken on Focal
** Changed in: ssh-import-id Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864107 Title: ssh-import-id broken on Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ssh-import-id/+bug/1864107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864107] Re: ssh-import-id broken on Focal
** Changed in: ssh-import-id Status: New => Confirmed ** Changed in: ssh-import-id Assignee: (unassigned) => Dave Jones (waveform) ** Changed in: ssh-import-id Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864107 Title: ssh-import-id broken on Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ssh-import-id/+bug/1864107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1834875] Re: cloud-init growpart race with udev
this seemed to "just work" for me. http://paste.ubuntu.com/p/93dWDPZfZT/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1834875] Re: cloud-init growpart race with udev
a.) I gave the wrong link. ugh. It should have been: https://code.launchpad.net/~smoser/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/379774 b.) the fixed link to 'a' probably makes more sense now. But basically you need a newer cloud-initramfs-tools to adjust for the fact that growpart needs flock now. cloud-initramfs-tools I believe is still a "native package". So it just has the packaging along side c.) you can use new-upstream-snapshot. cloud-utils is set to use the same basic workflow as cloud-init or curtin. I'm OK to upload cloud-initramfs-tools and also cloud-utils, but I think in both cases it makes sense to get someone from server team to do it. Just to have someone other than myself having done it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1834875] Re: cloud-init growpart race with udev
The fix is in cloud-utils upstream now. Still to do: a.) review/merge cloud-initramfs-tools pull request https://code.launchpad.net/~raharper/cloud-utils/+git/cloud-utils/+merge/379177 b.) upload cloud-initramfs-tools to focal c.) upload cloud-utils to focal d.) any SRU the order of 'b' and 'c' are not *terribly* important, because I do not think that there are many users of 'growroot' at this point. That said... the change to cloud-utils *does* break cloud-initramfs-tools so they should be done in that order. I personally do not really want to babysit these getting in. Can someone else sign up for that? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1834875] Re: cloud-init growpart race with udev
** Changed in: cloud-initramfs-tools (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
