« first day (246 days earlier)      last day (2200 days later) » 

12:00 AM
so, I booted into Busybox by this method, remounted rw, and changed the configuration with 2 sed commands (perhaps I could have run a text editor?)
 
Does it... have the boot-option modifications?
 
to this
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="initcall_debug no_console_suspend intel_idle.max_cstate=1"
GRUB_CMDLINE_LINUX=""
 
I mean does the new GRUB menu have the manual bit about busybox.
@Zanna Why wouldn't you have been able to run an editor?
 
no reason, only I vaguely assumed it wouldn't word
 
@Zanna Thanks. I'm pretty sure I had misunderstood you. I think reboot -f is just working like reboot -f usually works and forcing an actual reboot. I've re-edited (rev. 4).
 
12:03 AM
but Busybox has a builtin sed :)
 
@Zanna I would strongly expect it to work.
@Zanna It also has builtin vi, though that's pretty bare-bones.
 
then I ran usr/sbin/update-grub and it worked, and I did sync and remounted ro and reboot -f and sure enough the system just went down and booted without showing me the GRUB menu (but by now I can see you have gathered this)
@EliahKagan I've had to use that before
anyway, to edit 2 characters I can definitely use sed
 
Does halt builtin in BusyBox halt the system if you run:
halt -f
?
 
@EliahKagan looks good! this is a very useful answer
 
Yes, many of your answers are. :)
 
12:10 AM
hahaha :)
@EliahKagan yes, but it does not shut down or reboot. I had to abuse the power button again
I also found that I could run /bin/nano in there
 
Oh.
That's normal for halt. (Unless you mean it looked like it was in the middle of something, and stuff was still running.)
I should've asked you to try:
poweroff -f
 
I'll try it tomorrow (or rather, later today) haha
 
Ok.
You don't actually have to try it -- I'm reasonably sure that I was mistaken about what was going on and that reboot -f really is rebooting.
 
thank you for indulging my enthusiasm to test this method :D
 
Another thing to possibly try, later, if you want, is to hold down whatever key gives you your firmware (UEFI) menu when you reboot with reboot -f from busybox.
@Zanna You are most welcome. :)
 
12:13 AM
@EliahKagan oh ok!
going to sleep
 
Good night!
 
:)
 
(I'll move messages, probably later tonight. The link from the answer will continue to work--I'll make sure not to forget to remove the specific message it happens to link to. :)
 
 
2 hours later…
2:13 AM
458 messages moved from Raiders of the Lost Downboat
 
 
6 hours later…
8:10 AM
@EliahKagan sorry for not answering properly at the time
I realise it's kind of redundant now, but I'm going to try to clarify anyway what happened in case it's in any way useful (in future perhaps)
after checking that trying to sudo mv libc back to its rightful path failed with "yeah sorry buster, you need libc for that :P" (or something like that), I ran the command reboot, which produced the same error about missing libc
I had already closed all the other windows (no issues) so I closed the emulator too and clicked the shutdown menu button in the corner and then clicked on restart
if I had booted this kernel with parameters quiet and splash, like most Ubuntu-er probably have, I doubt I would have seen anything but the splash screen after that
but my cmdline had this instead initcall_debug no_console_suspend intel_idle.max_cstate=1
initcall_debug and no_console_suspend make the boot and shutdown procedures more verbose afaik; they cause more messages to get printed than otherwise would
(I don't have any interest in the system looking tidy while shutting down or booting - I would much rather see what's happening every time, so I can spot variations and anomalies if nothing else, but I set those parameters originally to debug hibernation)
so after I clicked restart, the screen when black, the shutdown messages started scrolling too fast to read, but with a few red [FAILED] lines, specifically I saw some about being unable to unmount /run/user/1000 and similar, stuff to do with my user. Finally it said Reached target Shutdown, and nothing else happened. When a stop job is running or something like that, during a badly configured hibernation attempt, I have waited for several minutes...
while something proceeded and indicated its progress and finally ended and the system managed to go down
in this case there was nothing like that so I assumed it was completely stuck and abused the power button
@Zanna the screen went black
should the question be edited? it would be somewhat more difficult to fix if libc were actually missing (deleted) rather than slightly mv'd I think...
presumably you would need to chroot to run APT, and would it actually work...?
@EliahKagan I have a 32-bit one too since that question about petrify... I might have to expand my answer to that question to make use of this hint from OP about extending its functionality, but I don't even know what it does :/
 
9:01 AM
@EliahKagan it's always the same GRUB menu, and I can always select Advanced Options for Ubuntu and press e to edit the boot parameters for the kernel before booting it
@Zanna I wonder why using the real path worked, while using the symlink did not work
 
 
2 hours later…
10:48 AM
@Zanna ... and since I always have those parameters and never quiet splash and so always see my shutdown process, I know that I never usually have any [FAILED] lines
 
 
1 hour later…
11:57 AM
sigh I am very anti snap. Maybe I need educating. Because I think snap is nice for devs and bad for users
 
