[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What is device 03:4c?



On Tue, Jun 21, 2005 at 05:56:04PM -0400, Marty wrote:
> Hendrik Boom wrote:
> >
> >The actual MBR used for both the failing boot and the successful boot
> >are on /dev/fd0.  LILO was told boot=/dev/fd0. It's remarkably safe
> >to play with a floppy's MBRs, because you can have so many of them.
> 
> There is a "feature" (bug?) in LILO that I've never quite understood but
> have worked around by always making any intended second target boot/root

My boot and root partitions are separate.

> partition the "first" drive in the system (either by removing the exist
> hda/sda or by changing the target partition to hda/sda). Then I boot with
> a rescue floppy kernel, specifying the target boot/root partition on the
> LILO boot option line, and then running lilo after booting up.  It's a
> pain in the butt, but I have learned to live with it.
> 
> If I don't do it this way, lilo always seems to write the MBR to the "first"
> drive's partition (the one I booted up on) instead of the new one I specify
> in lilo.conf.
> 
> Running LILO with one or more -v options may clarify whether you are running
> into this issue.  If you have this problem you will need a rescue floppy or
> standalone CD-ROM that supports reiser fs.

When I run lilo, it does appear to write to the floppy disk.
When I boot from the floppy after lilo writes to it,
the boot menu does have the changed entries in it.

So I think it is indeed writing to the proper place.

When I ask it to write to the hard disk, I do specify /dev/hda.

> 
> >
> >The successful boot has /boot on /dev/hda8, and it is not marked bootable
> >Its / is on /dev/hdb5.  Neither /dev/hda8 and /dev/hdb5 are not marked
> >bootable, but the boot works.
> >
> >The only obvious difference are
> >	the partitions are in different places on the hard disk
> >	when /boot is marked bootable, it fails
> >	the failing boot is the only one with / being reiserfs.
> >	The others are ext2.
> 
> Another obvious question: Did you check to make sure your reiser partition
> kernel has the drivers or modules required to support reiser fs?

The contents of the boot and root partitions in the copy (which was to
be upgraded to sarge) are exact copies of the ones I boot from
successfully (made with tar piped to untar), except for
  * changed /etc/fstab entries that properly
refer to the copy, not to the original.
  * changed /etc/lilo.conf to point to the same files and partitions,
but with the altered names from /etc/fstab
  * the root partition in the copy is a reiser partition.

The /etc/lilo on both systems provides stanzas for both the original
and copied systems, and also a DOS partition (which hasn't booted
since Y2K, but works fine with dosemu).  Of course I haven't been able
to use the /etc/lilo.conf in the copy yet, because I can't get it to boot.

The original system can read and write the reiserfs, so I presume the
copy would have the same drivers.

Unless, of course, some boot process needs to read the root partition
before it has discovered the reiser kernel modules.  Is that likely?
Just when *does* the boot process load its modules from /boot?  Does
it have to read from /etc first?  Could that be the problem?

Here's the lilo.conf stanza for the copy:

image = /sargeboot/vmlinuz-2.4.16-586
	read-only
	initrd=/sargeboot/initrd.img-2.4.16-586
	root = /dev/hdb12
	label = sargetobe

/dev/hdb12 is the reiser partition; /sargeboot is ext2.
The lilo.conf in the copy itself (which has never been used yet)
of course mantions /boot instead of /sargeboot to refer to the
exact same boot partition.

I still have another empty partition available : /dev/hdb13,
the same size as /dev/hdb12,  the root partition for
the copy.  I suppose I could make /dev/hdb13 into an ext2
file system,  copy /dev/hdb12 into it, and see if that boots.
It would answer questions whether the use of reiserfs is the
problem.

-- hendrik

> 
> >
> >-- hendrik
> >
> >
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact 
> listmaster@lists.debian.org
> 



Reply to: