[lug] need init parameter
D. Stimits
stimits at idcomm.com
Fri Jul 20 01:10:00 MDT 2001
Tim Klein wrote:
>
> On Thursday 19 July 2001 09:51 pm, D. Stimits wrote:
> > I'm trying to find out if there is a way, during boot, at the boot
> > prompt when it is possible to specify kernel and other parameters, the
> > following...
> > ...I am able to specify the root partition, and tons of kernel
> > parameters, but I must find a way to *also* specify root filesystem
> > *type*. Yup, I got it working on my rescue, to a point, but it is only
> > able to find and mount a root system that is ext2. I really need to
> > specify, depending on circumstances, a root system of type xfs or
> > iso9660. It reminds me of a fingernail scraping across a chalk board...I
> > can tell it almost anything, but it demands ext2. Is this even possible
> > to specify an initial root filesystem of type that is not ext2?
> >
> > D. Stimits, stimits at idcomm.com
>
> Well, I don't really know the answer to your question, but I do know this.
> I am building a LFS (Linux From Scratch, cool stuff by the way.
> www.linuxfromscratch.org) system, and the root file system for that is
> ReiserFS. I had to compile reiserfs into the kernel, of course ( if the
> module is on the disk, and i need the module to access the disk, hmmm ...
> Kernel PANIC! ). Aside from that, the kernel just figures it out, I didn't
> tell it anything about what kind of file system root is on. So hmmm? I
> could reboot, if you would like, and see if I notice anything at boot up that
> might be interesting or helpful (I am writing this message from the machine
> I would need to reboot, so I can't do it right now).
Hmm. I know some parameters can be built into the kernel (such as
bzImage), and rdev works by hexedit of certain bytes. One of those
parameters is major and minor number of the root filesystem (which can
be overridden via command line). Mostly I'm told that it is considered
old and not too good of a style to rely on the kernel bytes for
major/minor of root, that most init scripts pass this information.
Sometimes via a detection routine. What I have not found is a case of
whether the filesystem type is also embedded in the kernel image. It
appears that most likely the filesystem type is embedded (as a default)
along with the root device at the time the kernel is compiled. So if you
were to build on one machine or partition then boot another, you'd need
to either pass parameters or run rdev to hex edit; what I suspect is
that if you were to change filesystem *type* from ReiserFS, it would
panic and be unable to mount, due to not truly detecting partition type,
but I don't know. And if rdev works on major/minor number, I see no
reason why it wouldn't also attempt to get partition type at the same
time. What would be *very* interesting is if you have found a way to
create a rescue disk for your system which will boot with iso9660 as
root? Have you worked on any kind of rescue system? Also, what is the
content of your init file?
One option to building something in is to use a module and create an
initial ramdisk too...the ramdisk (if kernel is compiled with ramdisk
support) is mounted during bootup before any real filesystems are
mounted. I know this is working for me, because the scsi controller is a
module, and I can mount and run fine if I explicitly name an ext2
partition as root. *evil grin*...maybe I'll try formatting a CD as type
ext2! Well, that is kind of a kludge to have to do it that way. And it
would rule out the ability to load XFS as root, so maybe not a good
idea.
Does anyone happen to know if there are bytes in the kernel that I can
alter for filesystem type?
D. Stimits, stimits at idcomm.com
>
> HTH, Tim
>
> --
> ==============================================
> == Timothy Klein || teece at silverklein.net ==
> == ---------------------------------------- ==
> == "Hello, World" 17 Errors, 31 Warnings... ==
> ==============================================
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
More information about the LUG
mailing list