On 7/23/2010 6:17 PM, Denys Vlasenko wrote:
On Friday 23 July 2010 18:40, Jason wrote:
   It took me some time to figure this out so I'm sending this to the
list in case it helps others.

If you're getting this message when you launch a shell (sh):

       "can't access tty; job control turned off"

And you've looked at the FAQ on the subject:

       http://www.busybox.net/FAQ.html#job_control

But you're still having a problem.
Can you be more specific: what problem?
Problem: Not able to get a controlling terminal from /init script.

I tested this again and if I use __ exec setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1' __ in my /init script, I get "Kernel Panic - not syncing: Attempted to kill init!" Same thing if I use "exec setsid cttyhack sh". They do not give me a terminal at all. Just an immediate kernel panic.

My goal is to create an initramfs recovery shell from which I can re-partition and re-format the primary disk. Really, having a controlling terminal isn't required but I wanted to get rid of the "can't access tty" message and "setsid cttyhack sh" solves that for me.
Try this:

       setsid cttyhack sh

It will give you a controlling terminal (tty1) with job control turned
on without requiring a login.
(1) I don't want to mention a non-standard tool ctty in this FAQ entry.
ctty*hack* is names a *hack* for a reason.

(2) "setsid cttyhack sh" without exec creates a *child* shell.
This FAQ is meant to show how to give a ctty to *PID 1* shell.
This is important if the user wants to hand off control
of the boot process a-la "exec /sbin/init" later.
(1) That's fine. It was just a suggestion. I know it would have saved me some time had I known about it sooner. That's all.

(2) I don't fully understand the whole process but I can tell you what works and what doesn't. Like I said above, if I attempt to use exec to get a controlling terminal, I get a kernel panic. If I use "setsid cttyhack sh" inside /init to launch a shell and user types "exit", control goes back to /init script and I can do whatever I want. I can reboot or hand off control of the boot process using switch_root.

Note to web admin: It would be helpful if "setsid cttyhack sh" was
mentioned in the FAQ as a solution, as the solutions presented in the
FAQ do not work from the /init script within initramfs.  At least they
wouldn't work for me.  The console would hang if I tried to do __ exec
setsid sh -c 'exec sh</dev/tty1>/dev/tty1 2>&1' __ from my /init script.

Also, so the console doesn't hang when I type "exit", I do this in my
/init script:

       setsid cttyhack sh
# reboot if user types "exit"
echo s>  /proc/sysrq-trigger  # Sync
There is "sync" comand
       echo u>  /proc/sysrq-trigger  # Unmount (actually remounts
everything read-only)
and "umount -a"
       echo b>  /proc/sysrq-trigger  # reBoot

This requires that you have CONFIG_MAGIC_SYSRQ enabled in your kernel.
If someone has a better solution, please share.
Try "reboot -f".
I was using sysrq-trigger for all the commands since I thought I had to use it for the reboot anyway. But since "reboot -f" works, I have changed to using the appropriate commands. Thanks for the tip.
The reboot, halt, and
shutdown commands provided by busybox don't do anything for me.
Can you please give more meaningful bug reports? "Does not work"
isn't really providing enough information.
Just typing those commands without any arguments does nothing and as you confirmed, it's because I don't have busybox's init running.
I assume they require busybox's init to be running.
Without -f, yes, they do. That's the design (more like design flaw)
of traditional Unix way to shut down.
Gotcha.

By the way, I'm using BusyBox 1.16.1 with Linux kernel 2.6.23.5.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to