12:36 PM
@Zanna agreed, i dislike snaps for the amount of trash they produce
sure we have meanwhile gigantic harddrives but do we nees to have many libraries multiple times on the system just because every snap insttalls their own version?
 
I don't have a gigantic hard drive... after I've compiled a few random things, I start getting very tight on space
 
well in comparison to the times i started computing they are gigantic lol
my first HDD has a grand total of 100 MB
 
haha yeah true
the RAM we have now dwarfs the storage we had way back when
 
1 MB RAM was much
and you had to have special drivers for everything what was above the systems own 512 KB
games did fit on a single floppy disk
hell the complete computer mainframe of nasa had a wopping 8 KB ram/rom total and it brought us to the moon
 
hahaha
 
12:43 PM
if you imagine, if you simply compile a hello world program nowadays it is mostly over 1 KB big
not sure about the actual sice
on windows it was even 2048 bytes min
we produce really alot of overhead nowadays because we have the space
 
Mar 26 at 13:37, by Eliah Kagan
This is not really about speed. Not usually. To word it in an overbearing and sort of silly but accurate way: it's about the total computational resources of humanity. We have lots of fast computers. If we write code that does a lot of processing, we're still not likely to run out of them. The cloud is huge and growing. But the electrical power used by those computers still has to come from somewhere.
 
true that
 
 
1 hour later…
1:53 PM
What's the space overhead of snaps? Don't they deduplicate shared dependencies? I'm not sure I understand why the use of snaps would cause excess space... especially considering that Ubuntu Core, which has as one of its purposes to run on small devices with limited resources, is snap-based. Also, do they involve more processing?
@Zanna I wonder if it had actually shut down pretty well. Should I not be suggesting REISUB as the safest way to reboot a system that can't run any dynamically linked programs? Should I edit my answer?
@Zanna Maybe, but I'd personally prefer it just have another answer about how to deal with that. You could download the appropriate .deb packgage for libc6 and attempt to install it with the dpkg builtin that busybox has. You could do that while chrooted from a live cd or while booted with only busybox available. I don't know if it would rely on anything else. It would be super interesting to find out!
Or you could just copy the file from the live environment directly, assuming it's the same file, or extract the file manually with ar from the appropriate .deb file from the live environment, or use busybox ar.
@Videonauth Sorry, I meant to @-reply to that post on that message.
 
compare for example the install size of vlc snap to the one from repository
it is huge, after i saw that i stick to the repositories instead of snaps
 
Right, but that's because you don't happen to have other snaps that share the same dependencies, isn't it? I mean, suppose you just had snaps for everything. Would it take more space?
 
and to be honest i only once in two years where cought in a dependency loop, which i was able to solve realytively quickly
 
The vlc snap has stuff that you also have separately from any snap. But the duplication is across what different package managers provide, isn't it?
 
@EliahKagan never treid snaps again after that
 
2:06 PM
So this is why I am not sure if snaps actually take up excess space, or if the excess space is instead the result of using two package managers that won't use each other to satisfy package dependencies.
 
in fact i even have a cron job for @reboot which does systemctl disable snapd.service
in case an update enables it again
 
Is snapd not uninstallable?
 
not without really screwing things up
 
I'd hope you could just get rid of the snap package manager altogether if you don't want it and nothing on your system uses it.
 
its a dependency for many meta packages
 
2:07 PM
Hmm...
 
so i simply disable it
but not uninstalling it
 
Yeah, I'm still on 16.04. Nothing depends on it for me.
 
since 17.10 they focus on pushing on snap
 
Is that one of the reasons you've switched some of your systems to Arch?
 
they even plan to have the whole core-kernel etc use snap instead of repos
yes
i begun using arch to have knowledge on another linux architecture just in case they go through with making snap the main source
i use debian which is not depending on snap on my raspberry pi 3b
 
2:11 PM
@EliahKagan we can do some more testing :D
 
and arch on my laptop, one to have actual full control of what is installed and keep it low profile, my laptop isn't the newest
 
@Zanna I think it would be best for this to be a separate answer, though.
 
I was talking about the shutdown problem
you asked if you should edit your answer... I don't know
my system said it had reached target shutdown... it was mostly shutdown, but it refused to shutdown completely
 
@Zanna Oh. Sorry.
 
regarding attempting to restore a missing libc, I agree that should be a separate answer here (or elsewhere)
but "we can do some more testing" applies to your comments about that too ^^^
 
2:20 PM
Are you thinking maybe it should be a separate question because, with a missing libc, the stuff about LD_PRELOAD is much less relevant?
 
yeah... OP wanted to use LD_PRELOAD which was a pretty intelligent approach to the problem. But even if that could work (which would actually be terrible as you explained), it would not be useful if there were no libc anywhere on the system...
 
