Profile syntax for chapter 4

Jason Gurtz jason at tommyk.com
Wed Sep 27 09:43:22 PDT 2000



> ...We can make fdisk run non-interactive...

I think this is a good idea.  Although things like partition structure are
system dependent it would be nice if the user could insert the required info
in the profile before starting.  This would be especially nice when you have
more than one identical system and you want to quickly get them all up and
running at once.  Don't recall which fdisk is designed for this usage maybe
it was sfdisk.

> <fdisk></fdisk>

Definatly.  Now, all that is used for the actuall building is one partition,
but it would be nice to have the flexability to add partitions at the start,
so that when you're done you can have a seperate /var, /boot, /usr or
whatever.

Another issue:  For standards based systems, i.e. LSB, is there be, or would
there ever be, a spec on partition structure?

Proposal:

<fdisk type="auto" prog="sfdisk">
	<displayVerify output="stdout" /> #could be lp0, etc...
	<device selection="/dev/hda">
		<partition number="1" buildLfsOn="yes">
					/*  ^^^^^^^^^^^^^^^
					 * This will be used later
					 */
			<start block="1" />
			<end block="130" />
			<type="83" />
			<bootable status="yes" />
			<mntpoint="/mnt/lfs" />
		</partition>
		<partition number="2" buildLfsOn="no">
			<start block="131" />
			<end block="138" />
			<type="82" />
			<bootable status="no" />
			<mntpoint="swap" />
		</partition>
	</device>
</fdisk>

I put in the <displayVerify> tag because I feel that this particular
operation is a critical one and ppl should have the chance to revert at last
second to manual mode.

> ...that the user can create a partition.

Ok, if (by default perhaps), fdisk is going to be run manuly then this would
do:

<fdisk type="manual" prog="fdisk">
	<device selection="dev/hda" /> /* Still have to specify
</fdisk>					  * what device. How?
						  */



> The next step is formatting that partition. After fdisk ran the
> user has to
> give input regarding which partition he/she created as linux
> native and swap.
>
> Then the partition needs to be formatted:
> <format_partition>$partition</format_partition>
> So $partition needs to be defined somewhere that contains the
> proper /dev/xxx
> variable.
>
> The book assumes that you will use the swap partition that's
> already in use
> by your normal system. But that might not be the case here anymore, so a
> mkswap like tag should be inserted somewhere at some point but I
> think that
> can wait. Let's do it by-the-book first, but it wouldn't hurt if
> you guys can
> think about it already so it can be dealt with in due time.

If completely auto this info can be parsed from the tags in the fdisk
section above.  Perhaps it would be a good idea to have both partitioning
and formatting be sub-sections, occupying the "disk setup section."

Proposal:

<diskSetup>
	<fdisk>	/* This would require the
	.		 * correct type and
	.		 * buildLfsOn flags be placed
	.		 * in the fdisk section
	</fdisk>	 */
	<format type="auto">
		<displayVerify output="stdout" />
		<selectLfsPartition type="auto />
		<exec prog="mkfs" />
		<selectOtherPartitions type="auto />
		<exec prog="mkfs" />
		<selectSwap type="auto" />
		<exec prog="mkswap" />
	</format>
</diskSetup>

The profiler would have to take care of looping to handle extra partitions
defined in the fdisk section. <exec /> tags will handle possability of devel
of different utilities for other types of partitions/formats


else  #in manual mode

<diskSetup>
	<fdisk>
	.
	.
	.
	</fdisk>
	<format type="manual">  #Default?
		<selectLfsPartition type="ask" />
		<exec prog="mkfs" />
		<selectSwap type="ask" />
		<exec prog="mkswap" />
	</format>
</diskSetup>

>
> The next step is mounting the new partition under /mnt/lfs
>
> Yeah, you can even reverse it: <mount
> target="$LFS">$partition</mount>.

I like this better

> So we
> have to make up a rule is entered as a tag's parameter and what
> is the value
> of a tag (the stuff between <blah></blah>)

Should the profiler keep track of variables such as these.  I mean, we all
ready entered what partition we wanted to use above.


> Creating the directories:
>
> We can throw in a ton of <cd> and <mkdir> tags to get it done. How about a
> similar thing the book does now:
>
> <create-dirs>
> 	<cd>$LFS</cd>
> 	<mkdir>bin boot dev dev/pts etc home lib mnt proc root sbin
> tmp var</mkdir>
> 	<for var="dirname">$LFS/usr $LFS/usr/local>
> 		<do>
> 			<mkdir>$dirname</mkdir>
> 			<cd>$dirname</cd>
> 			<mkdir>bin etc include lib sbin share src
> tmp var</mkdir>
> 			<ln type="symbolic">share/man man</ln>
> 			<ln type="symbolic">share/doc doc</ln>
> 			<ln type="symbolic">share/info info</ln>
> 			<cd>$dirname/share</cd>
> 			<mkdir>dict doc info locale man nls misc
> terminfo zoneinfo</mkdir>
> 			<cd>$dirname/share/man</cd>
> 			<mkdir>man1 man2 man3 man4 man5 man6 man7
> man8</mkdir>
> 		</do>
> 	</for>
> 	<cd>$LFS/var</cd>
> 	<mkdir>lock log mail run spool tmp
> </create-dirs>

I like the idea of grouping under a general "what we are accomplishing tag"
like the <create-dirs> tag.  A better name may be
<createBaseFS></createBaseFS>

I dunno, in cases like this were it is actually a verbatim shell script I
think it would be better to use a <commands shell="bash">....</commands> set
up kinda like <PRE> in HTML

<createBaseFS>
	<commands shell="bash">
 	cd $LFS
	mkdir bin boot dev dev/pts etc home lib mnt proc root sbin tmp var
 	for var="dirname" $LFS/usr $LFS/usr/local
		do
			mkdir $dirname
			cd $dirname
			mkdir bin etc include lib sbin share src tmp var
			ln -s share/man man
			ln -s share/doc doc
			ln -s share/info info
			cd $dirname/share
			mkdir dict doc info locale man nls misc terminfo zoneinfo
			cd $dirname/share/man
			mkdir man1 man2 man3 man4 man5 man6 man7 man8
		done
	<what goes here?> #damn it need to study more shell scripting
	cd $LFS/var
	mkdir lock log mail run spool tmp
</createBaseFS>

>
> That will be it for this thread.

that will be it for this email

~Jason


--
+------------------+
| Jason at tommyk.com |
+------------------+






More information about the alfs-discuss mailing list