freenode/#devuan/ Sunday, 2019-04-21

andi89giMorning guys;) Happy Easter. How are you? Going to give Devuan a try because of init-system. It's more freedom, isn't it?08:28
andi89giwhen does Devuan 3.0 will be published?09:04
Centurion_Danandi89gi: when it's ready... probably soon after Debian Buster.09:46
andi89giCenturion:Dan: ah okay cool - mid of this year  I guess ,isn't it?09:49
andi89giCenturion_Dan: How can I help you on dev process? I've got programming skills. Bugfixes, maintaing ?09:52
andi89giwriting you later on ;) cu later10:00
stratactI have no issues with using Beowulf, pretty stable as is.10:01
stratactHowever I'm new to Devuan and I would like to swap the init system with runit, not sure if there is an easy way.10:04
averagestratact: I feel like it's easier to get a distro that's designed with runit from the very beginning https://bit.ly/2vgWzLj10:07
averagestratact: and there are two such distros: void, artix .   https://distrowatch.com/table.php?distribution=void ; https://distrowatch.com/table.php?distribution=artix10:08
averagestratact: swapping the init system for a  different one would mean that you'd have to rewrite all init files for all packages yourself in the new init system of your choice.. which can be impractical..10:10
averagestratact: so that's why i would opt for a different distro..10:10
averagestratact: or is runit compatible with already existing init scripts of devuan?10:10
stratacthey average, I've tried void but sadly I've had stability issues with it and it doesn't have a wide variety of packages by default. The reason I prefer devuan is because of its debian base and it's stability/reliability. I've been through a lot of broken distros and I'm looking for stability above all else :)10:23
Evilhamstratact: i use runit extensively, but not as an init10:43
Evilhamstratact: haven't had the need for that :-p, basically, whatever I need to have running reliably, I use with runit :-)10:45
Evilhamstratact: but booting and runlevels and bla bla, I keep with sysvinit10:46
EvilhamQuite a few do the same actually10:46
andi89giHi guys;) I'm back now - How's the best way to start helping you on contributing?14:59
Evilhamandi89gi: check what I wrote earlier on #devuan-dev :-)16:41
andi89giEvilham: Could you pls post the what you wrote earlier on #devuan-dev;)?16:44
Venkerhi people17:07
averageyes Venker17:07
Invader_Borkhi, is there a way to opt out of installing libre office and the like but still installing a wm using the graphical installer?17:07
averageInvader_Bork: maybe opt for some minimal install17:08
fsmithredyeah, unselect everything except standard system at the tasksel window17:09
fsmithredwhen you reboot, you can install what you want17:10
Invader_Borkand install manually the vm17:10
fsmithredwm?17:10
Invader_Borkwindow manager17:10
fsmithredwhich wm or desktop do you want?17:10
Invader_Borkxfce417:10
Invader_Borks/vm/wm17:10
fsmithredok, so don't install task-xfce-desktop17:11
fsmithredyou can install xfce4 (a metapackage) or you can install the individual parts.17:11
fsmithredif you know which parts you want17:11
Invader_Borkthat works too17:11
Invader_Borkthank you!17:12
fsmithredyw17:12
golinuxfsmithred: He wanted to use a graphical installer.17:54
golinuxI thought that option was only available in expert install.  Maybe I'm confused . . .17:54
EvilhamThere is a graphical expert install18:00
EvilhamWith mouse support:-D18:00
Venkersee you  :)18:01
golinuxCool.  I didn't know that.18:01
fsmithrednon-graphical installer is actually easier to use18:09
fsmithredgotta go. bbl. (few hours)18:10
golinuxThat is what is usually recommended18:10
_abc_Perhaps by Rubini or Kroah ? I found some pdf's online like "understanding the linux kernel" and "the linux kernel" by others. Anything else I should be aware of?18:56
_abc_https://www.kernel.org/doc/ this is also a good starting point, but I would like to cut to the chase: boot process, initrd issues, pivot_root18:58
_abc_ok, the document I was seeking was more or less this one, with links https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-some-unfinished-business19:32
_abc_Hmm, dracut would be a loose r2u "competitor", but it comes from THAT development house. Would one say it is "safe" to use dracut in devuan at all? https://dracut.wiki.kernel.org/index.php/Main_Page19:42
_abc_(no: never: dracut is systemd oriented 100%)19:43
_abc_this raises my hair on end, AND explains at least in part why halt does no longer umount the system volumes. Systemd contamination. https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_dracut_on_shutdown19:45
_abc_Note systemd does all the umounting!19:45
_abc_This completely duplicates the functionality in live-boot, the copy binaries before rootfs ro remount/umount at the end in /etc/init.d/halt on devuan and other sysvinit based systems19:46
_abc_Conclusion: devuan systems should use one of my hacks to patch /etc/init.d/halt to prevent unclean volumes after live-boot session end on all live media for devuan imo.19:47
djphwhat19:48
_abc_Of course this is moot on read-only booted iso's but anything else will be corrupted on shutdown without patching /etc/init.d/halt as I explained yesterday too.19:48
_abc_djph: nice interjection. Need more details to answer that. Ask.19:48
_abc_djph: ?19:53
djph_abc_: makes no sense in general19:54
_abc_Really? Booting a live devuan like ascii, with persistence volume or LUKS in loop dev, leaves the persistence and or the LUKS unclean on shutdown every time without this.19:55
_abc_djph: ^19:55
_abc_Was discussed last Summer in June and now again, other system.19:55
_abc_Eg running systemd less dracut less live wheezy (!) has the problem already.19:56
djpho...kay19:56
_abc_In addition to that, using a live usb stick made with refracta2usb with ascii or wheezy as system and boot partition on vfat causes both the vfat and the separate "system" persistence partitions to be left unclean at shutdown.19:57
_abc_With enough reboots, this will lead to destruction of the system for no good reason.19:57
_abc_I discussed this here with fsmithred and also gnarface and others yesterday.19:58
_abc_Is this channel logged at all?19:58
_abc_I really need to get my act together and have a site where I put up my patches and some relevant ramblings, maybe my old site at peter5.50webs.com19:58
_abc_Related: do not install dracut on devuan, it is a systemd stooge. I assume it does not work at all without systemd.20:00
gnarface_abc_: i remember there was an issue like that with raspbian that was blamed on a bug in the version of the tools, but i think it has since been fixed...20:02
gnarface_abc_: specifically the issue with vfat partitions showing up with the "dirty" bit set after a supposedly clean reboot.  iirc it was just a bug in it's ability to actually clear the dirty bit.20:03
gnarfaceso it would "clean" them properly except for that step20:04
gnarface(but of course it was still a showstopper because it would halt the boot at that point)20:04
_abc_The point is it is still occurring now, with devuan ascii, and beowulf. fsmithred said he has the problem and it was fixed using my script from June 2018.20:22
_abc_Meanwhile I experimented with the cli after booting with init=/bin/bash and I had some success with umount -fl /dev/$root etc; this umounts "lazy" but the umount may occur immediately, so a proper copy-out of needed things into tmp or similar is needed before issuing it.20:23
_abc_Using shutdown -n as I said yesterday, instead of /sbin/halt, in /etc/init.d/halt fixes it.20:23
_abc_I will write this stuff up on a page and put it up. It keeps re-occurring.20:24
_abc_The problems are not devuan specific, per se. The system I fixed yesterday and today was a wheezy live iso from linuxcnc.org. It's sysvinit scripts are identical with those used in ascii.20:25
gnarfacehmmm, ok then20:31
gnarfacea long time ago, if the drives didn't unmount after a certain timeout and number of syncs, something would go through and kill all the processes still running that were accessing any disks20:33
gnarfacein an attempt to allow them to cleanly unmount20:33
gnarfacesometimes (very rarely) that would hang indefinitely20:33
gnarfacebut i think i would like that functionality back20:33
gnarfacebecause usually then you can figure out what it is doing it, and just not use whatever it is if they won't fix it20:34
_abc_Indeed. And freebsd (and Junos which is freebsd based) still do that gnarface20:34
gnarfaceit would be nice to at least have the option as a debconf setting or something like that20:34
_abc_It does take ages in the era of lightning speed boot requirements - which only idiots who are pushing linux in the container with pay per minute use need. We are not those people.20:34
gnarfaceyea, agreed.20:35
gnarfacewe are not those people and they shouldn't be the ones making decisions for the whole community.20:35
_abc_I reboot my machine(s) like twice per year, or whatever the power supply situation forces on me, when not upgrading from zero.20:35
_abc_5 minutes do not matter in that picture and when the shtf, because reboots can be unsheduled I WANT THOSE SLOW MESSAGES ON SCREEN.20:36
_abc_When was wheezy "new" ish last time? Rolled out of oldstable? 2015?20:36
_abc_The problem was introduced about then.20:37
_abc_Wheezy reached support EOL in 2018, was 1st released in 2013 as 7.0, last in 2016 as 7.11 .20:38
_abc_So sometime between I assume 7.0 and 7.11 the sysvinit things changed in the init scripts.20:39
_abc_https://stackoverflow.com/questions/3330349/where-can-i-find-the-source-code-of-the-halt-tool this20:40
_abc_https://github.com/limingth/sysvinit/blob/master/sysvinit-2.88dsf/src/halt.c looks like it's unchanged since 200420:42
_abc_So someone changed the sysvinit scripts at some time, moving from shutdown final command to halt?20:42
_abc_Note halt executes shutdown...20:43
_abc_ref: debian manpages https://manpages.debian.org/unstable/sysvinit-core/halt.8.en.html "halt should never be called directly" ?20:45
_abc_golden comment on the -h flag in NOTES20:46
_abc_The horror story continues: in the initrd in wheezy, one finds: /lib/live/boot/FIXME :: quoting it: Additionally, this will allow us to abstract initramfs-tools integration to also support other initrd generators, such as dracut.21:03
_abc_systemd contamination confirmed in wheezy21:03
_abc_dracut is 100% systemd21:03
_abc_There seems to be a lot of concern about "not breaking mono" in the live-boot scripts. In other words, they wrote boot scripts to accommodate ONE high level application framework originated outside the open source community. Mono is better known as .NET by m$. Mono is the open sores re-implementation. Guess who cares a lot about supporting it? Our favorite OS breakers.21:09
_abc_I saw comments like "run-init can't deal with images in a subdir, but we're going to move all of these away before it runs anyway.  No, we're not, put them in / since move-mounting them into / breaks mono and some other apps." in several files so far, all authored/co-authored by the same team. The above is from /lib/live/boot/9990-overlay.sh in initrd in wheezy, should be the same in ascii live.21:10
golinux(_abc_ is having (mostly) a nice monologue)21:13
golinux(or soliloquy . . .)21:14
_abc_I would call it a disaster in motion21:15
_abc_The live-scripts in the initrd deal with mounting persistence volumes (including from nfs - what the hell?) in file /lib/live/boot/9990-overlay.sh21:16
_abc_There we find a lot of cleverness which is imo wasted time, for things no-one really uses on a live persistence system (nfs? - hello thin clients, you're so 1990s)21:17
_abc_And then we find that the script simply mounts every volume in the system, looking for the persistence label, WITHOUT fsck attempt. There is not even one comment about it.21:17
_abc_So, for decency, one really wants to attempt a fsck there, assuming the relevant fsck is installed in the initrd.21:20
_abc_For now, I stop here. At least I know where the problem lies.21:21
_abc_[comments welcome]21:21
_abc_golinux: you have the milk crate.21:21
golinuxLOL!  That wasn't a complaint.  Merely an observation . . .21:33
_abc_LOL I think the initrd scripts are so snafu'd, not systemd related this time, that the only way to make sense is to blanket edit all mount calls to safe_mount and script that to fsck using a fsck on initrd before any mount of a non nfs fsck-able fs.21:35
_abc_Crazy spaghetti code in there galore. At least there are comments. I still do not have a clear picture of the whole mess, will have to draw up a call tree.21:36
golinuxI actually appreciate your thoroughness.  If fsr were around you'd have someone to talk to.  All this is way over my head.21:36
_abc_No problem, I assume he reads irc backlogs now and then.21:36
_abc_We'll see. So far, I put out both fires which were burning, not leaving dirty fs's on shutdown from live+persistence sessions, and finding the place(s) where a fsck should be added in the initrd to fix any such mishap, should it occur.21:37
_abc_The initrd fix is not too bad if I simply (ha) move /sbin/mount on the initrd to /sbin/mount.bin and replace it with a script which checks if the thing to mount is fsck-able with what is available on the initrd, and warns as needed on the console. With a pause on each error so the poor user can read the warning.21:39
_abc_As is, there is no fsck at all on the initrd21:39
_abc_That's not a problem, one can push them into the initrd and rebuild it.21:40
fsmithred_abc_, I haven't read all the scrollback yet21:40
_abc_fsmithred: take your time, there was some rambling too.21:40
fsmithredI got the sources for sysvinit in beowulf and squeeze and compared some of the files21:40
_abc_oh. Bbin221:40
fsmithredsources.debian.org did not have source for wheezy sysvinit21:40
fsmithredyou want to see it?21:42
_abc_fsmithred: no, I think the problem predates wheezy. There's archive.debian.org iirc?21:44
_abc_fsmithred: did you find something concrete?21:44
_abc_I can't tell when things broke21:44
_abc_I.e. how long ago. They were broken in wheezy times. There is no atttempt at all in wheezy era initrd live scripts to fsck anything. Which is scary since it means ALL initrd based systems will happily mount un-fsck'd fs's behind the scenes, before the main system boots and tries to fsck them.21:46
_abc_There is no fsck program installed at all in the initrd, on wheezy, ascii at least21:46
fsmithredconcrete? I don't know - I can't read c.21:47
_abc_fsmithred: ok, what do you have, the source of halt.c?21:47
fsmithredyes and shutdown.c21:47
_abc_halt.c resorts to calling shutdown as you probably saw.21:47
fsmithredI thought I also had reboot.h, but I'm not finding it now21:47
fsmithredI'll paste it21:48
_abc_fsmithred: reboot and poweroff are symlinks to halt21:48
_abc_fsmithred: I have it all, it has not changed much since 2004?21:48
_abc_fsmithred: $sig Miquel van Smoorenburg 2004 ?21:48
fsmithredhttps://termbin.com/2fb321:48
_abc_thanks21:49
_abc_The perverse part is, if I use halt for stopping the system, it will call shutdown, and end up unclean. If I call it by hand, shutdown -n, it comes out clean.21:49
_abc_I am somewhat stumped by this till now21:49
fsmithredso the problem is with the way init does the shutdown?21:54
_abc_I do not know. I assume so. Since shutdown -n avoids init21:56
_abc_Which brings us back to another favorite theme: init changes due to systemd "compatibility"21:56
_abc_fsmithred: in your diff, @@ -743,20 +786,40 @@ :: that is dangerous, "Jesse" patched the timeout from count-minutes to wall clock time consideration "if the computer was asleep" meanwhile. That won't work well. The correct action is to cancel a pending shutdown if sleep is entered.21:58
_abc_Since shutdown clock time does not wake from the sleep state, by itself. A modified atd can do that. I wrote a tiny utility for this way back when, should be on peter5.50webs.com/free/21:59
fsmithredsorry, I'm lost22:01
_abc_fsmithred: unrelated: so, what I see in the patch you posted, is just cosmetics so far, and move from /etc/nologin to /run/nologin etc22:01
_abc_Not writing to the /etc tree in general, this was a general fsstnd move, a good one22:02
fsmithredyeah, a bunch of stuff has moved to /run22:02
_abc_fsmithred: re: atd: atwake utility @ peter5.50webs.com the description explains it.22:03
_abc_It's functionality is in atd now, I think.22:03
_abc_atwake by me from 201122:03
_abc_fsmithred: opinion on modifying initrd such that: a) fsck.ext2 fsck.ext3 fsck.vfat and libs are added b) the /bin/mount on the initrd is moved to /bin/mount.bin and /bin/mount becomes a script which will try to fsck any fs it is asked to mount, if the relevant fsck is installed on the initrd, and then call /bin/mount.bin as called?22:07
fsmithredthat sounds right22:09
fsmithredto fix the dirty shutdown requires replacing the binaries in the live system?22:10
fsmithredor is it possible to fix both things at once?22:10
_abc_Fixing the shutdown can be done in the persistence volume22:11
fsmithredyeah, ok22:11
fsmithredI'm just thinking about where to fit these in22:11
_abc_Apply either my June 2018 shutdown or yesterday's shutdown -n instead of halt in /etc/init.d/halt in the persistence volume22:11
fsmithredoh22:12
_abc_fsck the fs's from another boot, then boot into it, and it will shut down clean22:12
fsmithredthe latter sounds better (less to do)22:12
_abc_The initrd, as long as it is made with your r2u, which mine is, can be edited into the initrd, and will try to fsck the volumes (any) for every mount attempt from within the initrd scripts.22:12
_abc_That is a separate issue, working on it.22:12
fsmithredI would most likely make that optional22:13
_abc_fsmithred: that would be good yes, I plan to add a sleep and print fsck status on the console while that script runs, for any error found22:14
fsmithredsounds good22:14
fsmithredI like feedback from the system22:14
_abc_It is scary that so many people run live systems, even with LUKS persistence, and do not know they're sitting on a bomb. Every shutdown leaves the persistence volume dirty so far.22:14
fsmithredbeen doing it for years22:15
_abc_This seems to have been true since wheezy. I caught it on ascii last year reading dmesg for other reasons.22:15
_abc_Then the June sessions ensued which led to the June script you used already.22:15
fsmithredthere are a few posts about this on debian-live mailing list22:15
fsmithredold posts22:15
_abc_People just give up after a while. Someone calls open source open sores. It's true, but, unlike internal beleeding and gangrene, there is hope.22:16
fsmithredlol22:16
gnarfacethis was clearly a hit job22:16
fsmithredI thought it was odd that the wheezy source for sysvinit was missing22:17
_abc_is it not on archive.debian.org ?22:17
fsmithredI couldn't find any sources at archive.debian.org22:17
fsmithredthey're at sources.debian.org22:18
fsmithredjust not all of them22:18
_abc_https://www.debian.org/distrib/archive this is too olf22:18
_abc_*old22:18
fsmithredall the way back to hamm22:18
_abc_wheezy (7.x) is too "new" for that22:19
fsmithredhttps://sources.debian.org/src/sysvinit/22:19
_abc_Interesting. It seems to have fallen between the chairs? Rotated out of oldstable/EOL but not into arhchives?22:20
_abc_Did you ask on #debian? Or are you known as a pariah there?22:20
_abc_(for #devuan affinity reasons)22:20
fsmithredI don't go there22:20
fsmithrednever have22:20
_abc_:)22:20
fsmithredexcept for a few times, and a few of those times, it was by accident22:21
fsmithredfrom what I've heard, nobody gets treated well there22:21
fsmithredso I wouldn't feel special if they flamed me22:21
_abc_I just went there and asked.22:22
_abc_I have a thick hide and I'm furniture on several freenode channels.22:22
_abc_Not there.22:22
fsmithreddid you ask if anyone has the source code?22:22
fsmithredI did install debian today, so I guess I could go there22:24
_abc_I asked in general where the wheezy stuff is, linking the archive which does not have it. The one I linked before here. Wait, I got answers.22:24
fsmithredbut I didn't install gnome, so maybe not22:24
fsmithredback in 522:26
_abc_https://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian/dists/ fsmithred some wheezy in there22:26
_abc_https://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian/dists/wheezy/main/source/ 7MB src? A bit small?22:27
_abc_Or is that 7GB22:27
_abc_7MB src names only22:28
_abc_Strange, I can't locate the wheezy packages in there fsmithred - you seem to be right.22:31
_abc_This is not nice, but what can I say.22:32
_abc_C'est la vie?22:32
fsmithredmaybe we can get it from Jessie Smith22:32
fsmithredcurrent maintainer for sysvinit22:33
fsmithredgolinux, what's the name of the init mailing list?22:33
_abc_Ok, I'll stop for now, we'll see what comes up. The init in ascii is the same version as in wheezy?22:34
fsmithredthe script in /etc/init.d, yes22:34
fsmithredthe binaries, I don't know22:34
fsmithredI compared beowulf to squeeze22:34
_abc_That I already know. What about /sbin/init version?22:35
fsmithredcan check...22:35
_abc_You're much better at using debian tools and archives than I am. Go for it, please.22:35
fsmithredBinary files /mnt/sdb2/sbin/init and /sbin/init differ22:35
_abc_Hmm.22:36
_abc_fsmithred: try size on them? Same arch? x86 not x86 vs x86_64?22:36
golinuxfsmithred: www.chiark.greenend.org.uk/pipermail/debian-init-diversity/22:36
fsmithredthanks22:36
_abc_-diversity ?!22:36
golinuxThere is also this list https://lists.debian.org/debian-devel/22:37
fsmithred_abc_, same arch, different sizes22:38
fsmithredcomparing wheezy to jessie now22:38
_abc_Significantly different? I assume both are stripped?22:38
_abc_I mean more than 10% or so different?22:38
fsmithred 37064 May 29  2015 /sbin/init22:38
fsmithred36992 Jul 14  2013 /mnt/sdb2/sbin/init22:38
_abc_C compilers are strange, apart from evolving, which leads to better optimization, sometimes *adding* code makes the output smaller.22:39
_abc_fsmithred: that is not a significat difference in size.22:39
fsmithred57032 Feb 26 16:59 /sbin/init22:39
fsmithredbeowulf22:39
_abc_That is quite different yes22:39
_abc_Still same arch?22:39
_abc_And stripped?22:39
fsmithredyes22:39
fsmithredamd6422:40
fsmithredstripped?22:40
_abc_Perhaps beowulf is built with debug flags in it?22:40
fsmithredI take whatever the repo gives me22:40
_abc_fsmithred: run file on it, it can say stripped or unstripped ELF22:40
fsmithredascii is 3706422:41
_abc_file(1) will tell you if it is stripped or not22:41
_abc_fyi stripped means any debug symbols and object names not needed for runtime linking were removed from the ELF binary.22:41
fsmithredstripped in wheezy and beowulf22:42
_abc_debug builds leave them in, that makes the binaries large but debuggable with meaningful output in gdb22:42
_abc_fsmithred: ok so beowulf had a major change in the source22:42
_abc_The question is, what. Are they all dynamically linked per file(1) ?22:42
fsmithredyeah, some old bugfixes22:42
_abc_Old bugfixes won't double the size of the binary.22:43
_abc_Compiling it static (recommended for system progs!) would.22:43
fsmithredanswer is probably in the init diversity ml archive22:43
_abc_But it would be much larger than 57k if compiled static.22:43
_abc_fsmithred: there should be release notes for the ini version released with beowulf? That is not unreachable? Unlike wheezy's?22:44
fsmithredI have the changelog for wheezy22:47
_abc_I think the changelog for beowulf will be more interesting at this point. But bring it. Anything interesting in it?22:48
fsmithredI have that, too. Scrolling down to make sure it continues from the older one22:48
fsmithredit does22:49
fsmithredRestore umount at shutdown of filesystems mounted before /usr22:50
fsmithredoh, you want bug numbers?22:51
fsmithredwant the whole log?22:51
_abc_I don't know. Does not sound like a bugfix release.22:52
_abc_ldd /sbin/init would also be something to compare.22:52
_abc_Perhaps the beowulf one has more things linked into it vs older ones22:52
fsmithreddo I need to chroot wheezy to do that?22:52
_abc_Personally I'd like to see old-way initrd and system tools, all statically linked, for boot and rescue reasons22:53
_abc_fsmithred: no22:53
_abc_fsmithred: it will report some libs not found but what matters is which lib names, and if they're the same ones, disregarding versions22:53
fsmithredexact same libraries22:53
fsmithredwheezy/beowulf22:54
_abc_Interesting. Well, something changed from ascii to beowulf to make the binary twice as big22:54
Venkerhi people22:54
gnarfacewelcome Venker.  if you have a question just ask it.22:54
gnarfacein some cases you might have to wait a long time for a response22:55
fsmithredELF 64-bit LSB executable vs ELF 64-bit LSB pie executable22:55
_abc_I don't know what PIE is22:55
fsmithredneither do I.22:56
fsmithredsomeone explained it to me once, but that's gone22:56
_abc_https://unix.stackexchange.com/questions/89211/how-to-test-whether-a-linux-binary-was-compiled-as-position-independent-code22:56
_abc_ANOTHER Rat Hat "feature". Doubled binary size in the process? No problem?22:57
_abc_Would be worth asking in #programming a bit if they know of the size side effect of -pie -fpie gcc options22:58
_abc_It's a security feature apparently22:59
fsmithredyeah, this sounds familiar22:59
fsmithredI need a nap22:59
gnarfacesomething to do with anti-stack-smashing maybe?22:59
fsmithredate too much at a brunch22:59
_abc_ok23:00
fsmithredPosition Independent Executables (PIE) receive stronger address space randomization (ASLR) protectio23:00
_abc_gnarface: I don't know exactly what is involved and what it fixes.23:00
_abc_I asked in #programming and will also in #workingset23:00
fsmithredbbl23:01
detha_abc_: no use of absolute addresses, so the loader can easier shuffle things around23:01
_abc_well relative address use should result in a smaller binary. At least from what I remember from my sessions.23:02
dethanope, binary now has extra type indicators + address where otherwise it would just have been address23:04
_abc_Hmm that means not just all indexed addresses but also checks?23:05
_abc_Sounds like some bad plan? Slow down execution to half speed?23:05
dethanot really23:05
_abc_Potentially, from a trivial analysis at least?23:05
dethaposition independent code is nice. Alas, stupid intel CPUs are not built for it.23:06
_abc_Iirc pointer range checking is a separate compiler feature, has it's own switch flag. Does this turn that on? Bounds checking and such?23:06
dethanothing to do with checks, just extra indirect loads23:07
_abc_Is that not simply offloaded to the silicon using mov ax, [bp+...]23:07
dethathat's loading from stack23:08
dethaNow also things like globals or static strings like printf formats can be anywhere23:09
_abc_Depends where bp points. Just as an example for indexed.23:09
_abc_Well when I code such things in asm for embedded (not x86) one uses a per-section or per-program base index register in ram and everything is indexed relative to it. Cheap relocation.23:10
_abc_And it's not expensive usually, since the cpu's can mostly do indexed indirect addressing with offset, no extra instructions.23:10
_abc_Microchip PIC (excepting PIC32 which is MIPS 4k) cannot do this, have to do it manually, it is a chore then.23:11
_abc_I have not coded for x86 since 8086/8088 days, not in asm. I am SURE there are inidrect indexed instructions for everything.23:11
dethaYup. I made an OS for mc68k once where everything was relative to one base register, loader can throw the process anywhere ini mem, set base register, and it will run23:12
* _abc_ nods23:12
_abc_Well I got suggestions to use objdump -d /sbin/init and similar :) That does work, depending on who reads the disassembly :^)23:28
_abc_objdump -d /sbin/init here on a x86 non 64 system shows the usual static calls, I assume the output on the -pie binary will differ significantly23:28
_abc_fsmithred: here? Can you do something like: objdump -d /sbin/init|head -50 on the _64 system and pastebin it? I am curious now? Thanks.23:29
dethahttp://paste.debian.net/1078726/23:39
_abc_is that from beowulf?23:39
_abc_ detha: ^ ?23:39
detha2.0, whatever it's called23:40
_abc_I'm comparing with my copy of the output for i386 and mine is larger... so far.23:42
_abc_Sections take more bytes to do the same thing apparently23:42
_abc_My .init uses 36 bytes for example23:43
_abc_Yours uses 27?23:44
_abc_the following jump indirection table in your paste is larger, that would explain some growth.23:45
dethathere's a lot of compiler/linker flags to fiddle with, roughly works out to 'small, fast, secure. Pick any two'23:45
_abc_16 bytes per entry, mine has 14 / entry23:45
_abc_detha: sure but one trusts the artists who run the show with this and also trying hard :)23:45
_abc_So far, I see no reason for a 33% size growth from the disasm,23:46
dethaI have long since given up building own kernels from scratch, have to trust whoever runs the distro23:46
_abc_Oh I do my own, but usually on slackware or openwrt or such.23:47
_abc_I have to. Some crap never works out of the box and I am always "blessed" with old hw and cheap stuff nobody supports. I am an older guy.23:47
dethaI think the only hand-built kernel I currently have is one openbsd box, and only because I needed to patch some stuff in the PPPoE driver.23:48
_abc_Yes, things happen.23:48
_abc_Otoh, how would you fix a closed source thing? Not.23:48
dethaWith money, or beatings of the area manager :p23:49
_abc_Money? The 800lb gorilla has all the money. The guys in suits from Armonk also are loaded. You are going to buy them a beer or what?23:50
_abc_Also you can beat the area manager as long as you like, that won't fix the systems.23:51
_abc_Oh the fun of undocumented bits: printf %03X $(cat /proc/sys/kernel/sysrq) -> 1B623:54
_abc_this is ascii default boot settings23:55

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!