[lug] mysterious fstab

[Harris, James]

Well, I can't answer for everything, but you are correct in assuming that
the "LABEL=" causes a substitution with the device name.  This is achieved
by formatting the filesystem with a label such as "/boot", in this example.
When you specify the mount using the label instead of the device, it goes
out and mounts the filesystem it found at boot time with that particular
label.  This is a super cool way of keeping things more dynamic.  I suppose
these labels could affect a make bzdisk if it is getting information from
the fstab and doesn't understand how to replace the labels.

In case you want to verify what your filesystems are you can always take a
look at their superblocks to see the label:
/sbin/dumpe2fs -h /dev/hda1

You may want to do this on all of them, make a backup of the current fstab
and replace it with one that uses the device names instead of the labels.
Then give the make bzdisk another try, it'd only take a minute and might
resolve the make bzdisk problem.

-Jim

-----Original Message-----
From: D. Stimits [mailto:stimits at idcomm.com]
Sent: Saturday, May 26, 2001 23:59
To: BLUG
Subject: [lug] mysterious fstab


After installing RH 7.1 on a machine which uses a separate /boot/ and /,
I went to make a new 2.4.5 kernel for it, and wanted to test it on a
boot floppy. The boot floppy fails with repeating AX, BX, CX, DX style
register dump, infinitely repeating. So one thing I did was consider
mkbootdisk. I noticed in the man page it says it reads /etc/fstab. But
when I look at /etc/fstab, I see these lines for / and /boot:

LABEL=/                 /                       ext2    defaults       
1 1
LABEL=/boot             /boot                   ext2    defaults       
1 2

How can it get away with no mention of the actual device for "/" and
"/boot"? It should be /dev/sda2 and sda1, but nowhere does it mention
it. I can only assume there is some new means of doing a form of
variable substitution on "LABEL"...otherwise I don't see how the
original install could succeed. What the heck is going on there? Could
this have anything to do with a "make bzdisk" creating a failed boot
floppy? FYI, I did switch the compiler named from gcc to kgcc for the
compile. Has anyone here successfully compiled a stock kernel with RH
7.1?

On another area of kernel builds, more out of curiosity, I notice that
the default RH kernel install included in /boot/ not just the vmlinuz
images, and any initial ram disks, it also includes a vmlinux file
corresponding to each vmlinuz image. What is the purpose of the vmlinux
file if vmlinuz is the actual boot kernel? Is this part of initial ram
disks or support for a separate /boot/ partition?

D. Stimits, stimits at idcomm.com
_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug