Hello,

have some general inquiries ...

i've been reading "Understanding the Linux Kernel" and now i'm reading "Linux in a Nutshell" as i'm attempting to build my own distro.

btw i'm trying to avoid redundancies so i'm not interested in reading another book which contains the same stuff or only a slightly modified narration of it.

i've also heard about LFS so which one of those 2 series of books (the oreilley series or the LFS series) is better or more upto date regarding distro development?

also what is the best environment to develop/boot/run your own kernel/distro?

choose one of the following options:

1) real bootstrap using LILO or GRUB
2) inside a para-virtual box (i.e xen )
3) inside a full virtual box (i.e emulator such as virtual box or bochs)

i'm thinking about option 3 because i wanna develop a distro with a full fledged bootloader (i want to simulate the bootstrapping phase as well) and fancy capabilities to scan the partition tables to find existing OSes and stuff like that...

anyways , if you've better ideas then i'm all ears

cheers

If you want to build your own distro from scratch, I suggest designing a solid package building system first. I mean not a package _SYSTEM_, a package _BUILDING SYSTEM_. Do not build a distro by compiling software yourself, it's useless! When a new version of that package arrives, you have to update it. By hand. Again. And you are never going to keep up or do anything useful. For educational purposes, certainly, but if you want to do something serious, nope. I am currently maintaining a distribution and building/updating packages is my biggest time-waster, so I am trying to re-engineer the building system to be more automatized.

If you would like building a distro for educational purposes, use full-virtualization, like Virtualbox. In my experience, it's the easiest.

I'm going for my favourite answer...it depends.

The LFS book, which I think is really great and everyone should read, is focussed on building your own distro. So, if you just want to build your own distro, then I think it is highly recommended, but... If you are only building your own distro, in order to learn about linux more widely, then there is a strong case for reading more general books, like the O'Reilly ones.

So, which is it, are you building your own distro to learn Linux or are you learning Linux to build your own distro?

2Ivshti too many packets to maintain? Use community such as launchpad or own distro community people that for some reason use svn software version and actually can tell when they hit stable point. Actually i use alot of software from svn and usually in hard cases i just make scripts to compile and then rarely update them(but sometimes like moblin it's insane to compile some software(monodevelop in my case) due to distro package tools (>~100 libs by hand doooh)..).

Well thanks i'm definitely gonna take your advice into consideration
so it's says that your distro is "linvo" is that your own distro that you're working ? btw have you found a solution to this problem? (i mean the package building system) ?

yeah i was thinking about using Virtualbox , last year (in an unrelated adventure) i've used bochs when i wrote an experimental bootloader (actually was more like a hello-world OS) , bochs was definitely power but annoying in many regards...etc

that's a hard question to answer , i'd both ...
i'm building my kernel/distro in order to learn about OS design in general (in particular i'm interested of course in linux) as well i'm looking to harness this knowledge in coming up with a production grade distro for my own work (which is related to embedded computing) and also to use as my next Desktop System (because i'm tired of SuSe)..

i dunnu maybe i'm just crazy but i enjoy compiling stuff ... LOL ...at least for now , but i guess when i get tired of this i will most likely resort to automation via scripts , the thing is however how can we automate something if the compile options in newer versions of the software begin to change ?

cheers

Yeah, but it's still to complicated compared to the simplicity of the process.

It is. Well, no distribution actually has, I mean, all distributions require manual package updating. And you can not make the process 100% automatic. I am currently writing a system which monitors a package entry for it's version, and if it differs from the one in the repository, rebuilds it automatically without a build script (most packages use similar building systems).
The current version can be obtained watching a ftp directory in which the package is uploading, or using an regex on an HTML page (the webpage of the project), or so on. Most packages can be rebuild without build scripts using src2pkg, and the ones that will need more tempering are built using scripts. Even if this system is perfect, the process will still need observation and will fail sometimes - but it takes the pressure off.

In Ubuntu, packages are watched and updated by the community using launchpad. I do not wish to criticize but sometimes certain packages get patched with faulty (and a lot of) patches.

Arch Linux also uses a community-maintained repository (plus a developer-maintained one) which consists of PKGBUILD scripts.

