On Fri, May 18, 2012 at 06:32:34PM +1000, Jason White wrote:

Colin Fee <tfeccles@gmail.com> wrote:

...

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

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 <cas@taz.net.au> BOFH excuse #30: positron router malfunction

On Sat, May 19, 2012 at 03:09:37PM +1000, Colin Fee wrote:

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)

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 <cas@taz.net.au>

On Mon, May 21, 2012 at 12:33:41PM +1000, Trent W. Buck wrote:

Craig Sanders wrote:

...

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.

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 <cas@taz.net.au> BOFH excuse #2: solar flares