It could work if you were already root.
 
it could?
 
2:36 PM
Yes.
A non-root user cannot make sudo, pkexec, su, etc., nor other setuid programs like passwd and ping, use LD_PRELOAD, because that would be a security risk. A user can run other programs with LD_PRELOAD, and root can too. Root can even run setuid root programs with LD_PRELOAD, because the effective user ID is not actually being changed to be different from the real user ID when root does that.
In the case of just having to rename a file, there's no reason to mess around with LD_PRELOAD on Ubuntu, because Ubuntu has the busybox-static package installed, which is simpler and way easier to use for that. If the OP had a root shell, then then could just run busybox mv source destination. But they could also run LD_PRELOAD=/path/to/libc.so.6.bak mv source destination.
Does that make sense? Also, if it does, but is not apparent from my answer, then I think that's another reason to consider editing my answer, though less vital than it would be to change the part about REISUB if I am wrong to have claimed that REISUB is better than attempting a normal shutdown if one has broken libc.
@Zanna I had meant, did it have your modifications that you had pressed e to apply and pressed F10 to use. I had expected that if it was going back to the original GRUB menu rather than actually rebooting the machine, that it might have them. I don't think that expectation of mine, even as the speculation it was, was actually reasonable, though. On the other hand, I've been wildly wrong about which of my speculations are reasonable before (like how omitting quotes makes it work).
Perhaps the best approach would be to make an new self-answered question about how to solve the problem with libc.so.6 deleted, change the title, and link (but not dupe) the questions. I'm unsure though.
@Zanna That answer looks like it covers the 64-bit system case quite well. Are you saying you'd originally written it based on testing just on a 32-bit system?
Graphviz, the OP mentions in their comment, is a graph visualization program. I don't know how it relates to petrify (besides what the OP says, which I assume is accurate) because I don't know anything about petrify (though it looks interesting).
 
2:56 PM
@EliahKagan sorry, I think I understood from your answer that if you were already root, you would be able to use LD_PRELOAD effectively. That makes sense. I thought you were suggesting that if one were already root, having deleted libc would be fixable
@EliahKagan no, I tested it on my 64-bit system... I assumed OP was also using a 64-bit system because of the error they got (though they could have got that error if they were in the wrong directory of course) but I also assume that the binary would "just work" on a 32-bit system
 
@Zanna Yeah, it would be fixable either by via busybox or through using LD_PRELOAD. I just don't recommend the LD_PRELOAD way because it is needlessly complicated on Ubuntu (and Debian, and many other systems).
 
but, I mean, how would you load it, if you had deleted it?
the reason I thought I should try to extend my answer there is that petrify comes with two commands (that are symlinks to petrify!) but which apparently need this other program, Dot, to be installed, which I could not find, so did not attempt to install. But OP found a package in official repositories that made one of those commands work. So while their comment is useful, I should probably test out what they said and incorporate it into my answer...
 
@Zanna Oh. Well you could extract it using a statically linked executable, then use it, though it does seem silly to use busybox ar or something to extract it but then use LD_PRELOAD /path/to/extracted/libc.so.6 mv /path/to/extracted/libc.so.6 /lib64/or/wherever/libc.so.6.
@Zanna One of them works with graphviz in lieu of dot?
 
but extract it from where?
@EliahKagan apparently yes
 
Well, you could add that info, right?
 
3:09 PM
yeah, just need to test it, but I don't think I can do that because I don't know what the program is actually supposed to do. Maybe I can figure it out... or maybe I should encourage OP to post something?
I guess I'm saying stupid things, probably because I don't understand what statically linked means, for a start
 
@Zanna Encouraging them to post something sounds good.
Personally I have found asking people questions like, "Do you want to post..." is very effective. :)
I don't want to discourage you from working on it yourself though. (I don't, like, know the answer to that, or, uh, anything about petrify. If I didn't say, or post something myself.) Maybe they could work on one part and you another? I'd be interested in the approach of attempting to find and install dot...
@Zanna It means that the file contains its own copy of the library, rather than using a shared library.
In the case of an executable that is statically linked, it contains the object code (machine code and related metadata) of the library. If an executable uses static linking or all its libraries, then it doesn't need any shared libraries. So, like, if you statically link (to some implementation of) libc instead of using the usual shared libc, then you don't need libc.so.6 to be present on the system.
 
3:24 PM
@EliahKagan thanks :) I made a comment. Sort of kept looking at that in my inbox thinking I should do something but not sure what
 
@Zanna I don't think anything you've said sounds stupid though, nor did it suggest to me that you weren't familiar with static linking. You know about shared libraries, which are the more sophisticated concept. :)
 
