[00:00] <rbasak> I guess the easiest way to deal with this is to port the lot :-/
[03:56] <Skuggen> Hm, the MySQL dep8 test being so slow on arm64 is a pretty general problem
[06:23] <alkisg> xnox: good morning, could LP #1840945 be caused by mkinitramfs and not by the kernel decompression code? Should I put initramfs-tools in the affects list?
[06:40]  * alkisg tests all compressions to see
[07:00] <Unit193> alkisg: How'd you find that, anywho?
[07:01] <alkisg> Unit193: I redesigned/rewrote the new ltsp, so that all its code is sent via an additional initramfs; it worked in ALL debian/ubuntu based distros/versions that I tested (like 20 of them) except eoan :)
[07:01] <alkisg> It's like putting the casper code in an extra initrd, not embedding it into a single one
[07:06] <Unit193> alkisg: I mess around with ISOs, have been for quite some time.  That broke in Eoan and I'm wondering if it's related.
[07:07] <alkisg> Unit193: sorry I didn't get which part broke and which one is related
[07:07] <Unit193> (I'm testing that now)  I got dumped to busybox, sooo.
[07:34] <alkisg> I did an extensive comparison between eoan and bionic; xz still works, gzip/bzip2 regressed, lz* never worked : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840945/comments/3
[07:38] <Unit193> alkisg: I can't remember what all I'd tried, but using gzip for initramfs didn't help.  Makes sense though.
[07:39] <alkisg> Unit193: what is the error message that you see in the initramfs? For me, only .xz works in eoan
[07:40] <Unit193> Most of the time I get no error message.  xz initramfs is the one that works?  Huh.
[07:40] <alkisg> In my case, where I either concatenate 2 initrds, or send 2 different ones, yes, xz is the only one that works in eoan; while gzip/bzip2 worked in bionic too; and lz* never worked
[07:41]  * alkisg is seeing the strange new login screen of gdm currently
[07:41] <Unit193> Cool, trying that now.
[07:43] <alkisg> Unit193: if you think I might help, `cat /proc/cmdline` when you get the busybox failure, and upload a screenshot if you're using a vm... e.g. I also had netplan issues that broke initramfs
[08:08] <Unit193> alkisg: 'file=/cdrom/preseed/xubuntu-core.seed initrd=/casper/initrd quiet splash ---'
[08:10] <alkisg> Unit193: ok, so nothing related to networking or initrd concatenation; it sounds like a different issue. Are you just trying to boot the daily .iso? How, e.g. with kvm?
[08:11] <Unit193> `kvm -m 512 -cdrom myownfile.iso`, which should be good enough to get it to boot, but alas..
[08:11] <alkisg> Unit193: ah, do try kvm -m 1024...
[08:12] <alkisg> Crazy as it sounds, I think I needed more than 512 in one case
[08:12] <Unit193> This isn't GNOME, so it should be fine.  An error I sometimes see is more related to squashfs.
[08:12] <Unit193> (But trying it anyway.)
[08:13] <alkisg> I had the problem while the initramfs decompressed; not later on when services are starting
[08:13] <Unit193> This, as noted before, isn't a daily ISO but one I mess around with.
[08:13] <Unit193> 1024 still dumped me at busybox.
[08:14] <alkisg> busybox usually states the reason, so a screenshot and/or dmesg should probably help
[08:14] <alkisg> *initramfs-tools usually states the reason...
[08:15] <alkisg> Although if it's a custom iso, it might be unrelated to #ubuntu-devel, and we should go to some other channel or use pms...
[08:17] <Unit193> https://unit193.net/dmesg.png https://unit193.net/initial.png
[08:19] <alkisg> Unit193: and if you `cat /init` you see the /usr/share/initramfs-tools/init file?
[08:20] <Unit193> Yep.
[08:20]  * alkisg is puzzled about the (initramfs) prompt of the first picture, that doesn't mention anything at all from the initramfs-tools init script
[08:20] <alkisg> Why 2 pictures? What changed to get from the first to the second one?
[08:21] <Unit193> One is initial startup, the other is, as the name indicates, `dmesg`
[08:21] <alkisg> Aaaah ok so you just didn't get to see the busybox error message because busybox cleared your screen
[08:21] <alkisg> Put `break=bottom` etc so that you get a chance to see it
[08:21] <Unit193> Removing 'quiet splash' gets me 'No root device specified.  Boot arguments must contain root='
[08:22] <alkisg> True, if there's no root= in your /proc/cmdline, it can't mount it
[08:23] <alkisg> Your boot loader (isolinux I presume) should have provided it
[08:23] <alkisg> Unit193: let's go somewhere else, I don't think this is related to #ubuntu-devel...
[08:25] <mwhudson> Unit193: do you have anything in your initrd that sets BOOT to casper
[08:26] <mwhudson> e.g. this random casperized initrd i have lying around has conf/conf.d/default-boot-to-casper.conf
[08:26] <Unit193> mwhudson: Looking at the scripts, it should pick that up.  I believe..
[08:27] <alkisg> Unit193: sorry, mwhudson is right, the casper code takes care of mounting root so root= isn't passed in live cds; i was mistaken
[08:28] <Unit193> mwhudson: Appending BOOT=casper didn't seem to assist.
[08:29] <mwhudson> Unit193: boot= not BOOT=
[08:29] <mwhudson> the other thing could be mismatched uuids but i think that fails differently
[08:30] <LocutusOfBorg> cpaelzer, #1840749 can't you just use the upstream binaries?
[08:30] <LocutusOfBorg> just to understand if it is a packaging issue, or to understand when it broke
[08:31] <LocutusOfBorg> https://forums.virtualbox.org/viewtopic.php?f=6&t=89392
[08:33] <Unit193> mwhudson: ...Welp, that worked.  Now to figure out why it's not automatically picking that up anymore.
[08:33] <Unit193> Sorry.
[08:33] <mwhudson> Unit193: heh i've spent rather too long with my head in the initramfs code lately
[08:35] <Unit193> Now I feel stupid...  Anyway, let's see if I can't get CASPER_GENERATE_UUID to work.
[08:45] <LocutusOfBorg> tjaalton, did you upload of python-yubico fail?
[08:45] <LocutusOfBorg> http://launchpadlibrarian.net/436704667/python-yubico_1.3.2-2_1.3.2-2.1.diff.gz
[08:45] <LocutusOfBorg> +X-Python-Version: >= 2.8
[08:45]  * LocutusOfBorg fixup this
[08:46] <tjaalton> fail how?
[08:46] <LocutusOfBorg> X-Python-Version: >= 2.8
[08:47] <LocutusOfBorg> I don't think doko is planning to ever upload a python2 2.8 :D
[08:47] <tjaalton> explain
[08:47] <tjaalton> ok
[08:47] <LocutusOfBorg> python-yubico-tools/amd64 unsatisfiable Depends: python:any (>= 2.8~)
[08:47] <tjaalton> I didn't touch that part
[08:47] <LocutusOfBorg> it didn't migrate in debian and ubuntu
[08:47] <cjwatson> Also note that current Debian practice is to remove the X-Python-Version header entirely
[08:47] <tjaalton> or did I
[08:47] <LocutusOfBorg> and moreover you upload contained a binary, so it won't migrate in debian because of this
[08:48] <LocutusOfBorg> tjaalton, the signature on NMU is your :)
[08:48] <LocutusOfBorg> I can drop them both and reupload as nmu
[08:48] <tjaalton> oh I did
[08:48] <tjaalton> yes please
[08:48] <tjaalton> it had to go via NEW...
[08:49] <cjwatson> https://bugs.debian.org/934861 too FYI
[08:49] <tjaalton> bah
[08:50] <RikMills> as libmysqlclient-dev is now 8.0.16-0ubuntu3, there is no way of building anything against 5.7?
[08:51] <LocutusOfBorg> thanks cjwatson I'll update to that
[09:00] <Unit193> alkisg, mwhudson: Anyway, thanks.  One way or another I'll get it to work now. :)
[09:00] <mwhudson> Unit193: np, good luck
[09:04] <alkisg> yw Unit193; /me continues struggling with COMPRESS=...
[09:05] <Unit193> alkisg: Unfortunately, I can't really help you there as I guess that never gave me issues, even though I did adjust which compressor I used.  Next up: Being able to use zstd there too. :P
[09:05] <alkisg> :)
[09:07] <Unit193> Reminds me that I need to file a bug in mkinitramfs/initramfs-tools.  If you specify a compressor that's not available, it'll silently default back to gzip.  If you use verbose it'll warn you "No ${compress} in ${PATH}, using gzip"
[09:09] <LocutusOfBorg> vorlon, haskell needs sourceful uploads, not just rebuilds
[09:11] <The_LoudSpeaker> Hey! Does ubuntu 19.04 doesn't support steam?
[09:11] <The_LoudSpeaker> A friend of mine Installed steam but when he runs it. It doesn't start.
[09:12] <The_LoudSpeaker> Any help is appreciated.
[09:12] <EoflaOE> The_LoudSpeaker: 19.10 I think should support steam. How did he install it? Best to ask in #ubuntu.
[09:12] <LocutusOfBorg> The_LoudSpeaker, is that the client with a lot of security issues and a team who bans people reporting them?
[09:12] <The_LoudSpeaker> He installed using terminal. apt install I guess.
[09:13] <LocutusOfBorg> oh and then retract... https://it.slashdot.org/story/19/08/22/211245/valve-says-turning-away-researcher-reporting-steam-vulnerability-was-a-mistake
[09:13] <LocutusOfBorg> nice
[09:13] <The_LoudSpeaker> LocutusOfBorg: ?
[09:13] <LocutusOfBorg> The_LoudSpeaker, their bug-bounty program is scary
[09:13] <LocutusOfBorg> one person reported a security vulnerability and got banned instead of rewarded
[09:13] <The_LoudSpeaker> Lol!
[09:13] <LocutusOfBorg> so he gave a 0 day to the world a few days ago
[09:14] <LocutusOfBorg> https://it.slashdot.org/story/19/08/21/1928259/researcher-publishes-second-steam-zero-day-after-getting-banned-on-valves-bug-bounty-program
[09:15] <xnox> alkisg:  well append works for me.....
[09:16] <xnox> alkisg:  but i also failed to see any benefits to lz4 =/
[09:16] <LocutusOfBorg> The_LoudSpeaker, how did he install it?
[09:16] <LocutusOfBorg> what happens if he runs from command line?
[09:16] <alkisg> xnox: how are you testing?
[09:16] <LocutusOfBorg> wget http://repo.steampowered.com/steam/archive/precise/steam_latest.deb
[09:16] <LocutusOfBorg> this one might work
[09:16] <The_LoudSpeaker> Okay. I will try it in a bit and let you know.
[09:17] <xnox> alkisg:  bare metal reboots
[09:17] <xnox> alkisg:  so a lot more ram at least
[09:18] <LocutusOfBorg> The_LoudSpeaker, and tell him to use a VM, otherwise somebody might hack his laptop LOL
[09:18] <alkisg> xnox: no I mean, are you using the cpio date.img that I mentioned in the bug report? And cat initrd.lz4 date.img > initrd.img ?
[09:18] <cpaelzer> LocutusOfBorg: yes I can and will use the upstream binaries
[09:18] <xnox> alkisg:  as i commented on your bug report, the lz4 call you do is invalid.
[09:18] <The_LoudSpeaker> We have a strong firewall. LocutusOfBorg
[09:18] <cpaelzer> didn't know they are provided
[09:18] <alkisg> xnox: ah, I wasn't notified yet; refreshing/reading...
[09:19] <LocutusOfBorg> thanks cpaelzer , it might be really trivial to bisect, avoiding lots of rebuilds
[09:19] <LocutusOfBorg> The_LoudSpeaker, it was a joke, I don't really care :D
[09:19] <alkisg> xnox: so the additional initrd needs to be compressed using the same algorithm? Can't it be a cpio with no compression?
[09:20] <The_LoudSpeaker> LocutusOfBorg: same here.
[09:20] <xnox> alkisg:  kernel only knows how to read certain formats of lz4, which is not the default.
[09:20] <alkisg> xnox: date.img isn't lz4; it's cpio; I'm not compressing it
[09:20] <xnox> alkisg:         -l     Use Legacy format (typically for Linux Kernel compression)
[09:20] <xnox>               Note : -l is not compatible with -m (--multiple) nor -r
[09:20] <xnox> alkisg:  well, your bug description says you are.....
[09:21] <alkisg> xnox: I mean in my tests in #3
[09:21] <xnox> # echo date.txt | cpio -oH newc | lz4 > date.img => will never work
[09:21] <alkisg>  echo date.txt | cpio -oH newc > date.img
[09:21] <LocutusOfBorg> The_LoudSpeaker, it might be premature to run valve on devel systems, unless you know how to debug issues
[09:21] <LocutusOfBorg> 19.10 is not even released yet
[09:21] <LocutusOfBorg> still under development, and valve team I doubt are caring right now about it
[09:21] <xnox> alkisg:  but how was initrd.lz4 created? with or without -l ?
[09:21] <LocutusOfBorg> and I also doubt any ubuntu developer is caring about fixing it :)
[09:22] <LocutusOfBorg> I might care if it breaks on 18.04 :D
[09:22] <alkisg> xnox: with update-initramfs -u; whatever code that has, I believe should be fine
[09:22] <The_LoudSpeaker> LocutusOfBorg: ummm what valve? Can't get the context here.
[09:22] <xnox> alkisg:  depends on the release and if the tools were installed ;-)
[09:22] <alkisg> xnox: I changed COMPRESS= and ran update-initramfs -u for each case; it's yesterday's eoan build
[09:22] <xnox> alkisg:  mixed compression i would expect to work, because early initrds are all uncompressed
[09:22] <LocutusOfBorg> The_LoudSpeaker, steam/valve, same thing
[09:22] <alkisg> The initial lz4 was the one from the live cd, I didn't re-generate it
[09:23] <LocutusOfBorg> valve is the corporation providing steam
[09:23]  * LocutusOfBorg can say that his ubuntu 18.04LTS with steam works
[09:23] <xnox> alkisg:  why are you using a livecd initrd?
[09:23]  * LocutusOfBorg starts a game and blames The_LoudSpeaker for this!
[09:23] <alkisg> xnox: I'm going to test "same compression", which I haven't tested in #3, but even if that works, it doesn't help ltsp much as we'd need one ltsp.img image per chroot then...
[09:23] <xnox> alkisg:  what are you doing anyway?
[09:24] <alkisg> xnox: I rewrote a netbooting software called ltsp.org; the new technique is to send all the netbooting code as an additional initramfs, from ipxe or grub or wherever
[09:25] <alkisg> But either "second initramfs" or "concatenated initramfs" didn't work in eoan, while it worked anywhere else (tried 20 distro/versions from jessie and 16.04 to recent versions)
[09:25] <The_LoudSpeaker> LocutusOfBorg: ohh! Yeah forgot steam is provided by valve.
[09:25] <The_LoudSpeaker> Also, I haven't really tried steam on ubuntu myself. This is the first time I am(we are) trying. Coz a couple of days ago windows gave us a bigg BT.
[09:26] <Unit193> mwhudson: The mismatch uuid is 'unable to find a medium containing a live filesystem', isn't it? :)
[09:26] <mwhudson> Unit193: yes, that sounds like it
[09:26] <alkisg> xnox: if you plan to revert from lz4 to gzip, then ltsp isn't affected and we can postpone this issue for a later release... :)
[09:27] <Unit193> mwhudson: So yes, the issue I fixed tonoght I'd already fixed, but in doing so "fixed" nothing as I got that and mistook it for a similar issue.  Coolio!
[09:41] <alkisg> xnox: thanks; indeed lz4+lz4 or gzip+gzip work fine; it's lz4+cpio that have the issue. Where would that bug be, in the kernel decompression code or in mkinitramfs?
[10:13] <xnox> alkisg:  i do not know, but it's unlikely to be mkinitramfs. especially for the uncompressed cased.
[10:13] <xnox> alkisg:  you could try prepending, i.e. cpio+lz4
[10:13] <xnox> alkisg:  as that is how early initrd works
[10:13] <alkisg> xnox: ty, trying
[10:17] <alkisg> xnox: that indeed works! The mixed compression issue is still there but LTSP isn't affected anymore. Thanks again :)
[10:45] <xnox> alkisg:  yeah early initrd (ie. prepend uncompressed) is a kernel initrd implementation feature and should work (that's how microcode loading works) mixed compression initrds is interesting, and i would call it a linux kernel feature request, as initramfs-tools doesn't create those by default (it only does (multiple uncompressed) + 1 single compressed)
[11:16]  * alkisg will create a ltsp.gzip file and put it inside an uncompressed cpio, for maximum compatibility, and gunzip it inside the initramfs..
[13:56] <alkisg> xnox: hrm, although, putting ltsp.img as the first uncompressed cpio, will break microcode loading, won't it? :/
[13:57] <alkisg> "At boot time, the kernel performs the followings: If an uncompressed cpio archive exists at the start of the initramfs, extract and load the microcode from it to CPU. "
[13:57] <xnox> alkisg:  it should not
[13:57] <xnox> alkisg:  check dmseg to see if microcode update was applied on baremetal machine or not.
[13:57] <alkisg> ty, will do
[13:58] <xnox> alkisg:  we have verified this before, but worth double checking, by default we ship two early initrds + one compressed one, and we do observe microcode being loaded from the second early initrd on intel platforms.
[13:59] <alkisg> Great; will have to check tomorrow as I can only connect remotely to the office now; ty
[16:02] <The_LoudSpeaker> LocutusOfBorg: Thanks! The deb file you gave as a link worked. Playing CSGO at 250 fps now. :p
[16:44] <vorlon> rbasak: have you seen that some packages' autopkgtests seem to be unhappy with mysql-8.0 becoming the default? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-defaults
[17:00] <rbasak> vorlon: that's odd. I will follow up but it will be next week.
[17:01] <vorlon> rbasak: ack
[20:37] <evaluate> Hello.
[20:38] <evaluate> Are the scripts which generate for example the ubuntu-18.04-live-server-amd64.iso open sourced? And if yes, where can one find them?
[21:09] <Skuggen> vorlon, rbasak: There's also a recurring issue with the mysql-8.0 dep8 on arm64 timing out
[21:10] <Skuggen> e.g. for openssl, libaio and lsb
[21:12] <vorlon> Skuggen: do you know why the mysql-8.0 tests take so much longer than mysql-8.0 did?
[21:15] <Skuggen> There are more tests, but not that many more. I think maybe it's because of the amount of times the test suite needs a "clean" install, since --initialize takes longer in 8.0 than 5.7
[21:17] <Skuggen> I'll see if I can find out more next week, as well as look at the mysql-defaults failures. Mediawiki might be the same as cacti: Uses a native php connector that doesn't supporth the new default auth plugin in 8.0
[21:24] <vorlon> Skuggen: if the increased testsuite runtime is legitimate, then we can whitelist the package on the infrastructure to change the timeout; I just prefer someone to have analyzed it first to confirm it's legitimate
[21:28] <Skuggen> I'm _almost_ sure it's legitimate, but I can try to get confirmation, and see if maybe there are ways to improve it