rbasak | I guess the easiest way to deal with this is to port the lot :-/ | 00:00 |
---|---|---|
Skuggen | Hm, the MySQL dep8 test being so slow on arm64 is a pretty general problem | 03:56 |
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:23 |
ubottu | Launchpad bug 1840945 in linux (Ubuntu) "Concatenated lz4 initrds don't work" [Undecided,Confirmed] https://launchpad.net/bugs/1840945 | 06:23 |
* alkisg tests all compressions to see | 06:40 | |
Unit193 | alkisg: How'd you find that, anywho? | 07:00 |
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:01 |
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:06 |
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:07 |
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:34 |
ubottu | Launchpad bug 1840945 in linux (Ubuntu) "Concatenated lz4 initrds don't work" [Undecided,Confirmed] | 07:34 |
Unit193 | alkisg: I can't remember what all I'd tried, but using gzip for initramfs didn't help. Makes sense though. | 07:38 |
alkisg | Unit193: what is the error message that you see in the initramfs? For me, only .xz works in eoan | 07:39 |
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:40 |
* alkisg is seeing the strange new login screen of gdm currently | 07:41 | |
Unit193 | Cool, trying that now. | 07:41 |
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 | 07:43 |
Unit193 | alkisg: 'file=/cdrom/preseed/xubuntu-core.seed initrd=/casper/initrd quiet splash ---' | 08:08 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
Unit193 | https://unit193.net/dmesg.png https://unit193.net/initial.png | 08:17 |
alkisg | Unit193: and if you `cat /init` you see the /usr/share/initramfs-tools/init file? | 08:19 |
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:20 |
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:21 |
alkisg | True, if there's no root= in your /proc/cmdline, it can't mount it | 08:22 |
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:23 |
mwhudson | Unit193: do you have anything in your initrd that sets BOOT to casper | 08:25 |
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:26 |
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:27 |
Unit193 | mwhudson: Appending BOOT=casper didn't seem to assist. | 08:28 |
mwhudson | Unit193: boot= not BOOT= | 08:29 |
mwhudson | the other thing could be mismatched uuids but i think that fails differently | 08:29 |
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:30 |
LocutusOfBorg | https://forums.virtualbox.org/viewtopic.php?f=6&t=89392 | 08:31 |
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:33 |
Unit193 | Now I feel stupid... Anyway, let's see if I can't get CASPER_GENERATE_UUID to work. | 08:35 |
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:45 | |
tjaalton | fail how? | 08:46 |
LocutusOfBorg | X-Python-Version: >= 2.8 | 08:46 |
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:47 |
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:48 |
cjwatson | https://bugs.debian.org/934861 too FYI | 08:49 |
ubottu | Debian bug 934861 in python-yubico-tools "python-yubico-tools not installable, broken dependency" [Important,Open] | 08:49 |
tjaalton | bah | 08:49 |
RikMills | as libmysqlclient-dev is now 8.0.16-0ubuntu3, there is no way of building anything against 5.7? | 08:50 |
LocutusOfBorg | thanks cjwatson I'll update to that | 08:51 |
Unit193 | alkisg, mwhudson: Anyway, thanks. One way or another I'll get it to work now. :) | 09:00 |
mwhudson | Unit193: np, good luck | 09:00 |
alkisg | yw Unit193; /me continues struggling with COMPRESS=... | 09:04 |
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:05 |
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:07 |
=== alan_g is now known as alan_g_ | ||
LocutusOfBorg | vorlon, haskell needs sourceful uploads, not just rebuilds | 09:09 |
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:11 |
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:12 |
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:13 |
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:14 |
xnox | alkisg: well append works for me..... | 09:15 |
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:16 |
xnox | alkisg: bare metal reboots | 09:17 |
xnox | alkisg: so a lot more ram at least | 09:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
=== Wryhder is now known as Lucas_Gray | ||
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? | 09:41 |
=== lalit is now known as lalitmee | ||
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:13 |
alkisg | xnox: that indeed works! The mixed compression issue is still there but LTSP isn't affected anymore. Thanks again :) | 10:17 |
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) | 10:45 |
* alkisg will create a ltsp.gzip file and put it inside an uncompressed cpio, for maximum compatibility, and gunzip it inside the initramfs.. | 11:16 | |
=== ricab is now known as ricab|lunch | ||
alkisg | xnox: hrm, although, putting ltsp.img as the first uncompressed cpio, will break microcode loading, won't it? :/ | 13:56 |
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:57 |
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:58 |
alkisg | Great; will have to check tomorrow as I can only connect remotely to the office now; ty | 13:59 |
=== ricab|lunch is now known as ricab | ||
The_LoudSpeaker | LocutusOfBorg: Thanks! The deb file you gave as a link worked. Playing CSGO at 250 fps now. :p | 16:02 |
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 | 16:44 |
rbasak | vorlon: that's odd. I will follow up but it will be next week. | 17:00 |
vorlon | rbasak: ack | 17:01 |
evaluate | Hello. | 20:37 |
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? | 20:38 |
Skuggen | vorlon, rbasak: There's also a recurring issue with the mysql-8.0 dep8 on arm64 timing out | 21:09 |
Skuggen | e.g. for openssl, libaio and lsb | 21:10 |
vorlon | Skuggen: do you know why the mysql-8.0 tests take so much longer than mysql-8.0 did? | 21:12 |
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:15 |
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:17 |
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:24 |
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 | 21:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!