| andi89gi | Morning 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 |
|---|---|---|
| andi89gi | when does Devuan 3.0 will be published? | 09:04 |
| Centurion_Dan | andi89gi: when it's ready... probably soon after Debian Buster. | 09:46 |
| andi89gi | Centurion:Dan: ah okay cool - mid of this year I guess ,isn't it? | 09:49 |
| andi89gi | Centurion_Dan: How can I help you on dev process? I've got programming skills. Bugfixes, maintaing ? | 09:52 |
| andi89gi | writing you later on ;) cu later | 10:00 |
| stratact | I have no issues with using Beowulf, pretty stable as is. | 10:01 |
| stratact | However 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 |
| average | stratact: I feel like it's easier to get a distro that's designed with runit from the very beginning https://bit.ly/2vgWzLj | 10:07 |
| average | stratact: and there are two such distros: void, artix . https://distrowatch.com/table.php?distribution=void ; https://distrowatch.com/table.php?distribution=artix | 10:08 |
| average | stratact: 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 |
| average | stratact: so that's why i would opt for a different distro.. | 10:10 |
| average | stratact: or is runit compatible with already existing init scripts of devuan? | 10:10 |
| stratact | hey 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 |
| Evilham | stratact: i use runit extensively, but not as an init | 10:43 |
| Evilham | stratact: haven't had the need for that :-p, basically, whatever I need to have running reliably, I use with runit :-) | 10:45 |
| Evilham | stratact: but booting and runlevels and bla bla, I keep with sysvinit | 10:46 |
| Evilham | Quite a few do the same actually | 10:46 |
| andi89gi | Hi guys;) I'm back now - How's the best way to start helping you on contributing? | 14:59 |
| Evilham | andi89gi: check what I wrote earlier on #devuan-dev :-) | 16:41 |
| andi89gi | Evilham: Could you pls post the what you wrote earlier on #devuan-dev;)? | 16:44 |
| Venker | hi people | 17:07 |
| average | yes Venker | 17:07 |
| Invader_Bork | hi, 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 |
| average | Invader_Bork: maybe opt for some minimal install | 17:08 |
| fsmithred | yeah, unselect everything except standard system at the tasksel window | 17:09 |
| fsmithred | when you reboot, you can install what you want | 17:10 |
| Invader_Bork | and install manually the vm | 17:10 |
| fsmithred | wm? | 17:10 |
| Invader_Bork | window manager | 17:10 |
| fsmithred | which wm or desktop do you want? | 17:10 |
| Invader_Bork | xfce4 | 17:10 |
| Invader_Bork | s/vm/wm | 17:10 |
| fsmithred | ok, so don't install task-xfce-desktop | 17:11 |
| fsmithred | you can install xfce4 (a metapackage) or you can install the individual parts. | 17:11 |
| fsmithred | if you know which parts you want | 17:11 |
| Invader_Bork | that works too | 17:11 |
| Invader_Bork | thank you! | 17:12 |
| fsmithred | yw | 17:12 |
| golinux | fsmithred: He wanted to use a graphical installer. | 17:54 |
| golinux | I thought that option was only available in expert install. Maybe I'm confused . . . | 17:54 |
| Evilham | There is a graphical expert install | 18:00 |
| Evilham | With mouse support:-D | 18:00 |
| Venker | see you :) | 18:01 |
| golinux | Cool. I didn't know that. | 18:01 |
| fsmithred | non-graphical installer is actually easier to use | 18:09 |
| fsmithred | gotta go. bbl. (few hours) | 18:10 |
| golinux | That is what is usually recommended | 18: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_root | 18: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-business | 19: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_Page | 19: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_shutdown | 19: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 systems | 19: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 |
| djph | what | 19: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 general | 19: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 |
| djph | o...kay | 19: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.com | 19: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 |
| gnarface | so it would "clean" them properly except for that step | 20: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 |
| gnarface | hmmm, ok then | 20:31 |
| gnarface | a 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 disks | 20:33 |
| gnarface | in an attempt to allow them to cleanly unmount | 20:33 |
| gnarface | sometimes (very rarely) that would hang indefinitely | 20:33 |
| gnarface | but i think i would like that functionality back | 20:33 |
| gnarface | because usually then you can figure out what it is doing it, and just not use whatever it is if they won't fix it | 20:34 |
| _abc_ | Indeed. And freebsd (and Junos which is freebsd based) still do that gnarface | 20:34 |
| gnarface | it would be nice to at least have the option as a debconf setting or something like that | 20: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 |
| gnarface | yea, agreed. | 20:35 |
| gnarface | we 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 this | 20:40 |
| _abc_ | https://github.com/limingth/sysvinit/blob/master/sysvinit-2.88dsf/src/halt.c looks like it's unchanged since 2004 | 20: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 NOTES | 20: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 wheezy | 21:03 |
| _abc_ | dracut is 100% systemd | 21: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 motion | 21: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.sh | 21: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 |
| golinux | LOL! 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 |
| golinux | I 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 initrd | 21: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 yet | 21:40 |
| _abc_ | fsmithred: take your time, there was some rambling too. | 21:40 |
| fsmithred | I got the sources for sysvinit in beowulf and squeeze and compared some of the files | 21:40 |
| _abc_ | oh. Bbin2 | 21:40 |
| fsmithred | sources.debian.org did not have source for wheezy sysvinit | 21:40 |
| fsmithred | you 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 broke | 21: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 least | 21:46 |
| fsmithred | concrete? 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 |
| fsmithred | yes and shutdown.c | 21:47 |
| _abc_ | halt.c resorts to calling shutdown as you probably saw. | 21:47 |
| fsmithred | I thought I also had reboot.h, but I'm not finding it now | 21:47 |
| fsmithred | I'll paste it | 21:48 |
| _abc_ | fsmithred: reboot and poweroff are symlinks to halt | 21: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 |
| fsmithred | https://termbin.com/2fb3 | 21:48 |
| _abc_ | thanks | 21: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 now | 21:49 |
| fsmithred | so the problem is with the way init does the shutdown? | 21:54 |
| _abc_ | I do not know. I assume so. Since shutdown -n avoids init | 21: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 |
| fsmithred | sorry, I'm lost | 22: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 etc | 22:01 |
| _abc_ | Not writing to the /etc tree in general, this was a general fsstnd move, a good one | 22:02 |
| fsmithred | yeah, a bunch of stuff has moved to /run | 22: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 2011 | 22: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 |
| fsmithred | that sounds right | 22:09 |
| fsmithred | to fix the dirty shutdown requires replacing the binaries in the live system? | 22:10 |
| fsmithred | or is it possible to fix both things at once? | 22:10 |
| _abc_ | Fixing the shutdown can be done in the persistence volume | 22:11 |
| fsmithred | yeah, ok | 22:11 |
| fsmithred | I'm just thinking about where to fit these in | 22:11 |
| _abc_ | Apply either my June 2018 shutdown or yesterday's shutdown -n instead of halt in /etc/init.d/halt in the persistence volume | 22:11 |
| fsmithred | oh | 22:12 |
| _abc_ | fsck the fs's from another boot, then boot into it, and it will shut down clean | 22:12 |
| fsmithred | the 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 |
| fsmithred | I would most likely make that optional | 22: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 found | 22:14 |
| fsmithred | sounds good | 22:14 |
| fsmithred | I like feedback from the system | 22: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 |
| fsmithred | been doing it for years | 22: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 |
| fsmithred | there are a few posts about this on debian-live mailing list | 22:15 |
| fsmithred | old posts | 22: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 |
| fsmithred | lol | 22:16 |
| gnarface | this was clearly a hit job | 22:16 |
| fsmithred | I thought it was odd that the wheezy source for sysvinit was missing | 22:17 |
| _abc_ | is it not on archive.debian.org ? | 22:17 |
| fsmithred | I couldn't find any sources at archive.debian.org | 22:17 |
| fsmithred | they're at sources.debian.org | 22:18 |
| fsmithred | just not all of them | 22:18 |
| _abc_ | https://www.debian.org/distrib/archive this is too olf | 22:18 |
| _abc_ | *old | 22:18 |
| fsmithred | all the way back to hamm | 22:18 |
| _abc_ | wheezy (7.x) is too "new" for that | 22:19 |
| fsmithred | https://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 |
| fsmithred | I don't go there | 22:20 |
| fsmithred | never have | 22:20 |
| _abc_ | :) | 22:20 |
| fsmithred | except for a few times, and a few of those times, it was by accident | 22:21 |
| fsmithred | from what I've heard, nobody gets treated well there | 22:21 |
| fsmithred | so I wouldn't feel special if they flamed me | 22: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 |
| fsmithred | did you ask if anyone has the source code? | 22:22 |
| fsmithred | I did install debian today, so I guess I could go there | 22: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 |
| fsmithred | but I didn't install gnome, so maybe not | 22:24 |
| fsmithred | back in 5 | 22:26 |
| _abc_ | https://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian/dists/ fsmithred some wheezy in there | 22: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 7GB | 22:27 |
| _abc_ | 7MB src names only | 22: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 |
| fsmithred | maybe we can get it from Jessie Smith | 22:32 |
| fsmithred | current maintainer for sysvinit | 22:33 |
| fsmithred | golinux, 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 |
| fsmithred | the script in /etc/init.d, yes | 22:34 |
| fsmithred | the binaries, I don't know | 22:34 |
| fsmithred | I compared beowulf to squeeze | 22:34 |
| _abc_ | That I already know. What about /sbin/init version? | 22:35 |
| fsmithred | can check... | 22:35 |
| _abc_ | You're much better at using debian tools and archives than I am. Go for it, please. | 22:35 |
| fsmithred | Binary files /mnt/sdb2/sbin/init and /sbin/init differ | 22:35 |
| _abc_ | Hmm. | 22:36 |
| _abc_ | fsmithred: try size on them? Same arch? x86 not x86 vs x86_64? | 22:36 |
| golinux | fsmithred: www.chiark.greenend.org.uk/pipermail/debian-init-diversity/ | 22:36 |
| fsmithred | thanks | 22:36 |
| _abc_ | -diversity ?! | 22:36 |
| golinux | There is also this list https://lists.debian.org/debian-devel/ | 22:37 |
| fsmithred | _abc_, same arch, different sizes | 22:38 |
| fsmithred | comparing wheezy to jessie now | 22: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/init | 22:38 |
| fsmithred | 36992 Jul 14 2013 /mnt/sdb2/sbin/init | 22: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 |
| fsmithred | 57032 Feb 26 16:59 /sbin/init | 22:39 |
| fsmithred | beowulf | 22:39 |
| _abc_ | That is quite different yes | 22:39 |
| _abc_ | Still same arch? | 22:39 |
| _abc_ | And stripped? | 22:39 |
| fsmithred | yes | 22:39 |
| fsmithred | amd64 | 22:40 |
| fsmithred | stripped? | 22:40 |
| _abc_ | Perhaps beowulf is built with debug flags in it? | 22:40 |
| fsmithred | I take whatever the repo gives me | 22:40 |
| _abc_ | fsmithred: run file on it, it can say stripped or unstripped ELF | 22:40 |
| fsmithred | ascii is 37064 | 22:41 |
| _abc_ | file(1) will tell you if it is stripped or not | 22:41 |
| _abc_ | fyi stripped means any debug symbols and object names not needed for runtime linking were removed from the ELF binary. | 22:41 |
| fsmithred | stripped in wheezy and beowulf | 22:42 |
| _abc_ | debug builds leave them in, that makes the binaries large but debuggable with meaningful output in gdb | 22:42 |
| _abc_ | fsmithred: ok so beowulf had a major change in the source | 22:42 |
| _abc_ | The question is, what. Are they all dynamically linked per file(1) ? | 22:42 |
| fsmithred | yeah, some old bugfixes | 22: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 |
| fsmithred | answer is probably in the init diversity ml archive | 22: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 |
| fsmithred | I have the changelog for wheezy | 22:47 |
| _abc_ | I think the changelog for beowulf will be more interesting at this point. But bring it. Anything interesting in it? | 22:48 |
| fsmithred | I have that, too. Scrolling down to make sure it continues from the older one | 22:48 |
| fsmithred | it does | 22:49 |
| fsmithred | Restore umount at shutdown of filesystems mounted before /usr | 22:50 |
| fsmithred | oh, you want bug numbers? | 22:51 |
| fsmithred | want 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 ones | 22:52 |
| fsmithred | do 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 reasons | 22:53 |
| _abc_ | fsmithred: no | 22: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 versions | 22:53 |
| fsmithred | exact same libraries | 22:53 |
| fsmithred | wheezy/beowulf | 22:54 |
| _abc_ | Interesting. Well, something changed from ascii to beowulf to make the binary twice as big | 22:54 |
| Venker | hi people | 22:54 |
| gnarface | welcome Venker. if you have a question just ask it. | 22:54 |
| gnarface | in some cases you might have to wait a long time for a response | 22:55 |
| fsmithred | ELF 64-bit LSB executable vs ELF 64-bit LSB pie executable | 22:55 |
| _abc_ | I don't know what PIE is | 22:55 |
| fsmithred | neither do I. | 22:56 |
| fsmithred | someone explained it to me once, but that's gone | 22:56 |
| _abc_ | https://unix.stackexchange.com/questions/89211/how-to-test-whether-a-linux-binary-was-compiled-as-position-independent-code | 22: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 options | 22:58 |
| _abc_ | It's a security feature apparently | 22:59 |
| fsmithred | yeah, this sounds familiar | 22:59 |
| fsmithred | I need a nap | 22:59 |
| gnarface | something to do with anti-stack-smashing maybe? | 22:59 |
| fsmithred | ate too much at a brunch | 22:59 |
| _abc_ | ok | 23:00 |
| fsmithred | Position Independent Executables (PIE) receive stronger address space randomization (ASLR) protectio | 23: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 #workingset | 23:00 |
| fsmithred | bbl | 23:01 |
| detha | _abc_: no use of absolute addresses, so the loader can easier shuffle things around | 23:01 |
| _abc_ | well relative address use should result in a smaller binary. At least from what I remember from my sessions. | 23:02 |
| detha | nope, binary now has extra type indicators + address where otherwise it would just have been address | 23: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 |
| detha | not really | 23:05 |
| _abc_ | Potentially, from a trivial analysis at least? | 23:05 |
| detha | position 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 |
| detha | nothing to do with checks, just extra indirect loads | 23:07 |
| _abc_ | Is that not simply offloaded to the silicon using mov ax, [bp+...] | 23:07 |
| detha | that's loading from stack | 23:08 |
| detha | Now also things like globals or static strings like printf formats can be anywhere | 23: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 |
| detha | Yup. 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 run | 23:12 |
| * _abc_ nods | 23: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 significantly | 23: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 |
| detha | http://paste.debian.net/1078726/ | 23:39 |
| _abc_ | is that from beowulf? | 23:39 |
| _abc_ | detha: ^ ? | 23:39 |
| detha | 2.0, whatever it's called | 23: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 apparently | 23:42 |
| _abc_ | My .init uses 36 bytes for example | 23: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 |
| detha | there'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 / entry | 23: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 |
| detha | I have long since given up building own kernels from scratch, have to trust whoever runs the distro | 23: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 |
| detha | I 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 |
| detha | With money, or beatings of the area manager :p | 23: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) -> 1B6 | 23:54 |
| _abc_ | this is ascii default boot settings | 23:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!