Porteus Boot Order

[Ahau]

This article has been moved to the main site, here.

Feel free to continue adding to the discussion in this thread; edits/additions will be made to the version on the website.

Thanks!

[82issa]

The first part of this should look like this.
---------------------------------------------------------------------------------------------------------------------------------
FFPS
This is mad up term for the finger flipping the power swich.

BOOT
The word boot is short for "bootstrap" (itself short for "bootstrap load"). The term bootstrap derives from the idiom pull oneself up by one's bootstraps. It refers to the fact that a computer cannot run without first loading software but must be running before any software can be loaded, which seems as impossible as to "pull yourself up by your own bootstraps." The very first code the bootstrap loader points to is the bios.

THE BIOS
The Basic Input Output System is the fundamental level of firmware interface for your systems hardware/software. It resides on a non-volatile ROM chip which is integrated into the systems mainboard. The present day (2010 AD) bios exists on all 32 bit architecture systems and is fast being replaced by Extensible Firmware Interface (EFI) seen more and more in 64 Bit systems. The POST is one of the many functions of the bios.

POST
The Power On Self Test routines run immediately after power is applied to your computer. It is a pre-boot sequence that sets an initial value for output signals and performs basic checks such as ensuring RAM, disk drives, peripheral devices and other hardware components are properly working before starting the bios points the bootstrap loader to the Master Boot Record (MBR).

MBR
The MBR is typically the first sector ("LBA/absolute sector 0") of a partitioned storage device before the actual partition itself. It holds the disks partition table information and instructions on which partition to boot from. Some disk drives contain their own boot manager which can be stored in this first 512 byte sector and the partition table in this case is moved to another place. After the MBR decides which partition to boot from it hands control over to the 'boot sector' on said partition.

bootLOADER
The bootstrap Loader (bootloader)
The boot sector contains a program that will attempt to read the operating system from the disk and run it. This is called the bootloader and most Linux system bootloaders typically give users a choice of operating systems to run. The important piece of information in the bootloader is the location of the kernel.
-----------------------------------------
From there goto kernel stuff

[Ahau]

I'm bumping this one...I've made edits to the original post to implement fanthom's comments on the order (moving LLS to happen right after Kernel/INITRD), and 82Issa's comment to have BIOS come before POST.

I'd like to fill out more information on Initrd, I still don't understand it very well, and what it does vs what the kernel does

also -- what is the new name for /etc/rc.d/rc.slax?

Any comments or additions (such as password check and creation of save.dat, if those will be in the final release)??

Thanks!!

[82issa]

@Ahau
The kernel handles device/memory management.

The INITRD stands for initial ramdisk. They are built differently from the porteus modules but similar. They cary a simple set of tools for configuring, and loading device drivers, for the kernel. This is useful for when you have harddrive detection problems. You add your ("harddrive-controller.ko" an actual linux module) to your initramdisk so that the kernel can see the harddrive chain. The script for handling the cheatcodes reside in the root of this ramdisk. You can examine this script to see what is going on and understand exactly what each cheatcode executes or not.

Actual linux modules are also known as a device driver. This is very different from porteus module.

There are a couple different kernel panics, classified as hard kernel panic and soft kernel panic. One way to identify a kernel panic. Your computer locks up and the caps lock or numlock key will just flash on your keyboard. Just on and off. Nothing that I know of will force it to be responsive at this point. You need to identify what exactly happens before or directly after what is frozen on the screen when this happens. Then restart and remove one at a time to see if it will make it past that point in the boot.

[Ahau]

Thanks, 82Issa!

I think I'm understanding it a little better after your explanation, and as I read and write about it (here and on the debug HOWTO). It's similar to a save.dat container (or more correctly, a disk image, hehe) that contains the nuts and bolts that your system needs in order to build the rest of the system. In the case of porteus, it's the scripts and tools to construct the live filesystem, mount modules, and chroot everything so that it appears like a real filesystem. This afternoon, I'm going to unpack it (for the first time) and poke around to learn more.

Posted after 2 hours 5 minutes 34 seconds:
Yea, and verily I say unto you, I did peer inside mine initrd, and behold: the mysteries of linux were laid bare before me, and I saw the light.

[82issa]

Now I am sure that koool-aide just tasted soo---- goooood. For those of you who aren't totally sure what to doo here with the initrd to see.

What I recomend doing is decompressing the initrd.xz
This file is located /boot directory

Code: Select all

 xz −−decompress /mnt/sda1/boot/initrd.zx


After it is decompressed you will have just initrd
I just usually mount it.

Code: Select all

mkdir -pv /mnt/initrd
mount -o loop /path/to/decompressed/initrd /mnt/initrd
cd /mnt/initrd


From there you can explore arround that directory structure.
If you are curious how they cram so many cli tools into there. Just go to the /bin directory you know /mnt/initrd/bin. And issue the following command.

Code: Select all

ls -l


Note that switch is a minus lowercase 'L' This will show you that most of these utilities are symlinked to /bin/buisybox . I think I got the filename wrong for the symlink I am just working from 'brain ram' it is cluttered with whole bunch of other things. But you can do the research and have fun with that. Building an initrd is a little more complex than viewing what is in it.

Posted after 9 minutes 48 seconds:
It actually pivots_root not chroot. That is when the initrd is finished, and returns controll to the kernel to continue booting. The first thing executed is the /linuxrc script inside the initrd. That uses the tools which reside inside the initrd directory structure. I have heard of some projects that were trying to squeeze as much into the initrd. Making a fast booting system. Because there was no use for any other root in these projects. Their root was the initrd.

[brokenman]

When i posted that Ahau, i got the order slightly mixed up, but it was corrected (by fanthom) a little further down the thread, but i never got around to editing the original. I see you're right onto that.

Some great info there 82issa

The initrd is in fact very similar to other Linux distros, albeit a little modified by fanthom.

The script for handling the cheatcodes reside in the root of this ramdisk.
May want to double check this as linuxrc handles cheatcodes.

The rc.slax was removed and it's contents placed at the end of rc.M

[82issa]

/linuxrc is a script I just couldn't remember the name off the top of my head when I had made that previous
post, and it does reside at the root of the initial ram disk. Go ahead and open it up with your favorite text
editor. I didn't really mess arround with slax before I migrated here. rc.slax (shrug) means very little to me.
You might be referencing something completely different than what I was addressing.

[brokenman]

Yes, you are 100% fundamentally absolutely correct! And have a firm grasp on the inner workings of linux i might add.

** Spoken in a gruff Yoda voice **
The force, strong it is, in this one.

The slax.rc comment was answering Ahau's question. The good news is don't need to know about because it's gone.

[Ahau]

Thanks, all, for the information and tutelage! I'll get this cleaned up a bit and posted to the main site in due time.

Posted after 5 days 7 hours 15 minutes 24 seconds:
I've gone through the porteus linuxrc, rc.S, and rc.M and made some modifications to the above. I get the sinking feeling that I got a few things wrong in linuxrc (I may have left some things in that are not in the porteus version), and I think I may have left some stuff out of rc.S. However, it should still serve to give users a good idea of the process involved. I'll get this up on the main site. Corrections and suggestions are still very much accepted

[fondfire]

Is there any way the following could be added back to the /etc/rc.d/rc.S file?

Code: Select all


# Run SystemV init scripts.
[ -x /etc/rc.d/rc.sysvinit ] && . /etc/rc.d/rc.sysvinit

One way I've used Slax in the past is to develop some relatively easy-to-maintain, home-grown Linux appliances at my workplace. I had supplementary modules that included boot modifications realized in /etc/rc.d/rcS.d, as well as /etc/rc.d/rc3.d. One of the reasons I really liked doing it this way is that my home-grown modules generally didn't require heavy modification when Slax was upgraded and I never had to alter the core modules of the Slax system, which I find makes upgrading the appliances a lot harder.

Is there any huge reason why this can't be done in future versions of Porteus? (My guess might be due to boot-time. Is that really slowed if /etc/rc.d/rcS.d isn't even present, though?) I suppose I can place an alternate version of etc/rc.d/rc.S in the boot-drive's /rootcopy directory and periodically compare it to /mnt/live/memory/images/*/etc/rc.d/rc.S to make updates... Still, I thought I'd ask, as I hate to overwrite anything in core modules when it's not strictly necessary. (One of the things I was doing with scripts in /etc/rc.d/rcS.d was applying patches to init scripts I wanted to alter, so as to avoid making changes to core modules.)

Thanks.

--fondfire

[fanthom]

@fondfire
welcome on board.

Yep - sysvinit scripts can be also run in runlevel 1. one extra check wont slow booting of the system that much. will be added for next release - thanks for pointing this out.
just for my curiosity - what actions are your scripts doing before entering runlevel 3?

btw: i'm going to drop support for cryptsetup volumes from rc.S in first -rc of Porteus-1.1. i dont think anybody is using it and cryptserup is not even a part of the official ISO. if users starts complaining i'll bring it back.

Cheers

[fondfire]

Thanks!

Mostly, I was using it as a way to modify other start-up files in /etc/rc.d before the later boot-levels started. Perhaps it would make more sense to simply create new versions of the script and let a new module (or rootcopy) overwrite the script, but in many cases I was applying a source-patch to the scripts in rc.S so that slight changes (like bugfixes) to Porteus boot scripts would not be overwritten by my own (possibly inferior) scripts. I also made a bunch of changes to configuration files using patches before the services using them started-up.

I'm creating an appliance that uses IBM's NIM-on-Linux (AKA NIMOL) to make the back-up and restore of my employer's AIX systems easier. If I place porteus on the first partition of each of a handful of large USB boot drives, encrypt the next (much larger) partition, and copy my back-ups to the encrypted portion, I have a highly portable series of restore devices that can be booted on a lot of common hardware. Porteus boots on a lot of more recent systems that Slax cannot boot, so I'm trying to convert my devices to Porteus. By making a module with my modifications that don't change or overwrite the files of the core modules, I found I could make an "embedded" O/S for these USB restore drives that would be relatively easy to maintain for my purposes.

If I ever get this thing properly documented, I'll try to post it to my blog and link the post on the forum. I need a few modules outside the core and I created a module of IBMs NIMOL scripts. Unfortunately, I cannot repost the NIMOL script module, as NIMOL is a propietary part of AIX, but I can post how I created that module, as well, and anyone with an AIX CD should be able to do it, too.

Thanks again!

--fondfire

[fanthom]

If I ever get this thing properly documented, I'll try to post it to my blog and link the post on the forum.

Nice - waiting on your HOWTO