[00:00] I guess the easiest way to deal with this is to port the lot :-/ [03:56] Hm, the MySQL dep8 test being so slow on arm64 is a pretty general problem [06:23] 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:23] Launchpad bug 1840945 in linux (Ubuntu) "Concatenated lz4 initrds don't work" [Undecided,Confirmed] https://launchpad.net/bugs/1840945 [06:40] * alkisg tests all compressions to see [07:00] alkisg: How'd you find that, anywho? [07:01] 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] It's like putting the casper code in an extra initrd, not embedding it into a single one [07:06] 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] Unit193: sorry I didn't get which part broke and which one is related [07:07] (I'm testing that now) I got dumped to busybox, sooo. [07:34] 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:34] Launchpad bug 1840945 in linux (Ubuntu) "Concatenated lz4 initrds don't work" [Undecided,Confirmed] [07:38] alkisg: I can't remember what all I'd tried, but using gzip for initramfs didn't help. Makes sense though. [07:39] Unit193: what is the error message that you see in the initramfs? For me, only .xz works in eoan [07:40] Most of the time I get no error message. xz initramfs is the one that works? Huh. [07:40] 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] Cool, trying that now. [07:43] 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] alkisg: 'file=/cdrom/preseed/xubuntu-core.seed initrd=/casper/initrd quiet splash ---' [08:10] 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] `kvm -m 512 -cdrom myownfile.iso`, which should be good enough to get it to boot, but alas.. [08:11] Unit193: ah, do try kvm -m 1024... [08:12] Crazy as it sounds, I think I needed more than 512 in one case [08:12] This isn't GNOME, so it should be fine. An error I sometimes see is more related to squashfs. [08:12] (But trying it anyway.) [08:13] I had the problem while the initramfs decompressed; not later on when services are starting [08:13] This, as noted before, isn't a daily ISO but one I mess around with. [08:13] 1024 still dumped me at busybox. [08:14] busybox usually states the reason, so a screenshot and/or dmesg should probably help [08:14] *initramfs-tools usually states the reason... [08:15] 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] https://unit193.net/dmesg.png https://unit193.net/initial.png [08:19] Unit193: and if you `cat /init` you see the /usr/share/initramfs-tools/init file? [08:20] 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] Why 2 pictures? What changed to get from the first to the second one? [08:21] One is initial startup, the other is, as the name indicates, `dmesg` [08:21] Aaaah ok so you just didn't get to see the busybox error message because busybox cleared your screen [08:21] Put `break=bottom` etc so that you get a chance to see it [08:21] Removing 'quiet splash' gets me 'No root device specified. Boot arguments must contain root=' [08:22] True, if there's no root= in your /proc/cmdline, it can't mount it [08:23] Your boot loader (isolinux I presume) should have provided it [08:23] Unit193: let's go somewhere else, I don't think this is related to #ubuntu-devel... [08:25] Unit193: do you have anything in your initrd that sets BOOT to casper [08:26] e.g. this random casperized initrd i have lying around has conf/conf.d/default-boot-to-casper.conf [08:26] mwhudson: Looking at the scripts, it should pick that up. I believe.. [08:27] 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] mwhudson: Appending BOOT=casper didn't seem to assist. [08:29] Unit193: boot= not BOOT= [08:29] the other thing could be mismatched uuids but i think that fails differently [08:30] cpaelzer, #1840749 can't you just use the upstream binaries? [08:30] just to understand if it is a packaging issue, or to understand when it broke [08:31] https://forums.virtualbox.org/viewtopic.php?f=6&t=89392 [08:33] mwhudson: ...Welp, that worked. Now to figure out why it's not automatically picking that up anymore. [08:33] Sorry. [08:33] Unit193: heh i've spent rather too long with my head in the initramfs code lately [08:35] Now I feel stupid... Anyway, let's see if I can't get CASPER_GENERATE_UUID to work. [08:45] tjaalton, did you upload of python-yubico fail? [08:45] http://launchpadlibrarian.net/436704667/python-yubico_1.3.2-2_1.3.2-2.1.diff.gz [08:45] +X-Python-Version: >= 2.8 [08:45] * LocutusOfBorg fixup this [08:46] fail how? [08:46] X-Python-Version: >= 2.8 [08:47] I don't think doko is planning to ever upload a python2 2.8 :D [08:47] explain [08:47] ok [08:47] python-yubico-tools/amd64 unsatisfiable Depends: python:any (>= 2.8~) [08:47] I didn't touch that part [08:47] it didn't migrate in debian and ubuntu [08:47] Also note that current Debian practice is to remove the X-Python-Version header entirely [08:47] or did I [08:47] and moreover you upload contained a binary, so it won't migrate in debian because of this [08:48] tjaalton, the signature on NMU is your :) [08:48] I can drop them both and reupload as nmu [08:48] oh I did [08:48] yes please [08:48] it had to go via NEW... [08:49] https://bugs.debian.org/934861 too FYI [08:49] Debian bug 934861 in python-yubico-tools "python-yubico-tools not installable, broken dependency" [Important,Open] [08:49] bah [08:50] as libmysqlclient-dev is now 8.0.16-0ubuntu3, there is no way of building anything against 5.7? [08:51] thanks cjwatson I'll update to that [09:00] alkisg, mwhudson: Anyway, thanks. One way or another I'll get it to work now. :) [09:00] Unit193: np, good luck [09:04] yw Unit193; /me continues struggling with COMPRESS=... [09:05] 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] :) [09:07] 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" === alan_g is now known as alan_g_ [09:09] vorlon, haskell needs sourceful uploads, not just rebuilds [09:11] Hey! Does ubuntu 19.04 doesn't support steam? [09:11] A friend of mine Installed steam but when he runs it. It doesn't start. [09:12] Any help is appreciated. [09:12] The_LoudSpeaker: 19.10 I think should support steam. How did he install it? Best to ask in #ubuntu. [09:12] The_LoudSpeaker, is that the client with a lot of security issues and a team who bans people reporting them? [09:12] He installed using terminal. apt install I guess. [09:13] 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] nice [09:13] LocutusOfBorg: ? [09:13] The_LoudSpeaker, their bug-bounty program is scary [09:13] one person reported a security vulnerability and got banned instead of rewarded [09:13] Lol! [09:13] so he gave a 0 day to the world a few days ago [09:14] 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] alkisg: well append works for me..... [09:16] alkisg: but i also failed to see any benefits to lz4 =/ [09:16] The_LoudSpeaker, how did he install it? [09:16] what happens if he runs from command line? [09:16] xnox: how are you testing? [09:16] wget http://repo.steampowered.com/steam/archive/precise/steam_latest.deb [09:16] this one might work [09:16] Okay. I will try it in a bit and let you know. [09:17] alkisg: bare metal reboots [09:17] alkisg: so a lot more ram at least [09:18] The_LoudSpeaker, and tell him to use a VM, otherwise somebody might hack his laptop LOL [09:18] 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] LocutusOfBorg: yes I can and will use the upstream binaries [09:18] alkisg: as i commented on your bug report, the lz4 call you do is invalid. [09:18] We have a strong firewall. LocutusOfBorg [09:18] didn't know they are provided [09:18] xnox: ah, I wasn't notified yet; refreshing/reading... [09:19] thanks cpaelzer , it might be really trivial to bisect, avoiding lots of rebuilds [09:19] The_LoudSpeaker, it was a joke, I don't really care :D [09:19] xnox: so the additional initrd needs to be compressed using the same algorithm? Can't it be a cpio with no compression? [09:20] LocutusOfBorg: same here. [09:20] alkisg: kernel only knows how to read certain formats of lz4, which is not the default. [09:20] xnox: date.img isn't lz4; it's cpio; I'm not compressing it [09:20] alkisg: -l Use Legacy format (typically for Linux Kernel compression) [09:20] Note : -l is not compatible with -m (--multiple) nor -r [09:20] alkisg: well, your bug description says you are..... [09:21] xnox: I mean in my tests in #3 [09:21] # echo date.txt | cpio -oH newc | lz4 > date.img => will never work [09:21] echo date.txt | cpio -oH newc > date.img [09:21] The_LoudSpeaker, it might be premature to run valve on devel systems, unless you know how to debug issues [09:21] 19.10 is not even released yet [09:21] still under development, and valve team I doubt are caring right now about it [09:21] alkisg: but how was initrd.lz4 created? with or without -l ? [09:21] and I also doubt any ubuntu developer is caring about fixing it :) [09:22] I might care if it breaks on 18.04 :D [09:22] xnox: with update-initramfs -u; whatever code that has, I believe should be fine [09:22] LocutusOfBorg: ummm what valve? Can't get the context here. [09:22] alkisg: depends on the release and if the tools were installed ;-) [09:22] xnox: I changed COMPRESS= and ran update-initramfs -u for each case; it's yesterday's eoan build [09:22] alkisg: mixed compression i would expect to work, because early initrds are all uncompressed [09:22] The_LoudSpeaker, steam/valve, same thing [09:22] The initial lz4 was the one from the live cd, I didn't re-generate it [09:23] valve is the corporation providing steam [09:23] * LocutusOfBorg can say that his ubuntu 18.04LTS with steam works [09:23] alkisg: why are you using a livecd initrd? [09:23] * LocutusOfBorg starts a game and blames The_LoudSpeaker for this! [09:23] 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] alkisg: what are you doing anyway? [09:24] 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] 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] LocutusOfBorg: ohh! Yeah forgot steam is provided by valve. [09:25] 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] mwhudson: The mismatch uuid is 'unable to find a medium containing a live filesystem', isn't it? :) [09:26] Unit193: yes, that sounds like it [09:26] 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] 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! === Wryhder is now known as Lucas_Gray [09:41] 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? === lalit is now known as lalitmee [10:13] alkisg: i do not know, but it's unlikely to be mkinitramfs. especially for the uncompressed cased. [10:13] alkisg: you could try prepending, i.e. cpio+lz4 [10:13] alkisg: as that is how early initrd works [10:13] xnox: ty, trying [10:17] xnox: that indeed works! The mixed compression issue is still there but LTSP isn't affected anymore. Thanks again :) [10:45] 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.. === ricab is now known as ricab|lunch [13:56] xnox: hrm, although, putting ltsp.img as the first uncompressed cpio, will break microcode loading, won't it? :/ [13:57] "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] alkisg: it should not [13:57] alkisg: check dmseg to see if microcode update was applied on baremetal machine or not. [13:57] ty, will do [13:58] 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] Great; will have to check tomorrow as I can only connect remotely to the office now; ty === ricab|lunch is now known as ricab [16:02] LocutusOfBorg: Thanks! The deb file you gave as a link worked. Playing CSGO at 250 fps now. :p [16:44] 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] vorlon: that's odd. I will follow up but it will be next week. [17:01] rbasak: ack [20:37] Hello. [20:38] 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] vorlon, rbasak: There's also a recurring issue with the mysql-8.0 dep8 on arm64 timing out [21:10] e.g. for openssl, libaio and lsb [21:12] Skuggen: do you know why the mysql-8.0 tests take so much longer than mysql-8.0 did? [21:15] 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] 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] 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] I'm _almost_ sure it's legitimate, but I can try to get confirmation, and see if maybe there are ways to improve it