<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 _2_4 25  
26 27 28 29 30 31
00:00 blueness joined
00:27 bluetazmanian joined
00:28 dbarrett joined
00:36 laj joined
01:07 Nobabs27 joined
01:17 IRConan joined
01:45 cyteen joined
01:45 blueness joined
01:49 IRConan joined
01:56 IRConan joined
02:05 bluetazmanian joined
02:15 dirac1 joined
02:26 ogres joined
02:29 s33se_ joined
02:35 coin3d joined
03:00 blueness joined
04:01 sparklyballs joined
04:04 mguentner joined
04:11 mguentner2 joined
04:17 ppisati joined
04:33 mrEngineer joined
05:30 IRConan joined
05:37 mdillon joined
06:04 mdillon joined
06:26 mouthbreather joined
06:45 m0e joined
07:08 ProXy joined
07:15 ageis joined
08:03 ghavil joined
08:05 blueness joined
08:12 fekepp joined
08:16 welshjf left
08:19 IRConan joined
08:37 fekepp joined
08:46 bluetazmanian joined
08:49 xsteadfastx joined
08:50 t0mmy joined
08:50 blueness joined
09:10 bluetazmanian joined
09:11 discensa joined
09:11 bluetazmanian joined
09:12 bluetazmanian joined
09:19 bluetazmanian joined
09:20 t0mmy joined
09:27 bluetazmanian joined
09:30 bluetazmanian joined
09:41 lesion joined
09:45 bluetazmanian joined
09:47 bluetazm_ joined
09:48 bluetaz__ joined
09:49 bluetazm_ joined
09:50 FRP-admin joined
09:59 t0mmy joined
10:27 fcolista joined
10:31 sigjuice joined
10:45 david1 joined
10:47 dnel joined
10:48 Skele joined
10:52 blueness joined
10:58 fabled joined
11:02 dnel joined
12:19 farosas_ joined
12:42 biax joined
12:43 gromero joined
12:52 gromero joined
12:57 sparklyballs joined
13:04 mdillon joined
13:30 <TBB> has anyone else noticed Alpine's Truecrypt to have problems in commandline use?
13:31 <TBB> it seems to be unable to flush its own prompts to stdout properly, so you see them only after pressing enter to finish your input
13:35 <fabled> TBB, i fixed that for ecryptfs, sounds like truecrypt has similar fflush() calls missing
13:35 <fabled> i've been using truecrypt via GUI only
13:35 <fabled> TBB, is there a bug about it?
13:36 <scv> more glibc assumptions?
13:36 <fabled> yeah, sounds like that.
13:38 <TBB> fabled, not yet; I've got a couple of other bugs as well that I should report, it's just that I'm currently about 200% utilized in my work project
13:39 <fabled> TBB, ok. if it's generic alpine issue, please file a bug report.
13:39 <TBB> sure. I'm even a bit ashamed of how well my grand vision for being a contributor has turned out; too busy, most of the time, to file bug reports and contribute packages :/
13:44 <TBB> another question... glad to see MATE in the repos. I just don't seem to get logged in very quickly, there's a 20-30 second delay before the desktop is fully usable. and its screensaver doesn't lock; works otherwise, but won't lock
13:44 <TBB> well, there's no question other than OMG WHAT SHOULD I DO NOW?!?!
13:47 magellanic joined
14:09 sparklyballs joined
14:12 nanohest joined
14:13 <odc> TBB: use strace to find out what is causing the 20-30s delay
14:13 <odc> go!
14:13 <scv> strace, what a wonderful tool
14:21 <hiro> scv: also try perf-tools
14:21 <hiro> theres some little toys like execsnoop
14:22 <hiro> they are quite helpful sometimes in multiprocess problems
14:23 <hiro> cause sometimes strace doesnt show you delay caused by other programs other than the one you're analyzing
14:23 <hiro> if its not forked from it directly it gets really hard
14:24 <hiro> all this asynhronous complex freedesktop stuff for example ;)
14:25 <hiro> but, normally i have to use many such tools at once to pinpoint the bullshit thats happening in modern day linux desktops
14:25 <scv> ah desktop i can imagine
14:26 <scv> i try not to subject myself to such horrors anymore
14:26 <scv> maybe some years ago but today?
14:27 <hiro> scv: see the original request :)
14:27 <hiro> scv: MATE :D
14:28 <hiro> scv: are you using KMS console or what?
14:29 <hiro> scv: i saw some people even use mpv on console :D
14:29 <hiro> but web browsing normally kills this option for people
14:29 magellanic joined
14:36 <magellanic> apache is segfaulting with the latest alpine docker image, which worked previously, is there a known issue? if I remove this config from my vhost, it seems okay "Protocols h2 http/1.1". With that config I get child segfaults.
14:41 <scv> hiro: you're gonna stab me, but i'm running windows on my desktop
14:41 <scv> ¯\_(ツ)_/¯
14:41 <scv> gaming purposes
14:41 <scv> i've been meaning to install alpine but moving off a 4 disk raid0 is difficult
14:42 <scv> my last linux desktop machine was fedora and boy was that a shitshow
14:44 <hiro> scv: i also run windows
14:44 <hiro> scv: i log in to some alpine, debian, ubuntu, tinycorelinux boxes from cygwin
14:44 <hiro> scv: and if i'm ever forced to use an ubuntu desktop i regularly rdp into a windows box
14:44 <scv> pretty much same, although i've ditched any systemd monstrosities at this point
14:45 <hiro> scv: why bother trying to install chrome on a minimal alpine linux installation if the whole chrome codebase is 100 times as large as the part of the OS that i use...
14:45 <scv> my primary reason for abandoning linux desktop
14:45 <hiro> at least the userbase on windows is large enough that stupid bugs in the web browser *will* get attention from somebody with money
14:45 <scv> other reason was previous $DAY_JOB required software that ran on windows
14:46 <scv> my goal is to install alpine on my bare metal and virtualize windows & passthru the gpu
14:46 <magellanic> I use mint for a desktop :D
14:46 <scv> even bought ssds for it but haven't gotten around to actually doing the work yet
14:47 <hiro> on bare metal my windows 7 install on a phenom II x4 is still so blazingly fast that i will keep on using that for now
14:48 ogres joined
14:48 <hiro> while i don't think i'll do much with virtualization on this platform because i fear there just aren't enough features in that super old CPU
14:48 <scv> my desktop is a xeon e5-1620v2, so i think it'll handle the virtualization ok
14:48 <hiro> less virtualization capabilities
14:48 <scv> i used to have a phenom some years ago, outgrew it doing virtualization tasks
14:48 <hiro> i'd like an OS that makes good use of the IO-MMU
14:49 <scv> the other way around back then, server 2008 in vmware workstation, again for gaming :p
14:49 <hiro> scv: yeah, so as i feared :)
14:49 <scv> it just couldn't keep up though
14:49 <hiro> funny. mine is still perfectly capable
14:49 <hiro> i'm limited by the old GPU only
14:49 <scv> the cpu was the bottleneck for me for sure
14:50 <scv> found the same with many AMD cores though, worked at a few VM providers in the past and had trialed some 12 core interlagos for host nodes, they couldn't keep up with 55xx series xeons
14:50 <scv> even with fewer cores on the xeons
14:50 <scv> more customers and still more responsive machines
14:51 <scv> here's hoping ryzen is a change to that trend though
14:52 <TBB> yeh, it'd be nice to have AMD actually competing with Intel again
14:52 <scv> agreed
14:53 <TBB> odc: I'll do that. I have a pretty good hunch on what causes it tho, I just don't have the time to spend confirming it for now; maybe later in the evening
14:53 <TBB> (resolver trouble, possibly ipv6 related)
14:53 <odc> huh
14:54 <TBB> (misconfiguration, most probably)
14:54 <TBB> 5 sec timeouts, that kind of stuff
15:01 blueness joined
15:16 Emperor_Earth joined
15:30 blueness joined
15:37 blueness joined
15:43 zenny joined
15:44 <zenny> Hi, could not find any pointer to install zfs in root though it was stated that from v3.5 the install er supports. Tried with 'ROOTFS=zfs setup-alpine -m sys /mnt' didn't seem to work. Any pointers?
15:44 blueness joined
15:46 <Shiz> what part broke?
15:48 <zenny> I even tried to load modules=zfs.ko at the boot prompt without success. Generally it fails.
15:48 <Shiz> so booting?
15:50 <zenny> the iso boots alright, just need to know how to install root in zfs
15:56 czart__ joined
16:02 blueness joined
16:07 BitL0G1c joined
16:28 mikeee_ joined
16:39 mmlb joined
16:40 MH0815 joined
16:40 <mmlb> hey everyone, I'm trying to get alpine generic arm (aarch64) working with qemu-system-aarch64
16:41 <mmlb> I'm hitting a few walls
16:41 <mmlb> modloop and networking being the big ones currently
16:43 <TemptorSent> mmlb: Do you have it loadin an overlay that starts the modloop init? Where's it failing?
16:44 <mmlb> TemptorSent: nope I don't. I'm booting qemu-system-aarch64 with mostly just `-kernel` `-initrd` and console args
16:45 <mmlb> sorry if I'm doing it wrong, tried to look on the wiki for some info and couldn't find anything, how should I add an overlay dev and have init do the right thing?
16:46 <Shiz> its gonna need more than the kernel and initrd to start up the modloop
16:46 <TemptorSent> mmlb: Don't worry about it, the docs are not so great.
16:47 <Shiz> mmlb: you're using the "generic ARM" download, right?
16:47 <mmlb> I'm probably not using it correctly either, I'm looking to get alpine up, install docker, build an image, save said image and then shutdown.
16:47 <mmlb> Shiz: I am
16:47 <TemptorSent> mmlb: You'll need at least a minimal overlay that takes care of starting the services needed to get networking up.
16:47 <Shiz> i don't think he'll need an overlay
16:47 <Shiz> sorry, they'll
16:48 <Shiz> initramfs just needs to locate the modloop, and given that they're likely just passing -kernel and -initrd, isn't going to find them
16:48 <TemptorSent> mmlb: *lol* Okay, sounds like you're like me then -- making a tool work for something it wasn't previously cut out for.
16:48 <mmlb> TemptorSent: seems that way
16:49 <Shiz> mmlb: my best guess for you would be to create a qemu virtual disk image, format and partition it and extract the generic ARM rootfs to it
16:49 <mmlb> Shiz: I was passing in the modloop with `-drive if=sd,file=modloop-vanilla` but nothing seemed to be trying to get it
16:49 <Shiz> then pass it to qemu together with -kernel and -initrd that you previously did
16:49 <Shiz> yeah, the modloop shouldn't be loaded directly as drive
16:49 <Shiz> iirc
16:49 <TemptorSent> Shiz: I couldn't find where modloop actually got handled by init - afaik it requires an overlay with the needed packages in the world file and the runlevel links.
16:49 dlaube joined
16:50 <mmlb> TemptorSent: I couldn't find anything for modloop handling either
16:51 <TemptorSent> mmlb: I just went through debugging the startup process the past couple days, so either we're both missing something obvious, or modloop needs help starting.
16:51 <mmlb> Shiz: my actual workflow is going to use packer to run qemu, do the bare minimum to get ssh running, install docker and ...
16:51 <Shiz> TemptorSent: line 422
16:51 <Shiz> the boot media gets mounted, which includes the modloop init script
16:51 <Shiz> in its packages
16:51 <Shiz> and the packages get installed to a tmpfs
16:52 <Shiz> (if root= is not given, of course)
16:52 m0e joined
16:52 <mmlb> Shiz: what is boot media you speak of?
16:52 <TemptorSent> Shiz: Hmm, not seeing that happening for some reason.
16:53 <Shiz> mmlb: the boot media is typically like the cd-rom or thumbdrive you're booting from in a traditional setup
16:53 <TemptorSent> Shiz: does nlplug-findfs actually find and mount modloop?
16:53 <mmlb> ahh yeah thats what I thought, but aarch64 doesn't have that :(
16:53 <Shiz> mmlb: that's why i suggested you extracted the contents of generic ARM to a qemu virtual disk and mounted that
16:53 <Shiz> it should be able to find it that way :)
16:54 <Shiz> TemptorSent: no, what happens is this
16:54 <Shiz> TemptorSent: 1) it locates the boot medium through nlplug-findfs and mounts it
16:54 <Shiz> 2) it sees there is no root= and proceeds to setup a new alpine install in RAM from the .apks on the mounted boot medium
16:54 <Shiz> 3) the .apks on the boot medium include alpine-base .apks and related openrc init scripts
16:55 <Shiz> 4) it then chainloads into the alpine installs in RAM and runs the boot scripts, which set up the modloop
16:55 <TemptorSent> Okay, but somewhere around line 491 is the only place I see it actually referrign to modloop.
16:55 <Shiz> read what i said again
16:55 <Shiz> initramfs-init doesn't consider itself with modloop
16:55 <Shiz> it switches_root to the new alpine install in ram, which then runs modloop as part of regular openrc init
16:55 <TemptorSent> And thats' supposed to setup a skeleton set of runlevels.
16:56 <Shiz> yes, which is done by virtue of it installing the alpine-base .apk from the boot medium in that new install
16:56 <Shiz> :)
16:56 <TemptorSent> Right, but that has to actually be able to happen for it to proceed :)
16:57 <Shiz> yes, that's why i suggested to mmlb that they have to setup a way for alpine to find the boot medium
16:57 <Shiz> for example by extracting it to a qemu virtual disk and mounting that into the vm
16:57 <Shiz> :)
16:57 <Shiz> the 'generic arm' .tar works as a boot medium just fine
16:57 <Shiz> it just has to be found by the initramfs
16:58 <TemptorSent> I'll have to play with that... IIRC it uses an overlay to enable dhcp at boot, right?
16:59 <Shiz> no overlays are used
16:59 <TemptorSent> Shiz: Hmm, that's based on the uboot profile, right?
17:00 <Shiz> it includes uboot as bootloader, but i'm not sure if there's any uboot-specific configuration in the generic ARM image beyond that
17:00 <Shiz> http://git.alpinelinux.org/cgit/alpine-iso/tree/alpine-uboot.conf.mk
17:00 <Shiz> doesn't look like it
17:00 <Shiz> mmlb: still with us? :)
17:01 <TemptorSent> Right, but the image generation itself by mkimage used apkovl="genapkovl-dhcp.sh" in mkimg.arm.sh.
17:01 <TemptorSent> I think we lost him...
17:02 <TemptorSent> In my mkimage rewrite, I've sorted all the various functions out so you can actually tell what's doing what why.
17:03 <TemptorSent> But no testing on arm yet - who want's to be a test dummy?
17:06 <mmlb> yeah sorry, coworker was asking some questions :D
17:06 <TemptorSent> mmlb: No worries.
17:06 Berra joined
17:06 <mmlb> o/ I'll be a test dummy
17:07 <TemptorSent> mmlb: If you want to help me break it, I've done a rewrite of the mkimage code that makes it trivial to setup custom images.
17:07 <mmlb> Shiz: I don't see any 'generic arm' tar ball anywhere
17:08 <TemptorSent> mmlb: See https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
17:08 <Shiz> mmlb: https://alpinelinux.org/downloads/
17:08 <TemptorSent> mmlb: I think it's on the main alpine downloads :)
17:08 <Shiz> very bottom
17:08 <Shiz> 'Generic ARM'
17:09 <mmlb> oh right, yeah thats what I downloaded and extracted to get at the kernel/initrd
17:09 <Shiz> yeah
17:09 <Shiz> you should extract its entirety to a qemu virtual disk and mount it
17:09 <Shiz> :)
17:09 <mmlb> hmm I shall try that indeed
17:09 <Shiz> you can create one using qemu-img and mount it to your host system to move files to with qemu-nbd
17:11 <Shiz> formatting it as ext2/3/4 should work
17:11 <mmlb> cool I will try that Shiz
17:11 <mmlb> TemptorSent: can I just run ./makeimage.sh on non alpine, x86_64?
17:12 <TemptorSent> mmlb: Good question :)
17:13 <TemptorSent> mmlb: check the --help, and don't forget to have installed host keys first, then use --hostkeys flag to mkimage or nothign will boot!
17:13 <mmlb> Shiz: what do I do about boot loader?
17:14 <Shiz> mmlb: you just boot with -kernel and -initrd as you did before
17:14 <Shiz> you just also add the virtual disk :)
17:14 <Shiz> that should enable the initramfs to find the boot medium files at runtime, locate the modloop and setup a proper install in ram and switch into it
17:14 <TemptorSent> mmlb: extlinux is needed when it's trying to boot from hardware, but qemu is getting a pointer directly.
17:15 <mmlb> oic, so just to make sure I don't miss anything: extract all of generic-arm.tar to a virtual disk, qemu -kernel -initrd -append $(same args as extlinux.conf) -drive if=sd,$vdiskfile?
17:15 <Shiz> extlinux doesn't really do much on bare-metal arm
17:15 <Shiz> mmlb: i believe that should work, yes
17:15 <mmlb> cool will try that
17:15 <TemptorSent> Shiz: not extlinux itself, sorry, extlinux.conf
17:16 <Shiz> not sure if it supports sd though
17:16 <TemptorSent> That's what uboot appears to pick up its boot config from.
17:16 <mmlb> TemptorSent: I'll be trying your mkimages.sh anyway since that may come in handy for something else here
17:17 <mmlb> Shiz: yeah I don't think so either, thoughts on what it should be?
17:17 <TemptorSent> mmlb: Yeah, the intent is to make custom images about as easy as a docker image would be, and have them fully operational with no further config.
17:17 <mmlb> :heart_cat_eyes:
17:18 <TemptorSent> mmlb: I have it booting happily in qemu on x86_64 now, bringing up zfs, starting sshd, starting dhcp, and starting postgres.
17:19 <Shiz> mmlb: you can try with sd and see if it works :)
17:19 <Shiz> looking up other options right now
17:19 <mmlb> Shiz: I'll try but I don't think it'll work since sd isn't built in, or in the initram
17:19 <Shiz> mmlb: if sd doesn't work, you can try scsi
17:19 <Shiz> mmlb: sd isn't but mmc is :)
17:19 <Shiz> so it may still work
17:21 <TemptorSent> Depending on the configuration, the sd may look like a USB interface, scsi blk, mmc, or sd specifc.
17:22 <TemptorSent> I'm currently running this dev box of a micro-sd sitting in a usb reader :)
17:24 <TemptorSent> Many of the embedded arm devices hang a controller of an internal USB hub.
17:25 <TemptorSent> The REALLY fun ones hang them direcly of a SPI intereface with none of the extra signal lines and you get to basically bit-bang out page changes.
17:29 <mmlb> omg I just realized I was using sd, instead of scsi (for sata)!
17:30 <TemptorSent> mmlb: That could be problematic :)
17:31 <mmlb> yeah
17:31 <* mmlb> shakes fist
17:37 sergey joined
17:59 <Shiz> mmlb: any issues?
18:01 <mmlb> Shiz: Yup. So I got the vdisk setup, 1 ext4 partition, seems the disk is not being found
18:01 <mmlb> I'm running sudo qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 2048 -nographic -kernel vmlinuz -initrd initramfs-vanilla-with-modloop -append 'console=ttyAMA0,115200 ip=dhcp debug_init=yes' -netdev tap,id=net0,br=hv -device virtio-net,netdev=net0
18:01 <mmlb> -hda sdd.img
18:02 <Shiz> what's initramfs-vanilla-with-modloop?
18:02 BitL0G1c1 joined
18:03 <mmlb> oh, I stuffed the modloop file into the initramfs as `/modloop`, no other changes
18:03 <mmlb> same deal with normal initramfs-vanilla
18:04 <Shiz> what's sdd.img look like?
18:04 <Shiz> as in, how did you set it up
18:05 lesion joined
18:05 m0e joined
18:06 <mmlb> truncates -s10G sdd.img; losetup -f sdd.img; fdisk /dev/loop0 (gpt, 1 partition all space), mkfs.ext4 /dev/loop0p1, mount, rsync -havP extracted-generic-arm/ /mnt; umount; losetup -D
18:06 <Shiz> try this
18:07 <Shiz> qemu-img create -f qcow2 hda.img 10G; modprobe nbd max_part=8; qemu-nbd --connect=/dev/nbd0 hda.img; mkfs.ext4 /dev/nbd0;
18:08 <Shiz> then mount rsync etc and qemu-nbd ---disconnect=/dev/nbd0
18:08 <mmlb> 1s
18:08 <Shiz> and then -drive if=scsi,file=hda.img,format=qcow2
18:10 <Shiz> one issue is that the stock alpine armhf kernel config doesn't support GPT i think
18:10 <Shiz> armhf/aarch64
18:10 fireglow joined
18:11 <Shiz> unsure though
18:12 <mmlb> hmm well I have no way to check that out since I dont even get a '/dev/sda' at all (about to try you image now)
18:13 <Shiz> hmm
18:13 <Shiz> it might not be called sda
18:13 dfgg joined
18:14 fekepp joined
18:15 BitL0G1c joined
18:16 m0e joined
18:17 <mmlb> Shiz: nope doesn't look like the mods are loaded, I've got a bunch of ramN, ttyN nothing /dev/sda, hda, scsi...
18:22 coin3d joined
18:25 <Shiz> hmm
18:26 <Shiz> anything in dmesg?
18:26 <mmlb> not that I can tell
18:31 dirac1 joined
19:03 <mmlb> TemptorSent: how do you get the overlay seen in qemu?
19:19 blueness joined
19:26 cyborg-one joined
19:30 dirac1 joined
19:38 <TemptorSent> mmlb: You'll have to make sure the initfs gets built with the modules you need.
19:38 <TemptorSent> Once it can get that far, it the overlay will have the rest of the startup.
19:39 <TemptorSent> If you have to, make a cpio archive with the files you need in their directory structure and add it as an additional initrd.
19:41 lesion joined
19:42 <mmlb> ahh you're using your custom initrd, makes sense. Yeah I might try cpio for the extra initrd
19:42 <mmlb> I may just go with a custom image though
19:42 <mmlb> 2 birds 1 stone
19:46 <TemptorSent> update-kernel uses mkinitfs, so the settings /etc/mkinitfs/mkinitfs.conf determine the contents of the initrd.
19:46 <TemptorSent> Make sure the features you need are enabled and you should be good.
19:58 <zenny> Could not find any documents on installing alpinelinux's root in zfs (which reportedly is possible since version 3.5 (https://www.alpinelinux.org/posts/Alpine-3.5.0-released.html). Can anyone elaborate or point to any document? Already tried with ROOTFS=zfs setup-alpine -m sys /mnt, but got installed into ext4. Even trying to load modules=zfs.ko and zfs didn't go through.
19:58 dirac2 joined
20:18 minimalism joined
20:19 mouthbreather joined
20:19 m0e joined
20:26 tweek joined
20:28 tweek joined
20:29 blueness joined
20:31 tweek joined
20:36 tweek__ joined
20:39 tweek__ joined
20:39 tweek__ joined
20:43 <mmlb> thanks TemptorSent
20:44 Emperor_Earth_ joined
20:45 gromero joined
20:50 <mmlb> :woop: *finally*. I don't know why I didn't think to do this earlier :/. I extracted modloop into initram, repacked and booted that.
20:51 <mmlb> looks like aarch64 images are biased for "Cute Embedded Nonsense Hacks". It would be nice to have virtio_blk in it too.
21:03 <systmkor> mmlb: what do you mean by "Cute Embedded Nonsense Hacks"
21:03 <systmkor> I occasionally do some embedded stuff, and trying to learn about doing things the proper way or non-hacky way
21:07 blueness joined
21:09 <Shiz> mmlb: the latter should be easy
21:09 <Shiz> http://git.alpinelinux.org/cgit/alpine-iso/tree/alpine-uboot.conf.mk
21:09 <Shiz> poke someone to add "virtio" to INITFS_FEATURES
21:09 <Shiz> :p
21:09 <mmlb> know anyone I should poke?
21:10 <Shiz> best option is fabled or ncopa
21:10 <mmlb> systmkor: The aarch64 file I downloaded is missing some things that would be useful in virtualized environments (like virtio-blk, virtio-net)
21:11 <mmlb> and also using u-boot and dts, which is not how things are being done in aarch64-server space (UEFI + standard bootloaders)
21:11 <mmlb> so looks like current alpine builds are for embedded devices
21:16 mikeee_ joined
21:20 mystified joined
21:24 fekepp joined
21:26 mystified1234 joined
21:27 <mmlb> TemptorSent: I'm running mkimage in a docker alpine container, I have a user named builder with group abuild and sudoers file has `builder ALL=(ALL) ALL`, mkimage is failing with `>>> WARNING: mkimage.sh:x86_64:extended:build apk repo:x86_64: Building 'apks' failed!`
21:30 Nobabs27 joined
21:32 lesion joined
21:33 m41 joined
21:39 bahamat joined
21:41 <bahamat> Greetings, I'm trying to do some testing with Alpine in VMware Fusion. I'm booting the alpine-virt ISO, but I don't seem to have any network interfaces other than lo. I do have an interface device in the vmware config.
21:42 <bahamat> I feel like I'm missing something that should be obvious.
21:42 <Shiz> bahamat: what NIC is it set to emulate?
21:43 <bahamat> Shiz: Unfortunately the vmware interface doesn't show me...I think it's e1000 though.
21:44 <Shiz> hmm
21:44 <Shiz> does # lsmod show e1000?
21:44 zenny joined
21:45 <bahamat> I did modprobe e1000 manually, and it is there.
21:45 <bahamat> but neither ifconfig nor ip link list it.
21:45 <Shiz> anything in dmesg about e1000 finding a device?
21:45 <Shiz> it might not be an e1000 if it can't p
21:45 <Shiz> :p
21:46 <bahamat> Just that the driver loaded.
21:46 <zenny> @ncopa or @clandmeter how can one install root in zfs from bootable iso? Tried with even extended iso in vain. Just stuck like this forum thread: https://forum.alpinelinux.org/forum/installation/boot-zfs-root
21:46 <Shiz> bahamat: what about # modprobe vmxnet3
21:47 <bahamat> I tried vmxnet3 as well, same thing.
21:47 <Shiz> bahamat: what does ethernet0.virtualDev in your .vmx file say?
21:49 <bahamat> That line isn't present
21:49 <Shiz> that would indicate you don't have an active network device configured
21:49 <Shiz> if there are no other lines that start with ethernet0 either
21:49 <bahamat> ethernet0.present = "TRUE"
21:49 <bahamat> And others
21:49 <bahamat> Just not virutalDev
21:49 <Shiz> ah
21:50 <Shiz> try closing vmware, and adding ethernet0.virtualDev = "e1000"
21:50 <Shiz> then booting the machine again
21:50 <bahamat> OK, my other instances do have virutalDev="e1000"
21:51 atomi joined
21:51 <Shiz> the virt alpine image only supports E1000 and VMXNET3 drivers (and virtio-net and a few others)
21:51 <Shiz> so if your vmware tries to emulate vmxnet, vmxnet2 or some oehter device it wouldn't work
21:51 <bahamat> Yep, that was it.
21:52 <bahamat> No idea what it was emulating before
21:52 <Shiz> likely vmxnet or vmxnet2
21:52 <bahamat> Well, sorry to bust in here with what was essentially a vmware question :-/
21:52 <Shiz> no problem lol
21:52 <bahamat> It's lame that fusion doesn't even show me the device type, or allow me to change it.
21:53 <Shiz> interestingly i never had issues with alpine in fusion, but i didn't use the virt image
21:53 <Shiz> maybe it was because i used an older version of fusion, though
21:53 <bahamat> I've got 8.5.3
21:53 <bahamat> But, whatever. It's working now.
21:54 <Shiz> until recently i was on 6 or 7, i think
21:54 <Shiz> i haven't tried since upgrading
21:54 <Shiz> ah, my .vmx does say >ethernet0.virtualDev = "e1000"
21:54 <Shiz> so it was probably because I was using an older version of fusion
21:55 gromero joined
21:56 <bahamat> Yeah, I think that's it. These other instances were originally created with older versions
21:56 <Shiz> that's somewhat problematic though, that for a stock user Alpine won't run on a standard Fusion setup...
21:56 <bahamat> Yeah.
21:57 <Shiz> what "base" did you choose?
21:58 <Shiz> e.g. my selection for alpine is "Other Linux 3.x kernel 64-bit"
21:58 <bahamat> That's what I chose
21:59 <bahamat> Being booted from the CD, can I install packages without having to do the full alpine-setup?
21:59 <Shiz> sure
21:59 <Shiz> it will only retain in the live environment though, for obvious reasons
21:59 <Shiz> :P
21:59 <Shiz> you might want to run setup-apkrepos first
22:00 <Shiz> to change the repositories file to point to an online mirror
22:00 <Shiz> instead of the limited cache on the livecd
22:00 mouthbreather joined
22:02 snaphuman joined
22:03 <bahamat> I've only ever used alpine in clouds before, so doing it in fusion manually is a new experience for me :-)
22:06 <snaphuman> Hi everybody. This is my very first time in this channel. I have been using alpinelinux to build docker images just from a few weeks ago. I think this distro is awesome because of its minimalism.
22:08 <Shiz> :)
22:16 <mystified1234> PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
22:17 <mystified1234> I have this dmesg error
22:17 <mystified1234> how can i determine what hardware is causing the problem
22:19 <bahamat> mystified1234: "type=Data Link Layer" indicates network interface to me.
22:21 <mystified1234> thx
22:22 <mystified1234> command not found
22:24 <bahamat> Shiz: Ok, I've got my test case successfully executed. Thanks for your help!
22:24 bahamat left
22:25 ahrs joined
22:25 <Shiz> mystified1234: he wasn't giving you a command, but quoting from your message
22:25 <Shiz> typically, it would show the device in the next line of dmesg
22:25 <Shiz> at device [xxxx:yyyy] ...
22:25 <mystified1234> tx
22:26 <Shiz> compare that xxxx:yyyy to the IDs in lspci -vv
22:26 <Shiz> to find the device
22:32 atomi joined
22:43 bahamat joined
22:44 <bahamat> Ok, I've definitely found a bug.
22:44 <bahamat> But, I think it may be a musl bug, not really alpine.
22:45 <bahamat> If you use Google DNS ( and try to resolve a name that needs to upgrade to EDNS, name resolution fails.
22:46 <bahamat> Could someone independently verify this with me?
22:46 <dalias> "upgrade to EDNS" ?
22:47 <bahamat> DNS replies have a maximum size and may not be fragmented. If a reply is too large to fit in the DNS reply it's retried with EDNS over TCP
22:49 <dalias> there's no stub-relevant query that can't fit in normal dns
22:50 <dalias> if you're doing dnssec (main application) you need a local dns on
22:50 <dalias> stub does not (and should not) verify signatures; instead it needs to trust a local dns that can do the signature verification
22:51 <dalias> in short, it's working as designed, not a bug
22:51 <Shiz> im not sure i agree
22:51 <Shiz> there's cases to be thought where a DNS reply can exceed udp size
22:52 <Shiz> (agree on the dnssec part, though)
22:52 <bahamat> I absolutely know that's the case.
22:52 <dalias> it's a bug for applications to rely on those because in many/most instances you can't perform such lookups
22:53 <dalias> and the only way it can happen is with near-max-length CNAME pointing to a near-max-length other name that doesn't compress well with the CNAME
22:53 <Shiz> because in many/most instances you can't perform such lookups <-- why?
22:53 <bahamat> dalias: It's a bug for the resolver to return 'bad address' when there's a valid record.
22:53 <dalias> because most sites don't have tcp dns available
22:54 <Shiz> that's a bug in the site then
22:54 <dalias> tcp dns is not for stub resolver use
22:54 <Shiz> my site happens to have it available just fine
22:54 <dalias> it's for zone transfers, etc.
22:54 <bahamat> If a site is serving records that are too large and also doesn't support edns, then yeah, that's their problem.
22:54 <dalias> i mean the client site
22:54 <dalias> not the server site
22:54 <Shiz> i mean
22:54 <bahamat> Well it works with glibc.
22:54 <Shiz> my client site happens to have it available just fine
22:54 <bahamat> It works with FreeBSD.
22:55 <bahamat> It works with musl when the resolver is not Google.
22:55 <dalias> musl never does tcp
22:55 <bahamat> It's just musl and
22:55 <dalias> can you determine why it happens with
22:55 <bahamat> I can tcpdump it
22:56 <dalias> even if they appent bogus extra records, musl should accept truncated replies just fine
22:56 <bahamat> But I wanted to make sure someone else could verify the behavior I'm seeing.
22:56 <dalias> is it a domain i can try the lookup on?
22:57 <dalias> btw treating a domain that can't resolve because of technical issue like this as nxdomain rather than an error is probably wrong if that's happening
22:57 <bahamat> bigname.zonena.me
22:58 <bahamat> dig works fine. ping will exhibit the error if /etc/resolv.conf uses as the first nameserver.
23:01 <dalias> not sure what to make of it. is returning a bogus (empty) response
23:02 <bahamat> Did you tcpdump it yet? That's my next step.
23:02 <dalias> yeah, nothing interesting. it looks empty
23:03 <bahamat> Hmm.
23:04 <dalias> if we could distinguish this bogus response from a valid negative result we could ignore it
23:04 <dalias> and then if you have other nameservers they'd succeed
23:04 laj joined
23:05 <sirnaysayer> all the wiki entries for Xorg setup reference Xorg -configure as an option, when that would never work because of musl
23:05 <sirnaysayer> w0w
23:07 <dalias> ?
23:20 <dalias> bahamat, have you looked at the dump? any idea why it looks like an empty reply?
23:20 <bahamat> dalias: I haven't yet.
23:20 <bahamat> I was spinning up some instances with different libc implementations to compare
23:21 <dalias> i would compare the tcpdump too
23:21 <bahamat> Yeah.
23:21 <dalias> just in case there's a difference in the query that leads to a difference in the reply
23:23 <bahamat> So, I've tried glibc, FreeBSD, illumos, Darwin. Musl is definitely the outlier.
23:25 <dalias> that doesn't tell anything about why it's happening
23:25 <dalias> can you even tell if the others successfully look it up with
23:25 <dalias> or if they perhaps just ignore the empty response and get the result from another fallback ns
23:25 steven left
23:26 <bahamat> Yes, all of the others successfully look it up against
23:26 <bahamat> I'm getting ready to tcpdump on each of them to provide as comparisons.
23:26 <Shiz> dalias: quick off-question
23:26 <Shiz> = note: /usr/lib/gcc/x86_64-alpine-linux-musl/6.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/rustc.1RyuI3Lx271V/libunwind-2751140f63f73bc6.rlib(Ltrace.o): relocation R_X86_64_TPOFF32 against `tls_cache_destroyed' can not be used when making a shared object; recompile with -fPIC
23:26 <Shiz> do you know which side should be compiled as relocatalbe in this case?
23:27 <Shiz> is it Ltrace.o or the .o that contains tls_cache_destroyed
23:30 <dalias> the .o file containing that reloc was miscompiled
23:30 <dalias> so Ltrace.o I think
23:30 <dalias> TPOFF32 is not a valid TLS reloc type in shared libraries
23:32 <Shiz> hmm...
23:33 <Shiz> >Ltrace.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
23:33 <Shiz> curious
23:35 <dalias> bahamat, ok i straced the lookup (easier than tcpdump)
23:35 <dalias> has a buggy response
23:35 <dalias> it really is an empty reply
23:35 <dalias> it has the TC (truncated) flag set
23:36 <dalias> but in that case the part of the response that fits should be included
23:36 <bahamat> I see.
23:36 <bahamat> So other implementations are retrying with edns simply based on the tc flag.
23:37 <dalias> i guess so
23:38 <dalias> now, wonder who we report this to....
23:38 <bahamat> I wonder if they're doing it as some sort of bandwidth saving measure.
23:39 <dalias> hmm, maybe they consider your ridiculously long record as a malicious one crafted for ddos amplification?
23:40 <bahamat> Possibly?
23:40 <dalias> in any case...
23:40 <dalias> even if other libcs do use tcp/edns, by having an oversize record like this, you're badly impacting performance
23:40 <dalias> instead of 1 udp round trip
23:41 <dalias> you have 1 failed udp round trip, then multiple tcp round trips
23:41 <dalias> to get the result
23:42 <dalias> got the issue tracker, i'll post a bug report and see what happens
23:48 lesion joined