[vox-tech] Getting new Linux box to boot

[Jeff Newmiller]

On Fri, 31 Dec 2004, Richard S. Crawford wrote:

> On Friday 31 December 2004 11:07, Peter Jay Salzman wrote:
> >    1a. cd into your *real* root filesystem, /mnt
> >    1b. Use chroot.  This makes /mnt temporarily "look" like /.
> >    1c. Run lilo and reboot.
> 
> I remounted lumix to /mnt/lmx via:
> 
> # mount /dev/hda1 /mnt/lmx -t ext2 -o exec
> 
> Then I executed mount and got this:
> 
> # mount
> .
> .
> .
> /dev/hda1 on /mnt/lmx type ext2 (rw)
> 
> which seems like the exec flag is not being set.

That looks about like what the output of mount is on my
(working) system.  I think you are misinterpreting the (rw).

> 
> Also, when I tried chroot:
> 
> # chroot /mnt/lmx /bin/sh
> 
> I got:
> 
> illegal instruction
> 
> I double checked and made sure that sh is really in /mnt/lmx/bin/sh
> 
> All I can figure is that for some reason the exec flag is not really being set 
> when I execute the mount command, and this is causing the chroot command to 
> fail.

I run chroot something like this:

# mount -t ext3 /dev/hda3 /mnt/hda3
# cd /mnt/hda3
# chroot .

This avoids the issue that your current directory is outside the "view" of
the chroot environment when the chroot command returns control to you.  I
am also depending on the default behavior to start a shell in the chroot
jail.

What you have to keep in mind when using chroot, is that all the processes
you spawn from that point forward from that shell will load libraries,
refer to configuration files, and look for executables from the
perspective that /mnt/hda3 is the root.  Therefore, if the fstab on the
disk you are trying to resuscitate looks something like this [1]:

/dev/hda1   /boot  ext3  defaults   0 1
/dev/hda2   none   swap  sw         0 0
/dev/hda3   /      ext3  defaults   0 1

then you will want to premount the /boot partition in the appropriate
place before running lilo/grub:

# mount -t ext3 /dev/hda3 /mnt/hda3
# mount -t ext3 /dev/hda1 /mnt/hda3/boot
# cd /mnt/hda3
# chroot .

Thus, all the files are in place before you switch your perspective to the
simulated "normal" root partition.

Given your error, I would want to confirm that your "/lib" or "/bin" are
available and mounted properly.... even though putting such directories in
different partitions would be very strange.  "/usr" should not have to be
available at this point. I have not actually encountered your error yet,
though, so I don't know what the problem is in this case.

I don't recall what your rescue disk is, but if it has strace on it, you
might try that to see about where it barfs.  Knowing which libraries and
files it just loaded when it dies could provide some clues as to what is
going on.

--- 

[1] On older hardware, having your kernel reside in a smallish (100mb?)
boot partition near the front of the disk may be wise, since the bios may
not be smart enough to see your whole hard disk and if the kernel were
stored toward the end of it then LILO or GRUB might not be able to load
it.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------