In conclusion, in maintaining a distribution, most of the work falls to building software rather than implementing new ideas - although that is included too.
Another conclusion is that it's not worth it to maintain a distribution if you don't:
A) have specific ideas
B) do it for educational purposes

aha , that's interesting new knowledge to me.

btw , i've just successfully booted into my first self compiled kernel 2.6.39.2 (although i gotta admit that i've used the kernelinstall script of my current distro opensuse to actually install , but nonetheless for a kickstart ... it booted quite good except for some error , actually it loaded just like opensuse but with the new kernel and without a couple of missing modules and drivers and stuff...etc)
next i'll try to install the kernel manually ... let's see.

i digress,

well at the beginning you said that i should design a solid package building system first , isn't it possible to design that system later on in a more advanced stage?
you also mentioned that you use an ftp daemon to check on new updates or use a crawler executed by a cron job (i presume) well isn't configuring the ftp/http crawler for each single source tarball even more time consuming than the act of compiling this yourself?

on another issue, what about security ? in particular regarding signature verification of packages and similar related tasks ?
how can someone verify all those packages to have originated from the authors rather than being forged by a man-in-the-middle attack ?

cheers

Great! If you want to learn about the next stage of the boot, explore the init daemon and it's scripts.

Of course you can.

I've done some research, and I think this crawler can be fairly universal. It's gonna need a little configuration, and that's going to be done only once, so it's better than manually compiling. Still, it's an experimental idea of mine and I have not seen it in action yet. Even without the crawler, in Linvo, the goal is to use src2pkg for building packages, thus removing the need of build scripts or even manual building (as it's in your case). You should try src2pkg, it works very well for all the packages which do not require unusual tweaking.

I don't think that will be an issue when using official sources. The possibility exists, but I don't find it serious. Anyway, one can always implement security checks.

well yeah i'll do btw i do have some experience with setting up init scripts because i've been admining a web server which required me to setup similar scripts .

what do you mean with "build scripts" ? are referring to the autoconf produced scripts via "./configure" ?

and on another issue , which scripting language do you think is best suited for distro development?
bash , perl , python or perhaps php ?
i've always wondered why most scripts are in bash although more powerful scripting interpreters are available ...

cheers

try checkinstall too )

No, I mean the scripts that are used to uncompress and de-archive the source tarball, run the build routines (for example the ./configure routine, but there are other similar systems available), install this piece of software into an empty directory, and create a package out of this directory with package meta information (for example description, etc. ) and install scripts (scripts which are to run after the installation of the package) if this is necessary. This "build script" can also be used to patch the source, or to pass advanced options to "./configure". You can see a sample build script (from slackware) here:
http://slackbuilds.org/slackbuilds/1...bmm.SlackBuild
A more advanced one here:
https://github.com/PhantomX/slackbui...bmm.SlackBuild
And an Arch PKGBUILD here:
http://projects.archlinux.org/svntog...trunk/PKGBUILD
The last one is not a script you run directly, but through a helper system.

btw i came across something called a ramdisk when compiling/booting my kernel ?

why is that needed?

i understand that a ramdisk is a virtual hdd/block device located on ram , but i can't connect the dots and why that is related to the linux boot process.

any help?

cheers

The RAM-disk is only needed when you have a fully modularized kernel that has to work on different hardware. It contains drivers for the storage controllers and file-systems that are needed.
Since I know my hardware (when developing a distro you don't know the hardware of the people that install your distro) I don't need one, I always compile my kernels with the needed drivers compiled into the kernel.

alright , so is this ramdisk the file named initrdxx in the /boot folder?
if so how come that "Understanding the Linux Kernel" didn't mention that ? or did i miss it somewhere?

eitherway since which kernel version is this ramdisk available ? and how does the kernel know to use a ramdisk or not and which one?
is this related to depmod or any other userspace utility ?

cheers

Yes.

I haven't read that book, but as said above, a initrd is not necessary for a functioning kernel, I don't use one, for example.

All kernel versions, AFAIK, can use a initrd if you have that feature enabled while compiling the kernel.

It is the job of the bootloader to load the initrd if one is given in its configuration file.

I don't know if that is related to depmod, but you should have a look at mkinitrd. But I don't know if that tool is distro specific.

1 members found this post helpful.