Discussion:
grub init /bin/bash
Colin Fee
2012-05-18 06:28:59 UTC
Permalink
A work colleague was reading a blog and in one of the comments was a
statement saying that if you append

init=/bin/bash

to the grub boot line e.g.

linux /vmlinuz-3.2.0-2-amd64
root=UUID=26585ddb-7dde-4a7e-b2c7-e32330bb4cc8 ro splash quiet
init=/bin/bash

you end up ia a shell with root privileges.

So we had go at it and it works. We even tried booting with a USB tick in
place to see if you could copy stuff to it and you can.

The question that arose was what about network access? Do you have it? i.e.
is there a tcp/ip stack running and if not how would you load one etc?
--
Colin Fee
***@gmail.com
l***@levlafayette.com
2012-05-18 06:50:01 UTC
Permalink
Post by Colin Fee
A work colleague was reading a blog and in one of the comments was a
statement saying that if you append
init=/bin/bash
to the grub boot line e.g.
linux /vmlinuz-3.2.0-2-amd64
root=UUID=26585ddb-7dde-4a7e-b2c7-e32330bb4cc8 ro splash quiet
init=/bin/bash
you end up ia a shell with root privileges.
*shh* Don't tell everyone :)

Actually, this is a "not uncommon" way to reset root's password in case it
has been forgotten...

All the best, Lev
Jason White
2012-05-18 08:32:34 UTC
Permalink
Post by Colin Fee
The question that arose was what about network access? Do you have it? i.e.
is there a tcp/ip stack running and if not how would you load one etc?
What happens if you run ifconfig eth0 or a similar command?

I can't think of a good reason why you couldn't run ip, ifconfig, etc in that
situation.

You might have to load the required kernel module if udev isn't working.
Craig Sanders
2012-05-18 23:20:34 UTC
Permalink
Post by Jason White
Post by Colin Fee
The question that arose was what about network access? Do you have it? i.e.
is there a tcp/ip stack running and if not how would you load one etc?
What happens if you run ifconfig eth0 or a similar command?
I can't think of a good reason why you couldn't run ip, ifconfig, etc in that
situation.
you can.

i've done exactly that countless times so that i can do stuff like:

- run wget or whatever to fetch files from the net
- run an apt-get install or upgrade
- scp or rsync files in or out of the machine
- ssh in from a remote host
Post by Jason White
You might have to load the required kernel module if udev isn't working.
true.

also, the environment and console isn't set up quite right (e.g. ^C
wont kill an app) so you'll need to set it up with stty. and the rootfs
will be mounted read-only so you'll need to remount it RW in order to
make any changes, and you also get only one VT, so if you need more
you'll need to run them with openvt (aka "open", depending on version or
distro) or just run screen.


booting with 'init=/bin/bash' is useful in an emergency and still
occasionally neccessary, but these days i find it less hassle and more
useful to just pxeboot a rescue system (i tend to use clonezilla, it
makes an excellent command-line rescue system once you exit the cz
backup/restore menu) and mount the host's filesystem(s) under /mnt. and
'chroot /mnt' if necessary.

I have a gparted ISO available in my pxeboot menu too, in case i need to do
major partition shuffling/resizing etc, but I prefer to use clonezilla for
everything else.

i also have cz configured on my pxeboot server so that it starts up sshd
and sets up a few useful things like the following alias in case i need
to do something like grub-install while in the chroot:

alias prepare-chroot-mnt='for i in proc dev sys ; do mount -o bind /$i /mnt/$i ; done'





BTW, it's possible to use memdisk from syslinux to boot clonezilla or
any other hd, floppy, or ISO image from the grub menu, so you can do
this without setting up a pxeboot server. i've used memdisk to boot up
freedos floppy images for BIOS updates etc.

and recent ipxe packages in debian can optionally add an ipxe entry to
the grub menu so you can still netboot in case you're not fast enough to
press F8 or F12 or whatever to get the BIOS boot selection menu. useful.

e.g. my grub boot menu on my main machine at home currently looks like
this:

# grub-list-kernels.pl
0 Debian GNU/Linux, with Linux 3.2.0-2-amd64
1 Debian GNU/Linux, with Linux 3.2.0-2-amd64 (recovery mode)
2 Debian GNU/Linux, with Linux 3.2.0-1-amd64
3 Debian GNU/Linux, with Linux 3.2.0-1-amd64 (recovery mode)
4 Network boot (iPXE)
5 Bootable floppy: LSI
6 Bootable floppy: freedos-bare

Default: 0 Debian GNU/Linux, with Linux 3.2.0-2-amd64


craig

ps: for the OP - if you every wondered why grub has the option for
setting a password, then disabling the ability to edit the boot command
line is one of the main reasons...useful in, e.g., a computer lab at a
university, but anyone who has physical access to the machine can defeat
simple security measures like this.
--
craig sanders <***@taz.net.au>

BOFH excuse #30:

positron router malfunction
Colin Fee
2012-05-19 05:09:37 UTC
Permalink
Post by Craig Sanders
e.g. my grub boot menu on my main machine at home currently looks like
# grub-list-kernels.pl
0 Debian GNU/Linux, with Linux 3.2.0-2-amd64
1 Debian GNU/Linux, with Linux 3.2.0-2-amd64 (recovery mode)
2 Debian GNU/Linux, with Linux 3.2.0-1-amd64
3 Debian GNU/Linux, with Linux 3.2.0-1-amd64 (recovery mode)
4 Network boot (iPXE)
5 Bootable floppy: LSI
6 Bootable floppy: freedos-bare
Default: 0 Debian GNU/Linux, with Linux 3.2.0-2-amd64
craig
ps: for the OP - if you every wondered why grub has the option for
setting a password, then disabling the ability to edit the boot command
line is one of the main reasons...useful in, e.g., a computer lab at a
university, but anyone who has physical access to the machine can defeat
simple security measures like this.
Agreed. That's essentially the discussion we were having when where mucking around with grub; that to make that kind of edit you needed physical access and so any measures like grub passwords were superfluous.

In your grub menu example above do the bootable floppy options point to a floppy image e.g. an iso, or to a real device?

Colin.
Craig Sanders
2012-05-19 23:49:23 UTC
Permalink
Post by Colin Fee
Agreed. That's essentially the discussion we were having when
where mucking around with grub; that to make that kind of edit you
needed physical access and so any measures like grub passwords were
superfluous.
not exactly superfluous, just fairly easy to defeat if you have
unsupervised physical access to the machine. same as a BIOS password can
be cleared by opening the case and removing the CMOS battery for a few
minutes (or some motherboards have a CMOS erase button)
Post by Colin Fee
In your grub menu example above do the bootable floppy options point
to a floppy image e.g. an iso, or to a real device?
both are 1.44MB freedos floppy images. i can't remember the last time i
had an actual floppy drive installed in a computer (i still have a few
lying around but i stopped bothering to install them years ago)

craig
--
craig sanders <***@taz.net.au>
Trent W. Buck
2012-05-21 02:33:41 UTC
Permalink
Post by Craig Sanders
also, the environment and console isn't set up quite right (e.g. ^C
wont kill an app) so you'll need to set it up with stty.
If you have a one-liner to enable job control in pid 1, please share it.

atm I use open (as you mentioned) as a workaround.
Post by Craig Sanders
and recent ipxe packages in debian can optionally add an ipxe entry to
the grub menu so you can still netboot in case you're not fast enough to
press F8 or F12 or whatever to get the BIOS boot selection menu. useful.
Got an opinion on ipxe vs. gpxe?
Post by Craig Sanders
ps: for the OP - if you every wondered why grub has the option for
setting a password, then disabling the ability to edit the boot command
line is one of the main reasons...useful in, e.g., a computer lab at a
university, but anyone who has physical access to the machine can defeat
simple security measures like this.
...hence the tamper-detection reed switches in e.g. Dells. (Not that
it helps much IMO)
Craig Sanders
2012-05-21 04:06:29 UTC
Permalink
Post by Trent W. Buck
Post by Craig Sanders
also, the environment and console isn't set up quite right (e.g. ^C
wont kill an app) so you'll need to set it up with stty.
If you have a one-liner to enable job control in pid 1, please share it.
not really. IIRC i set stty intr, and a few other things, but even then
i never got the console set up perfectly - just good enough to do basic
repairs.

which is one of the reasons why it's far less hassle to just boot a
rescue system.
Post by Trent W. Buck
Got an opinion on ipxe vs. gpxe?
still undecided. i think ipxe will be the clearly superior choice in a
year or so, but at the moment there are pros and cons to both.

overall, though, i prefer ipxe. i switched to it over a year ago.

i can't even remember what reason i had for thinking gpxe could still be
a better choice in some situations...but my brain's not working properly
due to a cold or flu or something (despite the duuuuhhhh symptom this is
probably not the start of the zombie apocalypse).


IIRC, ipxe forked from gpxe because one of the main gpxe devs was not
accepting patches, not making new releases, and generally exercising way
too much control over the project. so the other devs forked it and it
has been actively developed ever since.

craig
--
craig sanders <***@taz.net.au>

BOFH excuse #2:

solar flares
Trent W. Buck
2012-05-21 07:33:25 UTC
Permalink
Post by Craig Sanders
Post by Trent W. Buck
Got an opinion on ipxe vs. gpxe?
still undecided. i think ipxe will be the clearly superior choice in a
year or so, but at the moment there are pros and cons to both.
Sounds like what I remember when I looked.
Post by Craig Sanders
overall, though, i prefer ipxe. i switched to it over a year ago.
I haven't cared enough; I use the intel pxe rom when it's available.
Post by Craig Sanders
i can't even remember what reason i had for thinking gpxe could still be
a better choice in some situations...but my brain's not working properly
due to a cold or flu or something (despite the duuuuhhhh symptom this is
probably not the start of the zombie apocalypse).
IIRC better hw support in gpxe for now -- unless I'm mixing up
gpxe/ipxe with uboot/<whatever the uboot fork is called>...

Russell Coker
2012-05-18 09:17:00 UTC
Permalink
It has always been this way since before grub was written.

You can run modprobe and ifconfig commands to get networking going or you can use openvt to start bash on a different VC before running "exec /sbin/init" to have the matching boot in a normal way.
--
Sent from my Samsung Galaxy S Android phone with K-9 Mail.
Duncan Roe
2012-05-18 21:45:06 UTC
Permalink
Post by Colin Fee
The question that arose was what about network access? Do you have it? i.e.
is there a tcp/ip stack running and if not how would you load one etc?
Because you started a shell in place of init, absolutely nothing is configured.
To get, for instance, network connectivity, you need to run at least the
relevant scripts in /etc/rc.d or wherever.

Cheers ... Duncan.
Loading...