_abc_ | The current idea is to locate where the noeject is used, and force a remount ro there, then a fsck if the former succeeds | 00:00 |
---|---|---|
_abc_ | Sounds good? | 00:01 |
fsmithred | yeah | 00:02 |
fsmithred | make sure it's not a CD | 00:02 |
_abc_ | Well a remount ro will fail succesfully on an already ro mounted media | 00:02 |
fsmithred | I'm gonna reboot the stick and see if it messes up the fat again, now that fsck fixed it. | 00:05 |
_abc_ | See it is ro before that? | 00:05 |
_abc_ | grep -l noeject $(locate bin/live-) -> /bin/live-medium-eject | 00:06 |
_abc_ | fyi | 00:06 |
_abc_ | Right, that file is not in the initrd. | 00:07 |
_abc_ | So I can edit it in the running system once booted, but that is a hen or egg problem. I think I will add a dir of files to copy into the system after squashfs mount, but before pivot root. I did this way back when 10 years ago but I do not remember how. Probably an arch unpacked on top of the mounted but not pivoted syste,m | 00:09 |
_abc_ | reading /bin/live-medium-eject :: they specifically do not umount usb mass storage devices?! HUH? "need coldboot to recover" means what? | 00:13 |
_abc_ | wow, sounds like 640 kB will be enough for everyone. | 00:14 |
fsmithred | you can make a hookscript that will make the changes for you each time you boot | 00:15 |
_abc_ | I can put the /bin/live-medium-eject on the persistence medium manually, now, edited a bit, so it will remount ro && fsck, I think | 00:16 |
fsmithred | use same format as the live-config scripts for the hookscript | 00:16 |
_abc_ | Or,rather, in the morning, since it's 1:15AM here and my error rate is going up a bit. | 00:16 |
_abc_ | fsmithred: hm? Oh, put it in a dir so it gets exec'd? | 00:16 |
fsmithred | well, you use persistence as you just described | 00:17 |
_abc_ | Yes | 00:17 |
fsmithred | no need for the hookscript unless you want it to work when there's no persistence | 00:17 |
_abc_ | Yes. But would a hookscript be stored on the initrd? | 00:17 |
_abc_ | I keep getting back to my 10 year old hack using a packed arch on the inird "dumped" on top of the squashfs+overlay mount before pivoting. | 00:18 |
_abc_ | *initrd | 00:18 |
_abc_ | Looks like I'll revive that some day soon, perhaps Sunday. | 00:18 |
_abc_ | Windows has one thing I like, there's a set of RunOnce scripts or programs it can run once upon reboot/when needed, this could be very useful for linux at some times. Like now. | 00:19 |
_abc_ | Okay, thanks for the help, will go zzz a bit in 5 mins and pick this up tomorrow or in the weekend. | 00:19 |
_abc_ | fsmithred: did you check if the rebooted stick has a fsck fault after reboot? | 00:23 |
fsmithred | yeah, it does | 00:24 |
_abc_ | Note dosfsck reports a fault even if the media was mounted ro after that. | 00:24 |
fsmithred | I also found errors inside my persistent loopfile | 00:24 |
_abc_ | Oh that is not good. | 00:24 |
fsmithred | just said it was not cleanly unmounted | 00:25 |
_abc_ | I once tried to shut down to runlevel s then to umount the media manually, and it would not let me | 00:25 |
_abc_ | That also needs addressing. | 00:25 |
fsmithred | when I mount and unmount it in r2u, it's ok | 00:25 |
_abc_ | mount -f -o remount.ro MUST work | 00:25 |
_abc_ | I gather someone made -f not work sometimes in the kernel, or in libc, I don't remember. | 00:26 |
_abc_ | Was a long time ago but now it haunts me. | 00:26 |
_abc_ | Okay, more things to try out | 00:27 |
_abc_ | Signing off now, going to bed a bit. Thanks and bye. | 00:27 |
tuxd3v | Hello | 00:28 |
tuxd3v | by accident I deleted my .bashrc file | 00:28 |
fsmithred | g'night | 00:28 |
fsmithred | tuxd3v, you can find a copy in /etc/skel | 00:28 |
tuxd3v | well the problem is that I already had lots of my stuff there | 00:29 |
tuxd3v | I still have my session open | 00:29 |
tuxd3v | could it bee since bashrc is sourced | 00:29 |
fsmithred | maybe you have a .bashrc~ | 00:29 |
fsmithred | yes | 00:29 |
fsmithred | did you have a lot of modifications in your .bashrc? | 00:30 |
tuxd3v | I have some | 00:30 |
tuxd3v | the problem, is that right now, I don't remember details :( | 00:30 |
fsmithred | well, unless you have a backup copy, they're gone | 00:30 |
fsmithred | but you probably should use the one in /etc/skel for now | 00:31 |
tuxd3v | I was to delete .bash_history, has I found a security breach in one of my scripts...it echoed my passwd to stdout :S | 00:31 |
tuxd3v | was --> have | 00:32 |
_abc_ | fsmithred: https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html related | 00:32 |
tuxd3v | but I typed ~/.bashrc | 00:32 |
tuxd3v | :S | 00:32 |
tuxd3v | should be there any environment for my session at least that could retrieve some data bask? | 00:33 |
tuxd3v | er, back | 00:33 |
_abc_ | tuxd3v: normally cp /etc/skel/.bashrc ~/ does fix it | 00:34 |
_abc_ | unless you edited it | 00:34 |
_abc_ | tuxd3v: ? | 00:34 |
tuxd3v | yes I had it edited.. | 00:35 |
tuxd3v | compilers toolchains, and a lot of my stuff including personal visualization stuff | 00:35 |
_abc_ | Well, in that case, copy in the above, then patch in your backed up edits. You did back it up, right? :) | 00:35 |
_abc_ | Since you put so much personal stuff in it, instead of sourcing a special file with those settings, like . ~/.my_bashrc_settings | 00:36 |
tuxd3v | I haven't done that.. I setet up a backup system with 12TB, but I am still configuring the remainings part of it.. | 00:36 |
tuxd3v | so not yet doing backups.. | 00:37 |
_abc_ | And err not backing up your $HOME is one of the other things one does not do. | 00:37 |
_abc_ | Looks like starting again from scratch, then. Sorry. | 00:37 |
_abc_ | In theory there are undelete file options but they do not work on modern systems and fs's. | 00:37 |
tuxd3v | humm | 00:38 |
tuxd3v | when you source a file...does it remains with a file descriptor open to .basjrc? | 00:38 |
tuxd3v | bashrc? | 00:38 |
tuxd3v | I still have my session open | 00:38 |
_abc_ | No. And bash unfortunately reads and then closes it. | 00:39 |
_abc_ | So no running bash instance holds an open file desc on bashrc | 00:39 |
Hurgotron | the running bash process might have copied to its memory somewhere, though. | 00:40 |
tuxd3v | that is a way to save what you have deleted has the file descriptors on that inode would then not be equal to zero, and so, the space would be retrievable | 00:41 |
_abc_ | Hurgotron: it does not do that it interprets the file's contents | 00:41 |
_abc_ | It MAY have survived in kernel buffers though | 00:42 |
_abc_ | tuxd3v: you can try to open /dev/kmem with something binary reading capable and search for a string you remember from bashrc | 00:42 |
_abc_ | This will be messy and you will likely need to find all the pages if it was larger than 4k | 00:42 |
_abc_ | Messy because x86 is little endian and you do a binary search on unaligned strings | 00:43 |
_abc_ | err eww. Looks like systemd interferes even with initrd. I see red warning lights. Something may be broken at script or kernel level there. https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ | 00:45 |
tuxd3v | well fsmithred, thanks, that will be the last resource, both bash proceses that I have none has file descriptors open to ~/.bashrc, I checked with 'lsof -nP -p processid' | 00:46 |
_abc_ | I just told you they do not | 00:47 |
_abc_ | tuxd3v: I am serious, open /dev/kmem and look for strings | 00:47 |
_abc_ | https://www.google.com/search?q=finding+strings+in+%2Fdev%2Fkmem >> tuxd3v | 00:48 |
Hurgotron | _abc_: good idea. | 00:48 |
_abc_ | It's a nasty hack. Strings are not always stored in byte order in kmem | 00:50 |
_abc_ | wchar_t etc | 00:50 |
Hurgotron | BTW - I'd *immediately* power down a system where I deleted something without backup. As in, yanking the power cord within seconds. Then image the disk and deploy forensic tools. | 00:50 |
_abc_ | O.o | 00:50 |
_abc_ | Core dump is a better idea. | 00:50 |
_abc_ | Using SysRq | 00:50 |
_abc_ | This will still not help much but power down is a really bad idea | 00:51 |
_abc_ | You can also halt the system from SysRq and you can shut down without committing buffers etc from root cli | 00:51 |
_abc_ | Going to run level s and then umounting all volumes remounted ro is another way. | 00:52 |
Hurgotron | anything which prevents the system from writing to the sector with your data. Never wrecked a system losing power accidentally, so I'd take the risk. | 00:52 |
_abc_ | Uhh I don't know what you see as systems, but to not pull the power on any modern boxes. Especially not industrial ones. Juniper you pull power twice in a row without waiting for it to boot and self fsck you reinstall. If it's pre 10.x junos it takes one try. | 00:53 |
stiltr | You can try a set | less and see if what you need is in there. | 00:54 |
_abc_ | stiltr: why would it be in a var? The content of bashrc? | 00:54 |
Hurgotron | _abc_: Well desktop systems obviously. I don't usually work in the vicinity of a server so I'd have to opportunity to unplug it directly :) | 00:55 |
_abc_ | Also grepping /dev/mem is urgent since all movements consume (reuse) buffer space. Whatever is in the buffer space will be overwritten eventually. | 00:55 |
_abc_ | Hurgotron: unplugging a server is usually not possible without a screwdriver. | 00:55 |
_abc_ | :) | 00:55 |
stiltr | _abc_: Depends on what he's had in there. If it's just how his PS1 is set, it's there. Something else, maybe not. | 00:55 |
stiltr | A memdump to file would preserve what's there for inspection later. | 00:56 |
_abc_ | A memdump to file on mounted external volume perhaps, with mount options set to NO BUFFERING. I do not remember those by heart. | 00:57 |
_abc_ | Causing a core dump and then interpreting that is the "clean" bad old way to do it. | 00:57 |
stiltr | Ya, I don't know what they are either. | 00:57 |
Hurgotron | _abc_: Depends on the server. the 1-4 U units at work would be easy enough to unplug if you have physical access. | 00:58 |
_abc_ | The screws ensure you do not have physical access. Like cleaners, etc. | 00:58 |
stiltr | I think I did something similar a long time ago trying to get back a file I deleted...eventually gave up. haha | 00:59 |
stiltr | ^^^memdump, not pulling the plug | 00:59 |
Hurgotron | _abc_: well, cages. Which are usually open when I'm working on that stuff. | 01:00 |
Hurgotron | stiltr: pulling the plug once worked for me. Actually I was fast enough that the file was not even erased :) buffers not written. It's been a long time ago though. | 01:01 |
stiltr | I'm sure it's doable. I've just not tried it. = ) | 01:02 |
stiltr | tuxd3v: What sort of stuff was in your .bashrc file that you're wanting back? | 01:03 |
_abc_ | He said env paths for compiler suites and something about visualization | 01:04 |
stiltr | Oh, you're right. Forgot he'd said that. Thanks! | 01:05 |
tuxd3v | sorry for the late, I was checking in a disk for something.. I don't have /dev/kmem in this machine | 01:41 |
tuxd3v | :( | 01:41 |
tuxd3v | Iam in the process of migrating my all disks to iscsi | 01:42 |
tuxd3v | tons of disks around and uncategorized information.. | 01:42 |
tuxd3v | its not usefull at the moment.. | 01:42 |
tuxd3v | need to be put in palce..in 1 year it will be ok.. | 01:43 |
tuxd3v | I had compiler suites, cross compiler suites, console congigs, colors, and so on.. | 01:43 |
tuxd3v | er, configs | 01:44 |
tuxd3v | lua environments for diferent situations also.. which is a pain in the ass to get again.. | 01:44 |
tuxd3v | Any one of you have already worked with amanda backups? | 01:45 |
tuxd3v | first of all, sory, I am late.. | 01:45 |
tuxd3v | Thanks for your help on this! :) | 01:46 |
Hurgotron | the next best thing to backups is to deploy simple versioning to your scripts, ie. cp -a script.sh script.sh-<timestamp> | 01:46 |
Hurgotron | Doesn't help you now, but most of us had to learn from data loss. | 01:46 |
Hurgotron | I'm mirroring my stuff to mobile disks or external servers with rsync and hardlink "deduplication" (--link-dest) | 01:48 |
tuxd3v | yeah that is another solution.. | 01:49 |
tuxd3v | just need to find the correct setup | 01:49 |
tuxd3v | then will come the rules to aplly at each machine. | 01:49 |
Hurgotron | That way I have versioned full backups without them taking up much more space than a single full backup plus incrementals. | 01:49 |
stiltr | Were you using aliases or exporting variables or something totally different? | 01:49 |
tuxd3v | at least exporting them I should be | 01:50 |
tuxd3v | a printenv doesn't find much | 01:50 |
stiltr | try set | less | 01:51 |
stiltr | I'm able to find function and whatnot from my .bashrc | 01:51 |
stiltr | aliases will also print current aliases | 01:51 |
stiltr | (I could see the function with set, but not printenv) | 01:52 |
stiltr | Though, it may be worth mentioning that isn't on a devuan box. | 01:53 |
tuxd3v | I rememebr know that I had functions to save history in another shells to .bash_history also | 01:55 |
gnarface | i could be wrong but i thought that was a built-in feature now that's just not on by default | 01:56 |
gnarface | i don't think you need to load extra functions for it | 01:56 |
gnarface | anymore, anyway | 01:56 |
tuxd3v | gnarface, yes its a builtin but I needed to set functions, to control the way it behaves | 01:57 |
gnarface | ah | 01:57 |
tuxd3v | I just don't recall why | 01:57 |
gnarface | hmm | 01:58 |
tuxd3v | :S | 01:58 |
gnarface | i got nothing, sorry | 01:58 |
tuxd3v | be dafault history is only appended in .bash_history when you logout session | 01:59 |
tuxd3v | er, default | 01:59 |
tuxd3v | Well, for know I followed fsmithred, advice and just 'cat' from 'skel' path to my home | 02:00 |
tuxd3v | I will let this shell open, just in case I remember something.. | 02:00 |
tuxd3v | :) | 02:00 |
stiltr | tuxd3v: Not to beat a dead horse, but was there anything interesting in set? I'm mostly curious if it's doing something different on my box than yours. | 02:17 |
tuxd3v | it depends on what you want, your configs and such.. | 02:22 |
tuxd3v | for example I now remember that I had a HISTSIZE=60000 | 02:22 |
tuxd3v | by default you only have 2000 lines | 02:23 |
tuxd3v | one simple sulution woulçd be to set a git server in my NAS server, and commit every half-day or so | 02:25 |
tuxd3v | er, would | 02:25 |
stiltr | I'm not sure I follow. What I'm saying is that everything I have in my .bashrc can be found in the output of set. | 02:26 |
stiltr | Sure, a git repo for configs isn't an uncommon solution. | 02:26 |
tuxd3v | I will save set output, since its big, and then will diff it with the one in new session.. | 02:31 |
tuxd3v | <stiltr>, nice hint | 02:32 |
tuxd3v | :) | 02:32 |
stiltr | Hope it help! | 02:35 |
Hurgotron | stiltr: good hint. Why didn't I think of it... I should go to bed, I guess. | 02:36 |
stiltr | Thanks! = ) | 02:37 |
tuxd3v | Thanks to fsmithred, _abc_, Hurgotron, stiltr, gnarface for the help on this.. great community! thanks again! | 02:44 |
gnarface | i didn't help much but you're welcome | 02:44 |
stiltr | : ) | 02:46 |
tuxd3v | everyone of you helped a lot, I already recovered some things | 02:47 |
tuxd3v | the rest will be 'like the first time' | 02:47 |
tuxd3v | lessons learned..whats the first thing to configure? right backups.. | 02:47 |
tuxd3v | :) | 02:47 |
gnarface | haha yep | 02:48 |
* stiltr feels the need to start a backup immediately | 02:54 | |
* fsmithred is staring at the empty 2T external hard drive on the desk | 02:55 | |
* stiltr wonders if fsmithred is looking over his shoulder | 03:05 | |
fsmithred | I'm figuring out how to create a torrent | 03:06 |
stiltr | Cool | 03:07 |
fsmithred | ok, I made the torrent file, now what? | 03:09 |
stiltr | Presumably, upload it to a tracker. | 03:10 |
buZz | get all yr buddy to download and seed it | 03:15 |
buZz | buddies* | 03:15 |
fsmithred | phone... | 03:17 |
fsmithred | I can just send them the torrent file? | 03:19 |
buZz | yes | 03:22 |
buZz | just the .torrent is fine | 03:22 |
buZz | you could also send them the full file, so they can start seeding directly, but there's no need specifically | 03:22 |
stiltr | I've only used a tracker, but I believe with DHT, the .torrent file will be enough. | 03:22 |
fsmithred | it's 3.2GB | 03:22 |
fsmithred | and it's already on a server | 03:22 |
buZz | with DHT, you can even just give the infohash :P | 03:23 |
buZz | and it'll figure everything else out | 03:23 |
buZz | its pretty cool | 03:23 |
stiltr | Oh, nice! | 03:23 |
fsmithred | would somebody like to test a torrent file and tell me if it works? | 04:34 |
va7lnx | what kind of torrent file? | 04:39 |
fsmithred | it's for a usb-hdd image | 04:40 |
va7lnx | ah. you just want to see if I can download it? | 04:40 |
fsmithred | multi-boot all the devuan live isos | 04:40 |
va7lnx | or actually run it? | 04:40 |
fsmithred | yeah | 04:40 |
fsmithred | no | 04:40 |
va7lnx | okay | 04:40 |
fsmithred | just download | 04:40 |
fsmithred | I'll pm you a temporary link to it | 04:40 |
va7lnx | kk | 04:40 |
fsmithred | thanks | 04:41 |
average | fsmithred: you can test it yourself.. | 05:25 |
average | but anyways .. | 05:25 |
fsmithred | it's working | 05:25 |
fsmithred | https://get.refracta.org/files/dev1usb/dev1usb.torrent | 05:25 |
average | gr8 | 05:25 |
fsmithred | I don't understand why I'm not seeding | 05:26 |
fsmithred | if I pause and resume, I get a connection for a few seconds, and then it disappears | 05:26 |
fsmithred | oh, three now | 05:27 |
fsmithred | ok, I'm seeding one now | 05:27 |
tuxd3v | fsmithred, it his working nice for me | 05:41 |
tuxd3v | :) | 05:41 |
gour | morning | 06:55 |
gour | i just submitted bug report using 'reportbug' and mailing it via my mailer (claws), but similarly to the last time, i do not see report, although i've found same problem - pulseaudio not starting (with the same solution) in the tracker, so just wondering what is going on with devuan's bug tracker? | 06:58 |
furrywolf | I couldn't get reportbug to report a bug to debian due to mailer issues. reportbug seems... buggy. | 06:58 |
gour | :-) | 07:01 |
gour | well, i just wonder how people report bug to devuan then? my report was sent to Devuan Bug Tracking System <submit@bugs.devuan.org> | 07:02 |
gour | otoh the original report for the same problem which encountered was submitted on Dec 29th, fix was posted on Jan 29th, but still not applied :-( | 07:16 |
gour | https://bugs.devuan.org//cgi/bugreport.cgi?bug=276 | 07:16 |
golinux | Use email directly to report bugs to bugs.devuan.org | 07:21 |
golinux | There are instructions on the site. Don't use reportbug | 07:21 |
gour | golinux: i used reportbug just to compile report, it was sent to the correct address containing required fields in the body etc., but can't find it | 08:05 |
gour | ahh, now i see it | 08:17 |
Evilham | gour: it does take a bit to show up | 11:23 |
gour | Evilham: ok, got it ;) | 11:33 |
_abc_ | Hi. fsmithred ? I did some work on the unclean shutdown issue. Still working on wheezy but it's the same generation as ascii in the scripts. I have a solution. Are you here? | 22:55 |
_abc_ | fsmithred: I will go soon, if you read this: edit the /etc/init.d/halt in your persistence volume to use this final action instead of poweroff or whatever: shutdown -h -n now ;; this does the crucial umount of all volumes even if it is a forced one. The outcome is, both the sdb1 and sdb2 respectively vfat and ext2 made with r2u are found to be cleanly umounted after reboot. | 23:06 |
_abc_ | fsmithred: the next step is to add fsck to the persistence mount phase at boot time, in the initrd. | 23:06 |
_abc_ | I will do that on Sunday. | 23:06 |
_abc_ | fsmithred: it is not clear if the cretins from the systemd camp are responsible for this failure too, apparently halt relies on things which happen in the background to umount the disks, does not do that itself, as shutdown does. | 23:07 |
_abc_ | The way I remember it, it used to halt and poweroff cleanly in slackware days, including from live media. This was in the early 2000s | 23:08 |
_abc_ | </end of communication> | 23:08 |
fsmithred | _abc_, I tested the script you sent me awhile ago, and it seems to be working | 23:10 |
_abc_ | good | 23:11 |
_abc_ | See above about unclean umounts on live fs's. | 23:11 |
fsmithred | I'm getting clean shutdowns on reboot and halt | 23:12 |
fsmithred | testing in beowulf | 23:12 |
_abc_ | Maybe something changed. I don't know. I have to do this to get ascii to shutdown clean after live+persistence session: in /etc/init.d/halt: | 23:13 |
_abc_ | # new halt action, use shutdown instead of halt, does proper umount | 23:13 |
_abc_ | log_action_msg "Will now halt (1)" | 23:13 |
_abc_ | if [ "$poweroff" = "-p" ]; then | 23:13 |
_abc_ | shutdown -h -n now | 23:13 |
_abc_ | else | 23:13 |
_abc_ | shutdown -r -n now | 23:13 |
_abc_ | fi | 23:13 |
_abc_ | # *** Should never reach this: halt" | 23:13 |
_abc_ | log_action_msg "Will now halt (2)" | 23:14 |
_abc_ | sleep 5 | 23:14 |
_abc_ | halt -d -f $netdown $poweroff $hddown | 23:14 |
_abc_ | Sorry oops. | 23:14 |
_abc_ | That was supposed to be a pastebin link. | 23:14 |
fsmithred | you got lucky | 23:14 |
_abc_ | Would be interesting to know if there is a change in the /sbin/halt source from ascii to beowulf | 23:14 |
fsmithred | you're still here | 23:14 |
_abc_ | Hm? | 23:14 |
fsmithred | multiple lines can get you auto-bounced | 23:14 |
_abc_ | Harsh. | 23:15 |
fsmithred | oh, not as harsh as the alternative | 23:15 |
fsmithred | spammers were pretty bad for awhile | 23:15 |
_abc_ | kickban! Undernet style. By continent prefix :) I know, I remember those times. | 23:15 |
fsmithred | I think I still have a wheezy here | 23:15 |
fsmithred | so I can check /sbin/halt on wheezy, jessie, ascii and beowulf | 23:16 |
fsmithred | will you be around later today/tonight? | 23:16 |
_abc_ | I am tinkering with wheezy because the nice people at linuxcnc.org released their live edition on wheezy live. That's what I then wedged into a stick with r2u alongside devuan ascii and other things. | 23:16 |
_abc_ | I'll be around, just remember my TZ is like 10 hours ahead of you. I need to sleep now and then :) | 23:16 |
fsmithred | 10?? | 23:17 |
_abc_ | It's 00:18 hours here. | 23:17 |
_abc_ | Maybe 8 | 23:17 |
fsmithred | after 5pm here now | 23:17 |
koollman | need to sleep ? what's that? ;) | 23:17 |
_abc_ | Oi, I got to be over 50yo and my brains still work. It's worth taking care of it after all this :) | 23:17 |
fsmithred | If you go get 5-6 hours of sleep, I can greet you at your morning coffee | 23:17 |
_abc_ | It's more like 8 I need, and weekend, but I'll work on something else tomorrow in "my" daytime. | 23:18 |
_abc_ | fsmithred: what do you plan to do? | 23:18 |
koollman | damn. I don't think my brains will still work when I'm 50yo | 23:18 |
fsmithred | compare four versions of /sbin/halt | 23:19 |
_abc_ | fsmithred: ok, what package is it in? I'm looking at the one in ascii, don't know the version on the one in wheezy. | 23:19 |
fsmithred | koollman, take good care of your brain - the rest is no good without it | 23:19 |
_abc_ | Looking a bit for debian versions online. | 23:19 |
fsmithred | checking apt-file | 23:20 |
fsmithred | syvinit-core | 23:20 |
fsmithred | also in systemd-sysv, but we don't have that | 23:20 |
_abc_ | I told you I suspect something is amiss related to systemd having their own halt/poweroff now | 23:21 |
_abc_ | They probably ripped something out of the normal halt on the way, and it no longer umounts. | 23:21 |
fsmithred | they really should just fork off of gnu/linux and call it something else | 23:22 |
_abc_ | ack | 23:22 |
fsmithred | better yet, they should get over the whole concept of brand identity | 23:23 |
_abc_ | wheezy scrolled out of the package system, but wheezy is systemd free (or was) since old. | 23:23 |
_abc_ | I wonder what the hell is going on for real. | 23:23 |
fsmithred | redhat increases complexity to get more service contracts | 23:24 |
_abc_ | how does one list the package version, as installed | 23:24 |
fsmithred | dpkg -l <package> | 23:24 |
koollman | dpkg -l ? | 23:24 |
fsmithred | or pipe it to grep <pattern> | 23:24 |
fsmithred | I like the display better that way | 23:25 |
_abc_ | fsmithred: I read some pieces about how people are allowed to write free software while employed, ip laws, and such. I do not like what I came up with. Will write it up as a 2 page essay some day soon. | 23:25 |
_abc_ | ascii running here has sysvinit-core 2.88dsf-59.9 i386 | 23:25 |
_abc_ | what do you have on beowulf? | 23:25 |
fsmithred | 2.93-8+devuan1 | 23:26 |
_abc_ | fsmithred: can you look in your beowulf, the end of the relevant function in /etc/init.d/halt at the halt call, does it resemble what I pasted above? | 23:26 |
fsmithred | 2.88dsf-59.9+devuan2 in ascii | 23:27 |
_abc_ | As I said | 23:27 |
fsmithred | hang on, I'm going to diff all the versions | 23:27 |
_abc_ | the script, halt, does it resemble exactly what I pasted at "halt" above? | 23:28 |
fsmithred | I will check | 23:28 |
_abc_ | halt -d -f $netdown $poweroff $hddown ? | 23:28 |
fsmithred | no, it looks like this: @^@<C4>^B^@^@^@^ | 23:30 |
_abc_ | ?? | 23:30 |
fsmithred | where is the script? if it's /sbin/halt, it's not a script | 23:31 |
_abc_ | You're looking at a binary? Kidding? :) | 23:31 |
_abc_ | fsmithred: /etc/init.d/halt | 23:31 |
fsmithred | oh | 23:31 |
_abc_ | near: | 23:32 |
_abc_ | log_action_msg "Will now halt" | 23:32 |
_abc_ | halt -d -f $netdown $poweroff $hddown | 23:32 |
_abc_ | ^^ that's from ascii and is identical with wheezy's | 23:32 |
fsmithred | yes, same | 23:32 |
_abc_ | So there has got to be a change in the binary or in something else which runs upstream of this | 23:33 |
_abc_ | With live and persistence, the persistence volume is remounted ro in /lib/live/boot-init.sh | 23:33 |
_abc_ | which is called from /etc/rc0.d/K11live via /etc/init.d/live | 23:33 |
_abc_ | This works in wheezy and in ascii, no questions asked. | 23:34 |
_abc_ | iow the media and the persistence volumes are mounted ro by the time init.d/halt runs | 23:34 |
_abc_ | Yet they end up unclean with ascii and wheezy, and you say clean on beowulf? | 23:34 |
fsmithred | only with your script | 23:35 |
_abc_ | Remind me which one please? I've pasted several these days. | 23:35 |
fsmithred | better_live_shutdown | 23:35 |
fsmithred | June 13 | 23:36 |
_abc_ | oh that one | 23:36 |
_abc_ | Hmm I really don't remember that one. | 23:37 |
_abc_ | And can't see it in that form on the disk. Can you paste it or a link? | 23:37 |
_abc_ | I retract the part about the brains still working... | 23:38 |
fsmithred | one minute | 23:38 |
fsmithred | https://termbin.com/1rrs | 23:39 |
gnarface | _abc_: i think your observations matched mine. intermittent failure to wait long enough for proper umounting... started in jessie or later iirc. someone in #debian told me it was not directly related to systemd compatibility, but rather just related to their developers getting impatient and not giving a shit about unclean shutdowns (because they were developing entirely on disposable VMs) | 23:40 |
_abc_ | gnarface: I feel vindicated | 23:41 |
_abc_ | fsmithred: I got the link, looking | 23:41 |
fsmithred | wow | 23:41 |
fsmithred | I can believe it. Too bad. | 23:41 |
_abc_ | Need to search a backup volume I changed systems since then fsmithred. Takes a while. | 23:41 |
fsmithred | goes along with the sentiment that we're all using solid-state drives | 23:42 |
koollman | that's ... sad | 23:42 |
_abc_ | Well I am still on spinning rust. Which is actually Cobalt-Nickel but spinning rust sounds great. | 23:42 |
gnarface | what i've been doing is just running this before i reboot: sync && sync && sync | 23:42 |
koollman | maybe I will have to do multiple checks for shutdowns/poweroffs on my backup servers. They cannot stop quickly | 23:43 |
Evilham | On that note, climbingturtle reminded me of that LVM + LUKS bug where shutting down / rebooting takes forever | 23:43 |
_abc_ | gnarface: old init scripts used to do something like sync; sleep 5; sync; sleep 3; sync; | 23:43 |
fsmithred | yeah, that's a pain | 23:43 |
_abc_ | gnarface: with killall -9 in between | 23:43 |
Evilham | I think I have a patch somewhere that has tobe tested | 23:43 |
fsmithred | Evilham, there are patches for that, but I guess you'll lose it on upgrade | 23:43 |
fsmithred | actually, there are two changes to be made | 23:44 |
Evilham | Yup | 23:44 |
fsmithred | one for shutting down lvm and one for shutting down an encrypted volume | 23:44 |
_abc_ | There should be a new repo in devuan "patches against systemd collateral breakage" | 23:44 |
_abc_ | as .debs | 23:44 |
fsmithred | we sorta started something like that | 23:44 |
fsmithred | devuan-sanity package | 23:44 |
_abc_ | Something like that. | 23:44 |
gnarface | i can think of another fix to go in it | 23:44 |
Evilham | Anyway, \o nighty | 23:44 |
fsmithred | g'night | 23:44 |
_abc_ | bye | 23:44 |
fsmithred | what's the third fix? | 23:45 |
gnarface | oh, well i discovered this unclean shutdown problem coincidentally with another "improvement" (regression) in the /sbin/fsck.reiserfs script, which should simply be deleted and replaced with the symlink to /sbin/reiserfsck that was previously there | 23:46 |
gnarface | i've mentioned it before | 23:46 |
fsmithred | the kids wrote a "better" script? | 23:46 |
gnarface | without testing the existing functionality, they wrote a script to "properly handle -y, which systemd passes by default to all scripts" | 23:47 |
gnarface | which unfortunately the script doesn't actually do | 23:47 |
gnarface | and the binary already did | 23:47 |
gnarface | so it's obvious sabotage | 23:47 |
fsmithred | I need some food. Back in a few minutes. | 23:47 |
gnarface | but if you bring it up you get accused of murdering han's wife | 23:47 |
fsmithred | sabotage or ignorance | 23:47 |
gnarface | hans's | 23:47 |
fsmithred | deliberate ignorance | 23:47 |
fsmithred | oy | 23:48 |
fsmithred | really, don't talk about anything not nice | 23:48 |
fsmithred | brb | 23:48 |
gnarface | reiserfsck will simply ignore "-y" and always has, because that its it's default behavior. the wrapper script they replaced it with simply chokes and fails, despite the claim that it was put there because reiserfsck wouldn't handle "-y" correctly (at best an untested and harmful assumption) | 23:49 |
gnarface | the two of those bugs combined will hose your filesystem on reboot if you were unlucky enough to be using reiserfs, whether you were smart enough to avoid installing systemd or not | 23:50 |
_abc_ | fsmithred: re-reading the notes and the script, the script achieves the same goal as today's edit in /etc/init.d/halt roughly | 23:51 |
_abc_ | gnarface: oh I did not know fsck.reiser ignores -y | 23:51 |
_abc_ | I still have reiser somewhere. | 23:51 |
gnarface | _abc_: it's *supposed* to ignore -y but what it actually does is error out | 23:51 |
gnarface | _abc_: reiserfsck however does ignore -y, which if they'd tested that, they'd have realized they didn't need to write a wrapper script at all | 23:52 |
gnarface | (i hold onto my suspicion that they *did* test it and pushed the change forward on purpose anyway) | 23:52 |
gnarface | anyway it's an easy thing to fix but it falls into the category of "debian upstream will definitely persistently continue to overwrite this fix with their vandalized wrapper script" | 23:55 |
gnarface | they did some similar garbage to xfs but in that case there's a semi-legitimate excuse | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!