| === diddledan0 is now known as diddledan | ||
| === ben_r_ is now known as ben_r | ||
| jbicha | doko: Ubuntu's containerd currently needs this delta: https://launchpad.net/ubuntu/+source/golang-defaults/2:1.13~1ubuntu1 (as seen on the NBS report) | 01:20 |
|---|---|---|
| === helio|afk is now known as heliocastro | ||
| suniel17 | Hi all, I have a board based on Rockchip RK3399 64-bit SOC ARMv8A.I have installed Ubuntu focal fossa with LXDE Display manager. I am bootingvia NVMe SSD, the board loses power(powered off) automatically duringthe boot process. found out that this is happenning when systemd-udevd is setting up ubuntu user space (loading rules from udev/rules.d).Can | 06:32 |
| suniel17 | any one please comment on this issue and suggest how to fix the problem. Thanks | 06:32 |
| LocutusOfBorg | vorlon, xnox can I please have initramfs-tools merged? the merge is trivial, I need some shellcheck test fixes | 09:31 |
| LocutusOfBorg | http://launchpadlibrarian.net/478820694/initramfs-tools_0.136ubuntu6_0.136ubuntu7.diff.gz | 09:59 |
| LocutusOfBorg | for now I went to this ^^ | 09:59 |
| theloudspeaker | Can someone confirm this: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1877553 | 10:17 |
| ubottu | Launchpad bug 1877553 in gdm3 (Ubuntu) "wifi gets automatically disabled when screen is locked and can be enabled only after a reboot." [Undecided,New] | 10:17 |
| theloudspeaker | Was there in 19.10 too. | 10:17 |
| ackk | juliank, hi, replied to your comments on https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/383411. I guess I should drop the focal MP as that's not the way to SRU it? | 10:23 |
| juliank | ackk: right, you probably want an SRU bug and then a 0.6.1 for focal (or 0.7~ubuntu20.04.1, meh) | 10:35 |
| juliank | ackk: I think I need to consult with vorlon on installing snaps without /ubuntu-$series branches, as I think the same rationale we have for seeded snaps also applies to deb2snap transitional packages. | 10:36 |
| juliank | ackk: Per-release branches should always be opened for a new release at archive opening (or earlier) | 10:37 |
| ackk | juliank, ok, yeah we're not entirely sure about the policy, the reason for the fallback is that if we don't do that, we'll need to create /ubuntu-XX.YY branches for all tracks for each ubuntu release | 10:38 |
| juliank | ackk: The thing is that you also don't want someone to install foo/ubuntu-20.04 in bionic, then move them to mainline foo branch in 20.10 because there is no foo/ubuntu-20.10 branch | 10:38 |
| juliank | and then later when they reach 22.04 they are still on foo, when you'd probably want them back on foo/ubuntu-22.04 | 10:39 |
| juliank | ackk: I don't think opening and closing the ubuntu-XX.YY branches is a huge effort, though I have not done it | 10:39 |
| juliank | AFAIUI, It's like a one-time thing you do at archive opening and then you don't need to worry about it | 10:39 |
| ackk | juliank, sure, it's more that we have to do it for multiple tracks I guess | 10:40 |
| ackk | I guess you need to have tracks for all LTS->LTS+1 releases for all maas versions that get releases between LTS and LTS+1 | 10:41 |
| ackk | juliank, which becomes quite a maintenance burden if you have to later keep them open | 10:42 |
| ackk | although I guess since maas is maintained by canonical there's no real reason to have different versions in 2.7/stable/ubuntu-20.04 and 2.7/stable | 10:43 |
| juliank | ackk: I thought you close them, and snapd automatically falls back to the 2.7/stable one until it sees something published in 2.7/stable/ubuntu-20.04, so there is no overhead until you have to do it for some reason | 10:45 |
| juliank | Its just giving you that option to publish a snap specifically for 20.04, does not mean you have to make use of it | 10:45 |
| ackk | juliank, right. I was talking about the overhead of keeping them open if you need (as you'll eventually end up with a lot of them. but I think we basically never care about having /ubuntu-X.Y open | 10:46 |
| ackk | juliank, out of curiosity, does d-r-u move all snaps across /ubuntu-$release channels, or just the seeded ones? | 12:25 |
| juliank | ackk: I've not looked at what it does | 12:53 |
| ogra | ackk, how would it do that for snadom snaps ? not all snaps have an /ubuntu-$release channel | 12:58 |
| ogra | *random | 12:58 |
| ackk | ogra, not all snaps. I was wondering if d-r-u would look at all snaps currently tracking /ubuntu-$release and move them to /ubuntu-$release+1 | 13:14 |
| ackk | well, or whatever you're upgrading to | 13:14 |
| ackk | ogra, IOW if there's an assumption that if you'r on an /ubuntu-* branch, one will exist for the target release | 13:15 |
| ackk | is there a documented policy about this somewhere? | 13:15 |
| ogra | i know there is such an assumption ... for all canonical maintained official snaps (i.e. snap-store, livepatch ...) | 13:15 |
| ogra | but i have also no idea if the upgrader switches you over (though i would expect so) | 13:16 |
| ackk | ogra on all risks, or just stable? | 13:16 |
| ogra | i think just stable | 13:17 |
| ogra | $ snap info snap-store|grep tracking | 13:17 |
| ogra | tracking: latest/stable/ubuntu-20.04 | 13:17 |
| ogra | thats an upgraded system ... (16.04->18.04->20.04) | 13:17 |
| ackk | ogra, so, groovy gets opened, expectation is that /ubuntu-20.10 are created for all tracks of a canonical-maintained snap | 13:18 |
| ackk | ? | 13:18 |
| ackk | ogra or just current track onwards? | 13:19 |
| ogra | heh, good question | 13:19 |
| ackk | I guess it would have to be all, if I'm on 2.7/stable/ubuntu-20.04 and upgrade to groovy I'd get to 2.7/stable/ubuntu-20.10, right? | 13:21 |
| ackk | even if by 20.10 2.8 is released and it's the default track | 13:21 |
| ackk | ogra, and I haven't even mentioned epochs :) | 13:23 |
| bswartz | Anyone know where I can find the current maintainer of the open-iscsi package? | 13:25 |
| ahasenack | bswartz: ubuntu doesn't have the concept of specific maintainers, you are better off checking the changelog file for recent entries | 13:26 |
| ahasenack | see if there is a pattern | 13:27 |
| ahasenack | bswartz: that being said, https://launchpad.net/ubuntu/+source/open-iscsi hints that the ubuntu foundations team is its owner | 13:27 |
| bswartz | Or do I need someone who works for Canonical to press the button? | 13:28 |
| bswartz | I also want this fix to go into Debian, but one step at a time | 13:29 |
| ackk | juliank, when you say "it's part of archive opening to create branches" do you mean as a policy, or is there something in place that does it for all seeded snaps? | 13:43 |
| juliank | ackk: there's a step in archive opening guide to ping maintainers of seeded snaps, probably should also ping maintainers of deb2snap transitioned snap I suppose | 13:43 |
| ackk | juliank, I see. should maas be on the list? (or maybe it is already?) | 13:44 |
| juliank | I think this is a broader policy question that needs to be discussed in a broader, less real-time forum | 13:44 |
| juliank | I think maas is a unicorn of sorts wrt seeding, but not sure | 13:45 |
| juliank | The deb was seeded, but maas was then unseeded | 13:46 |
| juliank | but as I said, I think it makes sense to apply the same rules to deb2snap transitional packages as for seeded snaps | 13:46 |
| juliank | and hence, that also involves pinging the relevant people at archive opening | 13:47 |
| juliank | ackk: are you subscribed to ubuntu-devel? | 13:48 |
| juliank | ackk: I figure i'd write an email | 13:48 |
| ackk | juliank, I don't think I am | 13:49 |
| juliank | I'll use a CC then | 13:50 |
| ackk | juliank, I am now :) | 13:52 |
| ackk | at least, I think | 13:52 |
| xnox | ackk: have you seen https://wiki.ubuntu.com/UbuntuSeededSnaps ? | 13:54 |
| irreleph4nt | Hi. Have any issues with booting 20.04 over the network (iPXE) been brought to your attention yet? I found the following but it's marked as fixed: https://bugs.launchpad.net/subiquity/+bug/1866775 | 13:55 |
| ubottu | Launchpad bug 1866775 in Ubuntu on IBM z Systems "subuquity installation on s390x fails (zVM and LPAR)" [Critical,Fix released] | 13:55 |
| ackk | xnox, I think I've seen it in the past, anything specific you're pointing out? | 13:55 |
| irreleph4nt | The problem I am having is that booting 20.04's kernel and initrd fails with "Unable to find a live file system on the network" | 13:56 |
| irreleph4nt | Booting the 20.04 squashfs with a kernel and initrd from 1910 however works. So the problem seems to be with those 2004 ships with | 13:57 |
| irreleph4nt | This is on amd64 BTW | 13:57 |
| juliank | xnox: maas is not a seeded snap, but it is transitioning a formerly seeded deb to a snap | 13:58 |
| juliank | Anyway, my email is complete | 13:59 |
| juliank | I shall send it | 13:59 |
| juliank | I wish I could send from my @ubuntu.com address, but gmail does not let me | 14:00 |
| juliank | developers should have mail | 14:00 |
| juliank | :D | 14:00 |
| ogra | gmail lets you if you set up an alias for it | 14:03 |
| juliank | xnox: Maybe we should just seed all snaps that are deb2snap transition targets without actually installing them anywhere | 14:03 |
| juliank | ogra: Well, my personal one does, but canonical.com one does not | 14:03 |
| ogra | (unless you send from canonicals gmail i guess ... never used that) | 14:03 |
| ogra | yeah ... | 14:03 |
| juliank | ogra: I need to resplit my email accounts at some point | 14:04 |
| ogra | i'm using IMAP over here ... | 14:04 |
| juliank | The plan was to split email into canonical | foss | personal, rather than canonical + ubuntu | personal + debian | 14:04 |
| ackk | juliank, ftr gmail is also telling me that it can't verify that your address is actually valid, which seems weird... | 14:04 |
| ackk | juliank, thanks for the email, btw | 14:04 |
| juliank | ackk: It's probably because it was resent by the mailing list,rather than directly from the server | 14:05 |
| ogra | yeah, sounds sane ... i split mine into two .. canonical| all-other | 14:05 |
| === heliocastro is now known as helio|afk | ||
| ahasenack | tjaalton: hi, any plans to update sssd's source format to 3.0 quilt? | 14:32 |
| xnox | juliank: my gmail sends emails from @ubuntu.com | 14:44 |
| xnox | (from webui) | 14:44 |
| xnox | irreleph4nt: hi, the bug you point to has nothing to do with amd64 | 14:45 |
| xnox | irreleph4nt: are you booting server or desktop? and what is your full commandline? | 14:45 |
| irreleph4nt | xnox, I am booting amd64 Desktop. Let me get you the cmdline real quick | 14:46 |
| xnox | irreleph4nt: to boot amd64, I expect something like: ip=dhcp url=http://releases.ubuntu.com/focal/ubuntu-20.04-live-server-amd64.iso for server | 14:46 |
| xnox | irreleph4nt: to desktop i expect something like: ip=dhcp url=http://releases.ubuntu.com/focal/ubuntu-20.04-desktop-amd64.iso | 14:47 |
| xnox | you can also use https i think as well. | 14:47 |
| xnox | irreleph4nt: also would be nice to see what arguments you used with 19.10 release, vs the 20.04 LTS release | 14:47 |
| irreleph4nt | xnox, the following works just fine for 19.10 but as said earlier fails for 20.04: | 14:51 |
| irreleph4nt | "vmlinuz initrd=initrd root=/dev/nfs boot=casper netboot=nfs nfsroot=192.168.0.8:/var/www/html/pxe/live/ubtu2004/ locale=de_DE.UTF-8 quiet splash ip=dhcp" | 14:51 |
| irreleph4nt | The only other arguments in the iPXE config point to the vmlinuz and initrd of 20.04 | 14:51 |
| irreleph4nt | the folder this config points to obviously contains an extracted 20.04 Desktop iso | 14:52 |
| xnox | irreleph4nt: ok, so you are using nfs mount (btw you don't have to, http is usually faster) | 14:56 |
| xnox | irreleph4nt: can you please check if the uuids match? i.e. | 14:57 |
| xnox | irreleph4nt: i.e. what is $ cat /var/www/html/pxe/live/ubtu2004/.disk/casper-uuid-generic | 14:58 |
| xnox | and what is uuid in the initrd? | 14:58 |
| irreleph4nt | how do I find the uuid in initrd? | 14:58 |
| xnox | one sec. | 14:59 |
| xnox | temp=$(mktemp -d) | 15:01 |
| xnox | unmkinitramfs /mnt/casper/initrd $temp | 15:01 |
| xnox | cat $temp/main/conf/uuid.conf | 15:01 |
| xnox | 7e9d6f34-8cf6-41a3-9cbd-7532e21aedc0 | 15:01 |
| xnox | so the initrd that is served over ipxe should contain above uuid.conf & it should match the nfs mount's .disk/casper-uuid-generic | 15:02 |
| xnox | irreleph4nt: because the kernel&initrd you boot, must match the iso you try to nfs mount, because it must have all the right runtime kernel modules. If the two don't match, it means that you have missmatched vmlinuz&initrd vs the .iso you are trying to boot. | 15:02 |
| xnox | irreleph4nt: sometimes that is intentional, in case you want to like modify your iso. In that case you can pass kernel cmdline argument "ignore_uuid" => but then your installs might fail. | 15:03 |
| xnox | irreleph4nt: are you sure that the vmlinuz & initrd that ipxe is serving to boot, are the identical ones as the ones in /var/www/html/pxe/live/ubtu2004/casper/{initrd,vmlinuz} ? | 15:04 |
| irreleph4nt | xnox, unless my brain malfunctioned, I am 90% sure I copied those from the same loop mount of the iso. Just getting you the uuids.... gimme one sec | 15:06 |
| alkisg | lsinitramfs initrd.img|grep casper, should tell you if it has casper | 15:07 |
| xnox | alkisg: that's not sufficient to distinguish 19.10 vs 20.04 | 15:08 |
| xnox | irreleph4nt: you may have copied the right ones, but like your ipxe is for some reason serving the old one. | 15:08 |
| alkisg | I mean, in case the initrd.img didn't come from an iso, but it came from some local installation, and doesn't have casper | 15:08 |
| irreleph4nt | Okay, so I found one potential problem: the .disk folder does not exist at the nfsroot | 15:08 |
| irreleph4nt | let me nonetheless check the uuid in initramfs | 15:08 |
| xnox | irreleph4nt: you can also boot with "break=top" which will give you shell inside the initrd, and then you can do just $ cat conf/uuid.conf | 15:09 |
| tjaalton | ahasenack: probably should | 15:09 |
| ahasenack | :) | 15:09 |
| xnox | irreleph4nt: right "cp /mnt/*" will not copy .disk, ideally you should rsync or mount stuff at /var/www/html/pxe/live/ubtu2004/ | 15:09 |
| xnox | like $ cp -a /mnt /var/www/html/pxe/live/ubtu2004/ | 15:10 |
| xnox | irreleph4nt: did the 1910 one have .disk dir? | 15:10 |
| xnox | irreleph4nt: i wonder, if I should be printing more help on how to troubleshoot when we fail to find network mounts. | 15:10 |
| xnox | irreleph4nt: we really do need .disk (cause we fetch a lot of configuration from there, which id "dynamic") | 15:12 |
| irreleph4nt | xnox, so I just tried your sequence from above | 15:13 |
| irreleph4nt | at step two tho I am getting "unkminitramfs not found" | 15:13 |
| irreleph4nt | unmk* | 15:13 |
| xnox | irreleph4nt: i see typo | 15:13 |
| xnox | oh | 15:13 |
| xnox | irreleph4nt: it's a tool shipped on ubuntu by default. from the initramfs-tools package. | 15:14 |
| xnox | initramfs-tools-core that is | 15:14 |
| irreleph4nt | well, my stock initramfs (as copied from the disk image) tells me it can't find it :/ | 15:14 |
| irreleph4nt | let me check the spelling again | 15:14 |
| xnox | irreleph4nt: hm? unmkinitramfs is to be used on a regular host system, to unpack initramfs. We don't ship that, inside the initrd. | 15:15 |
| xnox | irreleph4nt: if you have unpacked the initrd, or have dropped to shell inside the initrd, simply cat conf/uuid.conf | 15:15 |
| xnox | irreleph4nt: if you want we can google hangout and i can share my screen to show you things. | 15:16 |
| irreleph4nt | xnox, ah, now I get it | 15:16 |
| xnox | =) sorry if i gave confusing instructions | 15:17 |
| irreleph4nt | Okay. I just compared the UUID from within initrd to the UUID in the iso's .disk file. Those two match | 15:18 |
| irreleph4nt | So is the issue that my nfsroot does not contain a .disk folder then? | 15:18 |
| xnox | yes | 15:18 |
| xnox | it should | 15:18 |
| xnox | btw, if i were you i would switch from nfs to http, i.e. | 15:18 |
| irreleph4nt | xnox, well I switched from http to nfs actually | 15:18 |
| irreleph4nt | reason being that PXE requires HTTP instead of HTTPS | 15:19 |
| irreleph4nt | which I can't serve easily in my local network | 15:19 |
| xnox | I.e. vmlinuz initrd=initrd url=http://192.168.0.8/ubuntu-20.04-desktop-amd64.iso locale=de_DE.UTF-8 quiet splash ip=dhcp | 15:19 |
| xnox | irreleph4nt: fair enough. | 15:20 |
| irreleph4nt | xnox, just checked: 1910's nfsroot also does not have a .disk folder | 15:20 |
| irreleph4nt | but works flawlessly | 15:20 |
| xnox | irreleph4nt: so yes, recreate /var/www/html/pxe/live/ubtu2004/ with better copy of all the hidden files. | 15:20 |
| irreleph4nt | color me surprised | 15:20 |
| xnox | irreleph4nt: i may have added the uuid validation for network mounts, and fixed a bug, where we somtimes skipped it =/ | 15:20 |
| irreleph4nt | :D | 15:21 |
| irreleph4nt | okay, let me google the correct rsync command real quick | 15:21 |
| xnox | irreleph4nt: like you can do $ sudo mount -o bind ubuntu-20.04-desktop-amd64.iso /var/www/html/pxe/live/ubtu2004/ | 15:21 |
| xnox | or yeah, rsync / cp -a should do it. | 15:21 |
| xnox | irreleph4nt: but like without .disk you can't open release notes, bug reports fail to say what image you used to install it with, etc. | 15:22 |
| xnox | or like $ cp -r /mnt/.disk /var/www/html/pxe/live/ubtu2004/ | 15:23 |
| irreleph4nt | that's the cp command I used earlier | 15:25 |
| irreleph4nt | just managed to mount the iso in the right folder as a loop device | 15:25 |
| irreleph4nt | now rebooting | 15:25 |
| irreleph4nt | xnox, no dice, still getting the same error | 15:28 |
| xnox | irreleph4nt: can you pastebin / picture the whole output you see? | 15:29 |
| xnox | Full error and everything before it? | 15:29 |
| irreleph4nt | that'll take a moment | 15:29 |
| xnox | irreleph4nt: also please open a bug on launchpad against Ubuntu, package ubiquity. | 15:29 |
| xnox | irreleph4nt: I might need to go soon, but don't want to loose contact. | 15:30 |
| irreleph4nt | will you be notified as I create the bugreport? | 15:30 |
| irreleph4nt | xnox, solved! | 15:42 |
| irreleph4nt | I'll still create the bugreport tho | 15:42 |
| xnox | irreleph4nt: solved? | 15:45 |
| xnox | irreleph4nt: yes, as a ubiquity / casper / initrd developer for Ubuntu, i better be notified =) | 15:46 |
| irreleph4nt | xnox, mounting the iso to the right folder wasn't enough, as during boot that triggers a "mount: permission denied" error | 15:46 |
| irreleph4nt | and - in a not so helping fashion - ends up throwing the same error message at the very end that I quoted earlier | 15:47 |
| irreleph4nt | so at first I thought the issue was still the same | 15:47 |
| irreleph4nt | I now rsynced the iso contents to the folder, which includes .disk | 15:47 |
| irreleph4nt | and now it works | 15:47 |
| vorlon | juliank: what packages are doing deb2snap transitions that aren't also seeded, or which shouldn't follow the policy for per-series channels? | 15:52 |
| irreleph4nt | now all I need to do is figure out how to use launchpad correctly to actually create a bug, instead of always being routed to the ubuntu docs page :S | 15:52 |
| juliank | vorlon: maas was seeded as a Deb, but is not seeded as a snap | 15:52 |
| juliank | I'm not sure if there are others | 15:53 |
| juliank | I think they should also follow the seeded snaps policy | 15:53 |
| xnox | irreleph4nt: there is magic skip that URL option | 15:53 |
| xnox | irreleph4nt: which the help page tells you about. | 15:53 |
| juliank | vorlon: see ubuntu-devel email | 15:53 |
| vorlon | juliank: ack | 15:53 |
| xnox | irreleph4nt: or use $ ubuntu-bug ubiquity => that skips all redirects too | 15:54 |
| xnox | irreleph4nt: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug?no-redirect | 15:54 |
| xnox | irreleph4nt: so, i want you to still file the bug report. To say that it was unexpected that you saw the error, and that it didn't guide you, as to how / what you are meant to fix. | 15:55 |
| irreleph4nt | thanks! I am on it now | 15:55 |
| xnox | irreleph4nt: also you can ask us to stop using .disk or like have /meta/ directory instead. Cause then, it would have been copied when you first unpacked the iso. | 15:56 |
| * xnox hates that .disk is hidden | 15:56 | |
| irreleph4nt | I'll add that as possible fixes to the report :) Ideal solution would be if no such directory would be needed to begin with | 15:57 |
| irreleph4nt | I have used many linux distros in the past and ubuntu is the only one I encountered with such a folder | 15:57 |
| xnox | irreleph4nt: hm. that's hard though. Because we ship systems that have _multiple_ of these, and we have to find the right one. | 15:58 |
| irreleph4nt | :O | 15:58 |
| xnox | irreleph4nt: for example, if you have two usb sticks plugged in, with 19.10 and 20.04 => without .disk/uuid check we boot random grub, random kernel+initrd, and use random rootfs. | 15:58 |
| irreleph4nt | that must be a pain to deal with | 15:58 |
| xnox | irreleph4nt: like random, any combination in that matrix of 3x3 | 15:58 |
| irreleph4nt | but then again, having both of these plugged in should rarely happen. Also, what you are doing there - which might be an inherent problem of using grub - is that you do the systems BIOS / EFI's work | 15:59 |
| irreleph4nt | which TBH you probably shouldn't to begin with | 15:59 |
| xnox | irreleph4nt: or like boot 20.04 live session, whilst your laptop has a 19.10 OEM recovery system with it's own .disk/uuid | 16:00 |
| irreleph4nt | it's really not ubuntu's job to figure out what disk to boot | 16:00 |
| xnox | irreleph4nt: so people do usb sticks, on servers. because they have access to remote console, and they can remotely pick the right usb stick, cause they see bios menu. | 16:00 |
| xnox | irreleph4nt: but physically they are not present in teh datacentre. | 16:00 |
| irreleph4nt | xnox, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1877618 | 16:15 |
| ubottu | Launchpad bug 1877618 in ubiquity (Ubuntu) "20.04 fails to boot via PXE (amd64)" [Undecided,New] | 16:15 |
| tjaalton | ahasenack: committed to git | 16:40 |
| ahasenack | \o/ | 16:40 |
| coreycb | hello SRU Team, could we have cinder and neutron rejected from the focal unapproved queue please? | 17:45 |
| coreycb | bdmurray: hi, do you know if the SRU team is aware of the openstack ussuri final release scheduling? | 17:46 |
| bdmurray | coreycb: No, I don't know | 17:48 |
| coreycb | bdmurray: it's not a great way to make friends so apologies in advance. let me find some background to link you to. | 17:48 |
| coreycb | bdmurray: https://lists.ubuntu.com/archives/ubuntu-release/2020-March/004911.html | 17:50 |
| bdmurray | coreycb: March 2nd? that was like *forever* ago | 17:50 |
| coreycb | bdmurray: heh, well the schedule in that first email is the part to read | 17:51 |
| coreycb | bdmurray: the part about May 19, 2020 | 17:51 |
| bdmurray | coreycb: Okay, so now I've been reminded | 17:51 |
| coreycb | bdmurray: the upstream final release is next wed and we plan to jump on it and start uploading to the focal unapproved queue. I just want to coordinate with the release team and hopefully we can get everything into focal-proposed fairly soon after. | 17:53 |
| coreycb | s/release/sru/ | 17:53 |
| bdmurray | coreycb: Its not clear to me what you are asking for. | 17:55 |
| coreycb | bdmurray: we just have a lot of packages that we need to SRU into focal for the final release of openstack ussuri | 17:56 |
| coreycb | bdmurray: and would like the SRU Team to be aware | 17:57 |
| bdmurray | coreycb: Okay, if you are looking for somebody to be available to review them then I think the thing to do would be email the team via the ubuntu-release mailing list. | 17:57 |
| coreycb | bdmurray: sure I can do that, sorry to pick on you I just know you're avail timezone wise | 17:58 |
| bdmurray | coreycb: No problem | 17:58 |
| coreycb | bdmurray: thanks | 17:58 |
| === ijohnson is now known as ijohnson|lunch | ||
| LocutusOfBorg | jamespage, hello, stuff is now depending on openstack-pkg-tools (>= 109~) | 18:40 |
| LocutusOfBorg | please merge? | 18:40 |
| === ijohnson|lunch is now known as ijohnson | ||
| vorlon | bdmurray: currently, for snap channel transitions via u-r-u, is that strictly based on a whitelist of known snaps? | 19:04 |
| bdmurray | vorlon: yes | 19:14 |
| vorlon | bdmurray: should we do this instead by introspection of what snaps are installed that are tracking ubuntu release channels? So that e.g. we don't have to update u-r-u for things like the maas snap (ubuntu-devel) | 19:15 |
| bdmurray | vorlon: marcustomlinson has redone the deb2snap transition so he might be the best person to talk about this to | 19:19 |
| vorlon | marcustomlinson: ^^ ping :) | 19:39 |
| bswartz | Hi, I'm trying to fix a bug in the open-iscsi package for Ubuntu, and I need someone to sponsor this SRU: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1877617 | 20:34 |
| ubottu | Launchpad bug 1877617 in open-iscsi (Ubuntu) "Automatic scans cause instability for cloud use cases" [Undecided,New] | 20:34 |
| bswartz | I've done most of the work required to fix this, and I'm willing to do anything else necessary to get the fixes merged | 20:35 |
| sarnold | bswartz: nice report; for the fix to be released, it'll go through the SRU process https://wiki.ubuntu.com/StableReleaseUpdates | 20:46 |
| sarnold | bswartz: one step of that is to fix the issue in the -devel release, too, so a patch for groovy would probably help speed things along | 20:46 |
| bswartz | sarnold: Okay, I can do that | 20:46 |
| bswartz | sarnold: I just realized I don't know how to upgrade to the -devel version | 21:05 |
| bswartz | I'm trying something that might work | 21:07 |
| bswartz | No it didn't work | 21:08 |
| bswartz | This is weird, because I used the installer from the groovy directory, but I ended up with focal anyways | 21:08 |
| bswartz | I'm going to flush all my caches and start over | 21:09 |
| sarnold | bswartz: do-release-upgrade -d *might* do it -- the meaning of the -d changes over the course of a release | 21:10 |
| bswartz | That ended up in a crash loop when I tried that | 21:10 |
| sarnold | ouch :( | 21:15 |
| bswartz | I might have to install from ISO | 21:15 |
| bswartz | Look like the legacy network installer doesn't work well | 21:16 |
| bdmurray | sarnold: do-release-upgrade -d will take you to groovy now | 21:50 |
| sarnold | bdmurray: cool, thanks | 21:51 |
| sarnold | bdmurray: have you seen the crash loop bswartz mentioned? | 21:51 |
| bdmurray | sarnold: no, who would upgrade to groovy? | 21:52 |
| sarnold | bdmurray: bswartz is trying to get a fix for open-iscsi sru'd into our releases, and I pointed that one of the requirements is the fix being in -devel -- and bswartz sounds thorough enough to want to test the change :) | 21:53 |
| bdmurray | I'm running a test upgrade now and it seems fine to me. | 22:06 |
| sarnold | thanks bdmurray :) | 22:07 |
| bswartz | So what I actually did, was install groovy using the network installer, but I ended up with something that appeared to be focal | 22:39 |
| bswartz | Then I tried to upgrade that to groovy, and it went all pear-shaped | 22:39 |
| bswartz | It could be that my installation automation is broken by something new in groovy, or that it doesn't work well with -devel releases | 22:40 |
| bswartz | I used http://us.archive.ubuntu.com/ubuntu/dists/groovy/main/installer-amd64/current/legacy-images/netboot/ubuntu-installer/amd64/linux and http://us.archive.ubuntu.com/ubuntu/dists/groovy/main/installer-amd64/current/legacy-images/netboot/ubuntu-installer/amd64/initrd.gz to boot up | 22:42 |
| bswartz | But those gave me focal instead of groovy | 22:42 |
| bswartz | I'm doing a manual ISO install now | 22:43 |
| bswartz | sarnold: Okay, I pushed a build for groovy to the same PPA. FWIW, it looks like there are no differences from focal | 22:56 |
| sarnold | bswartz: nice nice | 22:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!