Chapter4 profile

Gerard Beekmans gerard at
Tue Oct 3 11:44:35 PDT 2000


Here we are again, the same chapter4 profile as before. I haven't included 
Jason's fdisk proposals. There are other possibilities which we should 
explore as well. So let me post the profile again and just pay attention to 
the comments in the fdisk section.



<!ENTITY drive "/dev/hda">
<!ENTITY LFS "/mnt/lfs">

<!--		Run fdisk. Only manual mode supported for now
		Also, only one drive is supported. Perhaps we should
		investigate the possibility of using something like
		Disk Druid from redhat. That way we don't have to specify
		drives and partitions in the fdisk tags below. Run the program
		and when the program exists it somehow tells the front-end
		which partitions are meant for what. If we don't it might
		be hard to support LFS on multile partitions. But for now
		we'll assume that one drive is used and LFS will be built
		on one single partition. This needs some more thought. Ideas
		are welcome of course.

		We can assume a poweruser and have the user select, after he
		ran fdisk, which partition is used for LFS and which one for
		swap. Or we can run some detection script/program that lists
		all ext2 partitions and all swap partitions and have the user
		decide which one to use. Then that information must be passed
		along by the front-end to the profiler (the front-end is a
		dumb tool. It does not create new profiles, that's up to the
		profiler who parses the (new) profile and sends it to the
		backend who does all the work. So the profiler translates the
		XML code into stuff that the backend understands (bash script,
		python, C and others).

		But all this stuff is to be discussed on the alfs-ipc
		(interprocess communication) list in due time. So let's not
		worry about that quite yet.




		Now we have to determine what happened during fdisk, ask the
		user which partitions he added are supposed to be used for what,
		and pass that along to the next tool. This could mean that the
		profiler receives the original profile plus some additional
		comments from the front-end and the profiler could add a few
		<!ENTITY> tags to the profile so we would, after fdisk, end up
		with something like:

		<!ENTITY root "/dev/hda1">	<!-- / -->
		<!ENTITY usr "/dev/hda2">	<!-- /usr -->
		<!ENTITY home "/dev/hda3">	<!-- /home -->
		<!ENTITY boot "/dev/hda5">	<!-- /boot -->
		<!ENTITY local "/dev/hda6">	<!-- /usr/local -->
		<!ENTITY swap "/dev/hda7">	<!-- swap -->

		All these partitions must be formatted (unless the use tells it
		not to) so perhaps we should change the variable names into
		something like:

		<!ENTITY partition-root "/dev/hda1">
		<!ENTITY partition-usr "/dev/hda2">

		And so forth. Then we can easily parse the file and have the
		profiler look for partition-* variables and create instructions
		for the backend to do something on those partitions (mke2fs)


		Format the partition (just a single partition for now) 


		And mount it 

	<MountPartition device="&partition;">&LFS;</MountPartition>


		Last part of chapter4, create the directories. We'll use the
		for loop thing for now until we find something better. It should
		not be hard at all to make the profiler understand a for loop
		and work with it.


	<mkdir>bin boot dev dev/pts etc home lib mnt proc root sbin tmp 
	<for var="dirname">$LFS/usr $LFS/usr/local>
			<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>
			<mkdir>dict doc info locale man nls misc terminfo 
			<mkdir>man1 man2 man3 man4 man5 man6 man7 man8</mkdir>

	<mkdir>lock log mail run spool tmp




Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Unsubscribe: send email to alfs-profile-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list