oh I see, so with sufficient permissions you would have enough stuff on the system that functioned to restore the lost libc
when I read your answer last night, I must have been skimming the earlier sections a bit because I was sort of half-awakely thinking I should tell you not to make it seem like there was no alternative to using a live system, because OP had implied they couldn't (although apparently they did) and it's always awesome to have some way that might work if you don't have physical access etc, but in the morning I read your answer again and it wasn't giving the impression that I'd thought it was
 
@Zanna Could this have been due to edits?
@Zanna The issue isn't that with sufficient permissions you can use the necessary tools. The issue is that with sufficient permissions you can copy the file.
 
anyway, now I live somewhere I have access to numerous computers and I could easily make a live USB if I didn't have one, but previously I was living somewhere I did not have access to any other computers, and it would have taken days for me to have an opportunity to make a live USB if I couldn't use my own machine
 
For users who are very uncomfortable with doing stuff that's more technical than usually required, they might still want to wait a few days, I think, because they might be (reasonably) afraid of making the problem worse and not knowing how they had.
I do want to give people the choice, though.
 
3:38 PM
@EliahKagan yes, I looked at the revisions and I think that the introductory part changed, but it changed after I first read it, and before I read it the second time, which is why I say I must have skim-read it the second time
 
It's true that root can run setuid root executables with LD_PRELOAD and other users can't, but it's not necessary for root to run them in this situation anyway, because root is already root. The useful executables, other than those used to do stuff as root, are non-setuid and do work with LD_PRELOAD (though I advocate using busybox instead).
@Zanna Ah, okay.
 
@EliahKagan I see that
 
Sorry...
 
no, I am really grateful for the explanation! I just don't want to keep making you repeat things that you already explained really well already if possible
I definitely won't be offended if you somehow manage to tell me things I already know (which with me is a bit like the alpha particles bouncing off the nucleus in the gold foil experiment). I just feel slightly guilty about having so much educative energy lavished on me, especially when you already wrote a perfectly good answer about the subject
 
I am hoping the answer is good and clear.
Also I am hoping its advice to use REISUB is not excessive.
Aside from that, I am interested in talking about things that are... interesting.
 
3:51 PM
I am wondering if REISUB would do anything to my system in the state it had managed to reach
 
I'm less interested in things that I'm, uh, less interested in, but I can take responsibility for distinguishing between the two in my own chat usage decisions. :)
 
oops sorry
 
seems like I was telling you what you should talk about :(
 
I had not interpreted it that way, or had it occurred to me to do so.
 
3:53 PM
ok :)
since I've had this device, I've had many c-state freezes and issues shutting down, and none of them have ever responded to magic sysrq REISUB treatment
 
Instead I was trying to assuage what I think is your concern that I might feel obligated to engage in topics that aren't sufficiently worthwhile to me. I do not feel obligated to do so.
 
that's excellent
 
@Zanna Well the kernel has to be able to do something for REISUB to work.
 
yes...
I mean, for this reason (the peculiarities of my toaster) I have not had much faith in it
and as a result have probably abused the power button more than was strictly necessary
@EliahKagan should I try it again?
 
@Zanna To find out what?
Do you mean, like, to capture all the messages?
I'm not worried REISUB might not work; I'm worried it might be inferior to a regular shutdown.
There was an Ubuntu release with a bug where SysRq magic was disabled, but that was fixed and the release is EOL. Supported Ubuntu releases allow SysRq magic, i.e., allow R, and allow at least the "SUB" part. The EI parts might not work on most machines these days -- those send SIGTERM and SIGKILL to each process except init. But I'm not real worried about that for this case (nor for most cases). I also don't subscribe to the view that everybody should re-enable E and I without specific reason.
 
4:10 PM
@EliahKagan I don't know... earlier you asked me (or maybe you were more wondering aloud/to the room in general) if I thought you should edit your answer because my system seemed to have mostly shut down. But it refused to fully shut down and I did something undesirable. So maybe I should have done something else at some point
I remember reading in that post on the canonical question What to do when Ubuntu freezes that I have to edit some file to enable magic sysrq... that was about 2 years ago though
 
Oh, yeah, I would totally try Alt+SysRq+REISUB (or REISUO if you want to power off instead of rebooting) if you try to shut down and it gets stuck. But if you tried that on your system and found it didn't work, I would still recommend people try it first before doing a hard reset. So the result of you trying wouldn't likely change my answer. What I'm worried about is the part of my answer where I suggest to do that instead of attempting a normal reboot in the first place (when libc is broken).
So I don't think you need to test that. To clarify, I recommend that you try REISUB in future situations like this before a hard reset, but I'm not asking you to test it now.
 
ok. I guess it seems to me it might be worthwhile knowing
- whether I could have got the system to finish shutting down by doing REISUB
- if I had used REISUB *instead* of attempting a normal reboot, the system would have gone all the way down
 

« first day (246 days earlier)      last day (2200 days later) »