@Zanna They're expecting that LD_PRELOAD would enable them to make sudo run with an alternate libc. Obviously that's prohibited for security reasons--the UID and EUID have to be the same for LD_PRELOAD to have an effect, prohibiting setuid executables like sudo from having their behavior modified when they are run as non-owners. I've posted an answer.
Regarding the LD_PRELOAD question, they've commented. I guess I should edit my answer to make more explicit that the same holds for su -- I think they understand that from my answer, but some readers might not. When I do, I might also add something about how they have the option of booting with init=/bin/busybox as a kernel option.
Sorry, I mean with init=/bin/busybox sh.
I hope this comment makes sense. I'll be afk for a few minutes shortly, then for a while longer.
If I understand them right, they already fixed it and that forthcoming edit of mine isn't urgent.
@EliahKagan haha sorry, I mean, I'm not sure that they fixed it, from their comment which sounds like they did fix it, but might actually be expressing an intention to fix it
I think they gave up on trying to fix it without rebooting and booted from a live DVD before seeing my answer (or perhaps they accessed the site from the live environment). That seems like the most likely explanation for their very quick reply and accept. However, I admit this isn't the only possibility.
I'm actually not sure how to do this and I don't have the ability to easily test it right now.
Kernel boot options in GRUB can be specified with double quotes; that's no problem. But does init="/bin/busybox sh" cause /bin/busybox to be used as the init process, with sh passed as its first command-line argument (which is what I want), or does it attempt to use a (presumably nonexistent file) whose full path is /bin/busybox sh as the init process?
Should this be an addition to my answer? Or should it be a separate answer. You had pointed out in comments (since deleted) that regular recovery mode won't work.
If you think it shouldn't be a separate answer then I am totally willing to add it to mine.
It's just... not only have I not tested it, I haven't written the instructions yet and I'd have to check how to do it. I haven't messed with boot options in GRUB for over a year now. It's terrible! :)
@EliahKagan I don't think I've done that... but why would I need to change boot options in the live system? I thought we did that by pressing F6... but it was a GUI-based thing
@Zanna Yeah, F6. That doesn't work for GRUB on an installed system, though, does it?
On an installed system you hold Shift (if necessary) to get a list of kernels. Then select one and press the key to edit its config temporarily. I think that key is Escape. Then add the boot option. I think that's right.
I always get the GRUB menu (by force) because shift doesn't work for me
nothing in fact works for me except forcing the menu. So I just force it to come up every time, because I very often have to boot a different kernel for some stupid testing or tinkering
@Videonauth Do you know if it's possible to make GRUB boot the kernel with busybox sh as an alternate init? This is like the old init=/bin/sh trick, but with /bin/busybox sh instead for systems where the reason you have to do it is to fix libc (which /bin/sh depends on and /bin/busybox doesn't).
@Zanna Doesn't busybox print its list of commands and exit when run with no arguments?
You should just boot from a live USB (or CD/DVD) and rename libc.so.6 back.
LD_PRELOAD doesn't work with setuid executables. But, if you want, you can use /bin/busybox to do last-minute backups (that don't require running commands as root) before rebooting.
Currently you are attempting to make ...
You can. I doubt it would work. You're right it shouldn't.
I need to brush up on this. @Videonauth had you been saying in AUGR that cross-compiling a kernel for ARM is hard? I should attempt that immediately. :)
I've compiled kernels a number of times but never cross-compiled one for anything.
@Zanna So, first, what happens when you do init=/bin/sh or init=/bin/bash? Does that give you a shell instead of starting up normally?
If not, then the problem may not be the way in which busybox sh is being expressed.
How does it know to pass sh as a command-line argument if it's not passing whatever else comes after it as a command-line argument? Is there a -- somewhere or something? Does the kernel treat that specially. I recall something about it doing so. (It's not obvious that it would.)
...Why did I think it might work without the quotes?
I mean it did, but why did I think it did?
I'm going to pretend say that I remembered something about that.
busybox has a reboot builtin. I can just say to use that in my answer.
I mean, you can try it. If you do I might mention if it works, if I have room. But it's not at all important. They and other readers would probably just want to run reboot after restoring the backup.
why do you think reboot doesn't work? that's the kind of thing that makes writing answers difficult "er, this should work, but it didn't work for me and I don't know why..."
@Zanna reboot with no options tells init to reboot gently. If no appropriate init is running the it won't work. It should work with -f.
ek@Io:~$ busybox reboot --help
BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) multi-call binary.
Usage: reboot [-d DELAY] [-n] [-f]
Reboot the system
-d SEC Delay interval
-n Do not sync
-f Force (don't go through init)
for busybox/android users:
you need to add a space (in contrast to normal usage) between 'remount' and 'rw':
mount -o remount, rw /
otherwise it won't work.
@Zanna Most advice on Ask Ubuntu has it without the space, which works with the regular mount command provided by the mount package. That's why I'm wondering.
@Zanna Normally you sync or unmount a disk to ensure any writes that have not actually gone to the disk go to the disk. (This actually only deals with caching performed by the kernel, not by hardware. It also is not related to buffering by programs, but buffers are flushed when a program terminates normally.)
The S and U in REISUB are "sync" and "umount," respectively. The S achieves the same thing as the sync command; I believe the U remounts filesystems readonly.
sorry, I don't get it. you said "I wonder if it's better to explicitly sync the filesystem and go back to GRUB with Ctrl+Alt+Delete though." but I don't know what you are suggesting that would be better than
but I wouldn't know whether it would be better anyway, so, I don't need to get it, sorry
I can test the final progression of commands if you're too tired, otherwise unable, or just prefer not to do so. That should not be a problem. I have a machine available for this now. It is slow and hard to use, but for what is left, that should not cause any hassle.
To reboot the broken system, use Alt+SysRq+REISUB.
That does the syncing and unmounting and stuff that I'm planning to suggest they use commands for in busybox later. I should really add mention of REISUB into the post!
...Continuing on with the instructions for what to do in busybox (but please do mention if there are further problems getting into it):
That's all right. I don't think Alt+SysRq+REISUB requires testing.
I mean, it would perhaps have been better for your system had you used it...
So, in the busybox shell, after renaming the file, sync, remount readonly, and reboot:
sync
mount -o remount,ro /
reboot -f
Use a space after the , in the mount command if one was needed for the first one.
The -f flag is needed because otherwise reboot requires a working init (and it has to be running -- so even if libc6 is fixed, there's still nothing with the expected functionality of the init daemon running).
Awesome. I'll let you know when I've edited the post so you can look it over, but you need not do so immediately (nor at all, if you don't want to). In particular, you need not stay awake until then. I plan to do it soon but I can't be sure when I'll get it done; new difficulties always arise! :)
have renamed the file, sync'd, remounted ro, rebooted with -f (back to GRUB menu), booted into my system, and nothing is broken
just for clarity, at the GRUB menu, you choose Advanced options for Ubuntu, move the cursor to the kernel you want, but instead of pressing enter, press e, then you get the edit screen
so there are a couple of decent pictures of the GRUB menu around, but they are old... I can never find a good set of photos to illustrate this procedure
Anyway, given all the work you have just done... I think it would probably have made sense if you'd posted a new answer. I've done a significant amount of the edit to mine, though, and I know you had preferred not to post a separate one.
Besides doing the testing, you contributed considerably to the actual procedure. There was stuff I got wrong, stuff I didn't know/remember how to do, and so forth.
Well, I'll never get the edit done if I find all the ideal resources first. I can always add links. What do you think of this (not the whole edit, of course, just the wording about the GRUB menu):
> Hold down Shift so the GRUB boot menu appears. Select Advanced options for Ubuntu and press Enter. Select any kernel and press e to edit its boot options temporarily. Add init=/bin/busybox sh to the end and press F10 to boot it.
We had edit suggestions that claimed Shift never works anymore for anybody, remember? They didn't cite the claim and they made additional changes so they were easy to reject. But is that true? I never do this these days...
you can say if shift doesn't work try esc, but shift doesn't work for me and esc brings the boot menu instead XD
I read it has to be left shift
you might want to mention not to press enter on any of the kernels
because if you press enter it just boots
it's sort of intuitive that you select something by pressing enter I think
just now while I was testing a lot, I accidentally booted the system twice by pressing enter absentmindedly when I wanted to "select" a kernel to press e on!
I mean, I actually don't understand the distinction between 64-bit UEFI and 32-bit UEFI. But I remember that distinction exists and that you've mentioned it in connection with your machine.
yeah I don't understand either. Maybe everyone has described this problem misleadingly. In any case it was a fun intro to Linux having to go from 100% clueless to figuring out how to boot the installed system from the GRUB command line and compile GRUB to get anything to work apart from the live system. And when I say fun, I really mean it
You should just boot from a live USB (or CD/DVD) and rename libc.so.6 back.
LD_PRELOAD doesn't work with setuid executables. But, if you want, you can use /bin/busybox to do last-minute backups (that don't require running commands as root) before rebooting.
Currently you are attempting to make ...
for busybox/android users:
you need to add a space (in contrast to normal usage) between 'remount' and 'rw':
mount -o remount, rw /
otherwise it won't work.
