IRC Logs for #crux-devel Wednesday, 2015-10-07

jaegerRomster: dash vs. bash has no effect, wine still fails00:20
Worksterthen it's glibc gcc anyones guess00:22
*** jue has quit IRC00:45
*** jue has joined #crux-devel00:45
jaeger <-- noticed this in the system logs, too00:59
*** heroux has joined #crux-devel01:14
*** ________mavric has quit IRC02:50
*** ________mavric has joined #crux-devel02:51
Worksterjaeger, another idea compile with -O003:03
Worksteri'll have to redo a machine at home to test 3.203:03
Worksteror even try compiling with clang but i haven't tried that yet either.03:04
*** Workster has quit IRC03:26
*** Workster has joined #crux-devel03:32
*** Workster has quit IRC03:46
*** Workster has joined #crux-devel03:49
*** Workster has quit IRC06:23
juefrinnst: I think we can close #1210 and #1211?09:53
frinnstheh, just commented on 1210 asking the same thing10:20
frinnstI've not investigated the perl thingy at all - managed to forget about it10:21
jueok, I'll close 121010:44
*** Romster has quit IRC10:56
*** Romster has joined #crux-devel10:57
frinnstaccording to lfs, perl 5.22 should include s2p/psed11:23
*** jue has quit IRC12:35
*** jue has joined #crux-devel12:37
frinnstgoodie jue, safe to close the ticket then12:47
frinnstand lfs needs to update their docs :-)12:47
frinnstyep, just saw it jue12:48
*** frinnst has quit IRC13:25
*** frinnst has joined #crux-devel13:31
jaegerRomster: building with -O0 allows winecfg to create the prefix, at least. I'll try actually running something when I get home13:51
*** gb00s has joined #crux-devel14:19
jaegeranyone have any objections to this patch?
jaegerCONFIG_UEVENT_HELPER is recommended to be unset these days in the kernel, that patch takes care of checking for it14:28
jaeger(for core/udev)14:29
*** gb00s_ has joined #crux-devel14:47
*** gb00s has quit IRC14:51
frinnstwhat happens if its not unset ?15:09
jaegernothing much, the system still works fine. It's just not recommended anymore. Maybe it'll get removed some time in the future15:10
jaegerIf it's unset, on the other hand, you'll see an error line at boot from start_udev15:10
jaeger(this is cosmetic, the system still works)15:10
frinnstare there any use cases whereas someone might want to have something explicitly set there?15:10
jaegernone that I'm aware of with any recent udev15:11
frinnstjust so we dont fuckup anything a user has manually set up15:13
frinnstother than that, im ok with the patch15:14
*** gb00s_ has quit IRC15:14
*** gb00s has joined #crux-devel15:15
jaegerAll this does is check for the existence of the file before doing what it already did15:15
jaegerif that makes sense15:15
jaegerit suppresses the "no such file or directory" error if the file doesn't exist15:15
jaegerno change in behavior15:16
frinnstah, ok15:16
jaegerregarding cryptsetup - systemd has a defined format for /etc/crypttab but it doesn't seem like sysvinit knows about it by default, so we'll have to come up with some kind of startup script for it on our own15:51
jaegerI'm able to create an encrypted /home and it seems to work properly in my ISO tests, at least15:53
frinnstbtw, all the TODO32 stuff is done, right?16:32
frinnstrp-pppoe was removed? the iso injections are all done too?16:32
frinnstand the filesystem progs are still on the iso, right?16:33
jaegerthey are16:34
frinnsti'll mark it all down as DONE then16:34
frinnst"remove xorg-glamor-egl: merged in with xorg-server" too?16:36
jaegercheck the iso tree :)16:46
frinnstbut that requires me to do *work* :D16:47
frinnstits muuuuuuch more easy to ask and have others doing it for me :D16:47
frinnstremove_packages xorg-glamor-egl <- :D16:48
jaegerbah :P16:58
jaeger <-- a first pass at cryptsetup parsing in /etc/rc16:58
jaegerit only deals with luks format (the default) and doesn't parse options yet, other than the password16:58
jaegerWoot, it works to setup my encrypted /home in the test VM at boot :)17:01
jaegersince cryptsetup is in /usr/bin this wouldn't allow for an encrypted /usr but I could switch it to use the static binary instead if that's necessary17:09
jaegerer, /usr/sbin17:09
jaegerI'll add some shutdown logic as well and prepare a patch for us to test for 3.217:23
jaeger <-- a patch (will test now in my VM)18:47
jaegerteK__, jue: any thoughts on this patch?18:52
jaegerIt seems to work properly in my VM18:53
jaegerI have not included support for encrypted swap or for plain dm-crypt devices. The documentation all says to use LUKS unless you know you need otherwise so support LUKS devices seems like a good choice18:57
jaegerswap probably wouldn't be difficult to add18:57
juehmm, the whole thing looks a bit complicated to me ...18:59
jueI have a single line in my rc.local:19:00
juecryptsetup luksOpen /dev/sda3 home && mount /home19:00
jaegerI feel it's only as complicated as it's necessary to be, honestly19:00
juebut well ..19:00
jaegerto cover some basic error detection19:00
jaegerfor reference, my /etc/crypttab in the VM just contains:19:00
jaegercrypthome    /dev/sda319:00
jaegerI'm not a big user of encrypted stuff, I just took this on because it keeps coming up. If you guys don't really want it, it won't hurt my feelings :)19:01
jaegeryour approach is very simple and straightforward but also very specific to your device and mapping name19:02
juedon't get me wrong, if we want a more general solution it has to be more complicated19:02
jaegerYeah, I was aiming for "somewhat general" but not "all-inclusive"19:03
jaegersomewhat similar to slackware's approach for what that's worth19:03
jueand as always I'm a fan of the most simple solution and that's a entry in rc.local IMO19:03
jaegerI feel like this fits the bill of "allow crux users to set up simple /home encryption out of the box" with the option for each individual user to make it as complicated as he or she likes19:05
jaegerI don't have strong feelings on the matter, though19:06
jueme neither19:06
jaegerThis approach should technically allow encrypting anything but /, /boot, or /sbin out of the box.19:08
jueyeah, looks like19:10
jaegerWe could even remove the OPTS part to forego adding options parsing logic, leaving it up to users to make it more specific/complicated or support plain dm-crypt if they prefer19:11
juewell, I'm still not really convinced that we need anything at all but it's definitely ok for me if you add that to our rc stuff19:15
jaegerIt seems like we've had enough people ask about it over time that having some basic support would be good, I think. A starting point, so to speak19:16
jueyeah, but most of them are asking for a encrypted / IIRC19:18
juebut I think that's out of question for 3.219:21
jueor we have to accept a longer delay IMO19:22
jaegerSince we've not had any official initramfs/initrd support in the past that's a bigger job, yeah19:22
jaegerIf we want to support encrypted / I'd prefer someone who actually uses that functionality do the work, would probably do a better job. /me eyes teK__19:23
jueyep, indeed19:23
jaegerThe encrypted /home (or whatever that isn't /, /boot, or /sbin) seemed like a much easier low hanging fruit :)19:25
juesure :)19:26
jaegerI'm going to encrypt /etc/ports and nothing else! very important data there!19:26
*** rexich has joined #crux-devel20:03
*** gb00s has quit IRC20:17
frinnstyeah I dont use luks either, since i hate laptops and rely on my home being secure :)20:55
*** rexich has quit IRC21:22
teK__after jue tiny hint yesterday, I built a busybox port, suitable for initrd + cryptsetup purposes22:40
teK__it can be found at
*** Workster has joined #crux-devel22:40
teK__I have yet to test it, though :)22:41
teK__still I suppose the job is not that huge because there _are_ patches that wait for testing :)22:41
teK__jaeger: wrt your /etc/rc patch.. won't the kernel autoload the appropriate modules -- if needed --  on cryptsetup invocation?22:43
teK__that patch is '_huge_'22:45
teK__I have been thinking about modularzing /etc/rc "on demand" by having packages bringing their scripts to /etc/rc.local.d (no better name yet, sorry)22:46
teK__candidates would be mdadm, lvm and cryptsetup.22:47
teK__the difference to /etc/rc.d/* stuff would be that these 'should' be mandatory and loaded rather early in the /etc/rc stage22:47
teK__upside: keep /etc/rc very neutral and organizing stuff brought in by optional packages neatly22:49
teK__one could even split that even more like /etc/rc.{once,reboot,startup,shutdown} if one were to get fancy22:50
teK__either as separate directories or within one directory and via filename suffixes/prefixes22:51
teK__same goes for order just like the udev rules do by using number-prefixes22:51
teK__ < tiny adjustments to your neat script, nice idea with the array :)23:08
teK__still curious about the modprobing stuff for dmcrypt.. did you test leaving the modules out? It makes the script bigger than it should have to be23:09
teK__ is the third hit onGoogle for cryptsetup module auto load. Saying: why is there no auto-loading of modules during initrd-phase?23:10
teK__it seems that even ubuntu needs some manual hinting for the modules to get loaded..
Worksterthem run levels are old stuff now right? we don't even use run levels for single user and multi user and X23:14
teK__yes and no, why?23:15
Worksterjust thinking well we do have single user and multi user... about all we use.23:16
teK__take a look at /etc/inittab, there are runlevels23:16
Worksteri can't remember the last time i even used single user init23:16
Worksterthat's where i have seen them yes23:16
teK__me neither ;) I  would try and use telinit 2 (?) after booting with init=/bin/sh.. but I'm lazy so I'm just rebooting any way..23:17
jaegersorry, was out of my office. regarding the modules thing, maybe it would be loaded automatically, I didn't test that. Frankly, the modprobe is a small part of the overall script23:32
jaegerseems like it's not popular, which is fine. Like I said, it won't hurt my feelings if we don't use it.23:33
teK__I like it23:35
teK__and we can lift the load from /etc/rc with the approach I described above.23:35
jaegerinitrd-phase doesn't have udev running, for what that's worth. (in response to the "why is there no auto-loading" question)23:36
jaegerEven after all this time it's a bit fuzzy to me where the kernel leaves off with module loading and udev kicks in23:40
teK__only mdev, yes23:40
jaegerIf you want to use the stuff I've pasted for your modular approach, feel free. For the RC I'll just make sure that cryptsetup is on the ISO (already done that)23:41
teK__my guess is, that udev does not do module loading but react to newly discovered devices. I might be wrong though23:41
jaegerthat would make sense. I haven't really delved into it23:41
teK__jaeger: ok; the thing is, jue won't agree to modularizing optional parts from /etc/rc. I always felt the if [ -f $binary ]; ... approach to be ugly and disorganizing :)23:42
jaegerit seems like when a feature is needed, kmod would try to load it with modprobe if it isn't already loaded. and use modules.dep to figure out dependencies23:43
jaegerthen udev would react to the event to create a new device node or whatever23:43
jaeger(though this is guessing, I haven't researched)23:43
teK__I find it strange that so much user-space magic is involved in this23:44
teK__i.e. the modules not carrying dependencies in them23:44
jaegerYeah, I feel like jue is pretty clear on not wanting to complicate things. I've got no objection to that, I was just shooting for an approach that didn't add TOO much complexity but did allow more accessibility23:44
jaegerif we don't want to be too concerned about accessibility, then leave it out and put it in a wiki page instead, or something like that23:45
teK__my proposal is adding a dircetory and slimming down /etc/rc, actually23:45
jaegerhooks, more or less23:45
jaegerI'd be fine with that, personally. I doubt we'll all agree on it, though23:45
teK__it works for udev and xorg and... % ls -ld /etc/*.d | wc -l23:48

Generated by 2.11.0 by Marius Gedminas - find it at!