rrq | fsmithred: you remember the installer isos have the "magic touch" script as way of dealing with some boot races.. have you tried that on the live isos? | 01:12 |
---|---|---|
fsmithred | no | 01:12 |
fsmithred | where is the script? | 01:12 |
rrq | actual script is hosted at https://git.devuan.org/devuan/devuan-installer-iso/blob/master/scripts/magic-touch | 01:13 |
rrq | it's invocked from somwhere... (testing my memory here) | 01:14 |
rrq | -k +e | 01:14 |
fsmithred | it runs check-missing | 01:15 |
fsmithred | which isn't in the live isos | 01:15 |
rrq | ok | 01:15 |
fsmithred | unless that's a normal startup script | 01:15 |
rrq | right... actully, magic-touch edits that script so that script doesn't remember its previous run; it's a "normal" installer script | 01:18 |
rrq | I don't rememebr the reason, but it's instead of editing the source udeb | 01:19 |
rrq | (if you manage to sort out what "it" refers to in those you are good :)) | 01:21 |
fsmithred | when during boot do modules get loaded? | 01:22 |
rrq | the first is from the initrd's /etc/modules and individualy by its init hook scripts | 01:23 |
rrq | after pivot it'd be kmod I think | 01:25 |
rrq | eg /etc/rcS.d/S09kmod | 01:26 |
rrq | if you neeed them early you'll name them in /etc/initramfs-tools/modules and rebuild initrd | 01:28 |
rrq | that'd then be roughly /usr/share/initramfs-tools/init:226 | 01:30 |
fsmithred | ok, first thing I'm gonna do is boot without 'quiet' | 01:37 |
rrq | what? doesn't seeing all that booting activity scare you? | 01:45 |
fsmithred | I always get rid of quiet. It's the default in Refracta isos. | 01:45 |
fsmithred | I do find it annoying to get kernel messages in the console when I'm trying to log in | 01:46 |
fsmithred | but mostly I just boot to desktop, so it doesn't matter | 01:46 |
fsmithred | ok, where does "Loading essential drivers" get logged? I can't find it. | 01:47 |
rrq | ah.. you might want to start with console=ttyS0 | 01:48 |
rrq | or is this bare-metal? | 01:49 |
fsmithred | bare metal | 01:49 |
fsmithred | from dvd | 01:49 |
rrq | mmm so you should see all the logs then ... | 01:50 |
rrq | first one would be from line 30 "Loading, please wait..." .. if we have the same init | 01:53 |
fsmithred | I'm gonna compare dmesg output between regular boot and boot to ram | 01:57 |
rrq | so what's the difference between those for a live DVD ? | 02:22 |
rrq | in partuclar, what does "regular boot" do if not to ram ? | 02:26 |
rrq | ah.. it's the root FS that's copied to RAM .. so different timings post pivot | 02:34 |
fsmithred | yeah, it copies filesystem.squashfs to ram | 02:45 |
fsmithred | and then anything you run gets read from that ram | 02:45 |
fsmithred | instead of from the dvd | 02:45 |
fsmithred | takes a long time to boot, but then everything is fast | 02:45 |
fsmithred | This is regular boot: | 02:55 |
fsmithred | [ 8.648784] ISO 9660 Extensions: RRIP_1991A | 02:55 |
fsmithred | [ 8.729654] loop: module loaded | 02:55 |
fsmithred | [ 11.232463] squashfs: version 4.0 (2009/01/31) Phillip Lougher | 02:55 |
fsmithred | [ 38.727140] udevd[765]: starting version 3.2.7 | 02:55 |
fsmithred | This is boot to ram. They are the same except for the extra time to load to ram: | 02:56 |
fsmithred | [ 8.704459] ISO 9660 Extensions: RRIP_1991A | 02:56 |
fsmithred | [ 162.978195] loop: module loaded | 02:56 |
fsmithred | [ 163.112485] squashfs: version 4.0 (2009/01/31) Phillip Lougher | 02:56 |
fsmithred | [ 170.000048] udevd[790]: starting version 3.2.7 | 02:56 |
fsmithred | after that point, a whole lot more happens in the boot to ram than in the regular. | 02:56 |
fsmithred | including snd | 02:56 |
rrq | so I guess /dev/loop0 is either to /dev/ram0/fs.squashfs or /dev/sr0/fs.squashfs or something | 03:02 |
fsmithred | this: /dev/loop0 776M 776M 0 100% /run/live/rootfs/filesystem.squashfs | 03:04 |
rrq | right.. and readlink -f of that? | 03:10 |
fsmithred | just gives the same path | 03:17 |
rrq | mmm would be different mount then.. as /run/live probably ? | 03:39 |
golinux | I have just outlined a rough draft for the Beowulf release announcement here: | 08:13 |
golinux | https://pad.dyne.org/code/#/2/code/edit/D+ChmluW+TT9QPdOVO9q0rpf/ | 08:13 |
golinux | There are some content questions and empty spaces that need to be filled. | 08:14 |
golinux | Please post all comments below the =============== They will be included as appropriate after review and discussion. | 08:16 |
LeePen | y | 10:22 |
HumanG33k | do you know if you (devuan) have make change on perl/apt/dpkg stuff ? | 11:48 |
HumanG33k | because when i try to install fusiondirectory from their repository (stretch one no new for now) the connfiguration is stuck on that line | 11:49 |
HumanG33k | : /usr/bin/perl -w /usr/shar^Cdebconf/frontend /var/lib/dpkg/info/fusiondirectory.postinst configure 1.3-1 | 11:49 |
HumanG33k | but the package work | 11:50 |
LeePen | HumanG33k: we forked apt a few weeks ago. | 11:50 |
LeePen | Which suite are you using? | 11:51 |
HumanG33k | Devuan GNU/Linux 3 (beowulf) x86_64 LeePen | 12:00 |
LeePen | No then. Our forked apt is in ceres and chimaera only. | 12:00 |
HumanG33k | You really have to fork apt ? | 12:01 |
HumanG33k | … | 12:01 |
HumanG33k | they use some systemd stuff in in now ? | 12:02 |
LeePen | Yes, it Debian's version depends on libsystemd0 :( | 12:05 |
Unit193 | Which libelogind0 provides, I see. | 12:38 |
LeePen | Unit193: yes. However, we feel the idea is for the packaging system to be as lean as possible. | 12:41 |
Unit193 | LeePen: Sure, I just wondered why it wasn't being pulled back on my unstable system is all. | 12:41 |
LeePen | libelogind0? | 12:42 |
Unit193 | libsystemd0, since of course I have apt. | 12:45 |
amesser | LeePen: Did I do something wrong when triggering the apt build yesterday or was it an issue with the build system? | 14:15 |
HumanG33k | LeePen, i feel like their poll about init system was mainly a communication one … | 14:32 |
LeePen | amesser: it was the build system. | 14:34 |
LeePen | I re-ran the failures. Hope that was OK? | 14:35 |
amesser | sure | 15:39 |
fsmithred | How can I turn off multi-threading during boot? | 22:26 |
fsmithred | "during boot" I mean disabled for boot - I expect I'll have to do something before reboot (or before building the live-iso). | 22:27 |
mason | fsmithred: I'm not sure the best way to hook a script into your initramfs, but I'd look for a place to do it there, and do something vaguely like what they describe at https://serverfault.com/questions/235825/disable-hyperthreading-from-within-linux-no-access-to-bios | 22:31 |
fsmithred | I think there's someplace to remove or change the word, CONCURRENT, but I can't remember where that is. | 22:32 |
mason | fsmithred: Do you mean concurrent service start-up, as opposed to hyperthreading? | 22:33 |
fsmithred | yes | 22:33 |
fsmithred | I want to un-clog my pipes | 22:34 |
mason | fsmithred: So, in /etc/init.d/README at the end there's a pointer to /usr/share/doc/insserv/README.Debian after some verbiage saying "More information on the format is available from insserv(8). This information is used to dynamicaly assign sequence numbers to the boot scripts and to run the scripts in parallel during the boot." | 22:36 |
mason | Nothing immediately obvious there, but I'll find something. | 22:36 |
fsmithred | thanks, I'm reading | 22:37 |
mason | hrm, CONCURRENCY=makefile in /etc/init.d/rc | 22:39 |
mason | fsmithred: So, looks like you'd want to set CONCURRENCY=none in there | 22:39 |
mason | or touch /etc/init.d/.legacy-bootordering from the look of it | 22:39 |
mason | That might be the easiest answer. | 22:39 |
mason | script looks for that, and sets CONCURRENCY="none" if it sees it | 22:40 |
fsmithred | that sounds like the right thing to do | 22:40 |
mason | Note that I haven't tested it, but it sure does sound right. | 22:40 |
fsmithred | I'm gonna test it now | 22:40 |
mason | I'll re-coffee for luck. | 22:43 |
fsmithred | lol | 22:47 |
fsmithred | making the iso now | 22:47 |
fsmithred | then I have to burn | 22:47 |
fsmithred | then I can boot it | 22:47 |
mason | fsmithred: In a spiritually similar move, I ended up having to make a new pot of coffee so there'd be some to pour. | 22:57 |
fsmithred | lol | 22:57 |
mason | I'm also, in parallel news, thinking that I'm slowing things down looking at how to mutate TWiki so it can run in parallel under one browser instance. I'm thinking it might be better just leaving it in default form and running multiple instances through LXC or similar, maybe with nginx instead of Apache to keep it light-weight. TWiki for Devuan certainly won't need the parallel installs that I need for | 23:00 |
mason | my own stuff. | 23:01 |
mason | Plus, any changes I make that deviate from vanilla will just make it harder to upgrade. | 23:02 |
fsmithred | good point | 23:07 |
fsmithred | I like being able to take defaults | 23:07 |
fsmithred | laziness is an admirable quality when applied correctly | 23:08 |
fsmithred | well, that didn't fix it | 23:21 |
mason | Did it definitely run things serially? | 23:22 |
golinux | Devuan uses nginx so best to get used to that. | 23:28 |
mason | Eh, Apache's still far more common. But sure. | 23:30 |
fsmithred | not sure if it really ran things serially | 23:41 |
fsmithred | did not make a difference | 23:41 |
mason | Hrm. :/ | 23:42 |
fsmithred | actually, the first part of booting seemed to go faster | 23:42 |
fsmithred | up to the point of running all the live-config scripts, then it took a long time for the desktop to come up | 23:42 |
fsmithred | but it does that either way - that's just slow DVD | 23:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!