The boot process can't find the root partition (the part of the disk, that contains the information for starting up the system), so you have to specify its location yourself.
I think you have to look at something like this article: how-rescue-non-booting-grub-2-linux
short: in this grub rescue> command line type
ls
... to list all available devices, then you have to go through each, type something like (depends what is shown by the ls command):
ls (hd0,1)/
ls (hd0,2)/
... and so on, until you find
(hd0,1)/boot/grub OR (hd0,1)/grub
In case of efi
(hd0,1)/efi/boot/grub OR (hd0,1)/efi/grub
... now set the boot parameters accordingly, just type this with the correct numbers and after each line press return
set prefix=(hd0,1)/grub
or (if grub is in a sub-directory)
set prefix=(hd0,1)/boot/grub
Then continue with
set root=(hd0,1)
insmod linux
insmod normal
normal
Now it should boot. Start a commandline now (a terminal) and execute
sudo update-grub
... this should correct the missing information and it should boot next time.
If not, you have to go through the steps again an might have to repair or install grub again (look at this article: https://help.ubuntu.com/community/Boot-Repair)
On a qemu virtual machine Ctrl-Alt-Del does it (also sendkey ctrl-alt-delete in the qemu monitor; but on my machine I can simply type Ctrl-Alt-Del -- they're not special in my "desktop environment").
I'm not using virtualbox, but google says that virtualbox has a menu option (Input->Keyboard->Insert Ctrl-Alt-Del)
Best Answer
Single user mode has not been the right term for quite some time. In the 1990s, what used to be single user mode split into emergency mode and rescue mode. You are not in fact using either one.
What you are actually doing is a poor idea, because it involves running a program as process #1 that is not designed to do the jobs that process #1 actually needs to do. You would be better off using emergency or rescue modes, the latter of which is invoked by the accepted answer that the answer that you point to, itself points to.
Yes, signals will act oddly. Process #1 has special semantics for signals, for starters, which is one of the several reasons that
init=/bin/bashis a poor idea. Furthermore, job control shells cannot do job control when/dev/consoleis their standard I/O but nothing has set up a proper session with a controlling terminal, as the Bourne Again shell actually told you as soon as it started up.It is possible with some simple chain-loading tools to set up a proper session with a controlling terminal, and thence enable job control and signal delivery to a foreground process group, but that does not fix all of the other things that will go wrong with
/bin/bashas the process #1 program because you have to carefully do them explicitly, by hand.Just use rescue mode or emergency mode.
Further reading
open-controlling-tty. nosh toolset. Softwares.setsid. nosh toolset. Softwares.vc-get-tty. nosh toolset. Softwares.