You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm going to use this gist as a scratch pad for ideas for continuing GoboLinux. Feel free to add ideas, questions, quandaries, etc. -fowl
Come lurk in IRC at irc.freenode.net #gobolinux
The Process
This should get you to a 014.10 system from 014.01 in the safest way possible.
This guide was written in mind from a fresh 014.01 minimal install, but you should be
able to upgrade safely if you have the time and don't mind uprooting all of your software.. Be warned spooky ghost noises
After Scripts is updated run UpdateSettings Scripts to get 2.10.2, just use all new settings.
Then edit /System/Settings/Scripts/GetAvailable.conf to add
'http://mwh.geek.nz/files/gobo/014.10/packages/MANIFEST.bz2' above the official package lists
already in there. Put the gytha.org mirror in here if it isn't already.
InstallPackage Compile
InstallPackage Linux
It is recommended that you install Glibc separately from the new kernel
InstallPackage -s remove Glibc 2.14
InstallPackage GCC
You might need to install GMP 4.2.2 to be able to compile
`InstallPackage GMP 4.2.2`
`SymlinkProgram GMP 5.0.2`
#make sure both of these are in place
`ls /lib/libgmp.so.10`
`ls /lib/libgmp.so.3`
InstallPackage Python 2.7.2
Old OpenSSL is incompatible with the newer Python, so if you have a problems right
after Python installs, please do
Udev is important to update now before you attempt to reboot into the new kernel. It brings
a lot of important things like Glibc, GCC, USBUtils, Python, etc with it.
** what other packages or settings are essential here to not cause headaches?
From here you can continue with Openbox, Fluxbox, etc. See https://gist.github.com/1190590 for a list of packages ready for the new system.
Note that [GOOD] does not mean working these packages still need to go through some testing
About PAM and Shadow
<mwh> when you do pam and shadow, try putting this into system-auth: http://mwh.geek.nz/files/gobo/014.10/system-auth
<mwh> and no other changes
<mwh> and see whether passwd works
<mwh> and login
<mwh> have a root shell open
<mwh> you can just run login from the root shell, in fact
Come to irc://irc.freenode.net/gobolinux for support, ideas, complaints, subpoenas, etc
Aftermath
This is the order in which I'm updating my system, and any notes
InstallPackage Subversion
Compile BuildLiveCD
InstallPackage SquashFS-Tools For LiveCD Mastering
InstallPackage Sudo Optional. The new Sudo requires Linux-PAM
Priorities
Get an updated livecd out, doesn't have to be anything special, just update the base system inc. the installer, kernel, udev alternatives?
Update Kernel DONE
GoboHide
Update GCC, Glibc DONE
HAL is outdated now
The Future
64 bit support out of the box would be nice :)
Updating to Python 3.0 the following need to be updated also
The Installer
AbsTK (used in the installer)
Aliens (part of Scripts)
Outdated
Upgrade to latest glibc on gobolinux. Don't use mwh's repo for this your system will break.
This is a quick guide to the internals of how the GoboLinux Live CD is constructed. It will get you up to speed with the tools that build the CD, allowing you to make customizations. With this we hope to lower the entry barrier to potential contributors to the distro's development.
Prerequisites
This tutorial assumes you're running a GoboLinux system, with the most recent version of the Scripts package installed. Your kernel needs to support UnionFS, SquashFS and CramFS. You also need the SquashFS-Tools installed. All of this is available from the GoboLinux repositories.
This tutorial assumes all steps are performed with superuser privileges
(become superuser with su or use sudo). This is because the tools need to
create device nodes, unpack files keeping privileges and suid bits and perform
mounts using UnionFS. As usual, care must be taken when performing tasks as
superuser, when running pre-release software downloaded through SVN and
especially, when doing both, as it's the case here. Proceed at your own risk.
The tools
To get started, you need to install the BuildLiveCD package. You can install it by typing:
Compile buildlivecd
A number of other GoboLinux tools and packages will be involved in the process of building the CD, but this is the only one you need to install in your /Programs directory. We'll get to them in detail one by one, but here's an overview:
InitRDScripts - this is the "Scripts" package for the mini-GoboLinux environment in which the CD kernel is loaded
LiveCD - scripts that are specific to the Live CD environment, having to do mostly with its initialization.
ConfigTools - some scripts that tweak configuration files to match the system where they're running.
Installer - the actual installation program, that copies the contents of the CD to the hard disc
AbsTK - Abstract Tool Kit: the interface abstraction library that allows the Installer to have both text-mode and graphic interfaces.
The CD mastering environment
Once you have BuildLiveCD installed in your system, you can set up the CD mastering environment. A single command creates the necessary directories and downloads all needed packages: UpdateEnvironment. Run it in an empty directory; in our examples we'll use /Depot/LiveCD.
mkdir /Depot/LiveCD
cd /Depot/LiveCD
UpdateEnvironment
Note that this will download hundreds of megabytes worth of packages, so this may take a while.
For GoboLinux devs: This script downloads some files from SVN and stores a local copy of the SVN repository under LocalSVN/. To ease development, you may want to have a copy with write access enabled, instead of the default anonymous SVN copy. To do this, pass your Savannah username as an additional parameter to UpdateEnvironment.
UpdateEnvironment hisham
If your username in the local machine is not the same as your Savannah username, you can pass it as a second parameter (since you're running as superuser, the script will "sudo" to your user account when running svn).
Building the CD
The whole process of building the CD is wrapped by the CompressAndBuildISO script. In your first run, you can simply call it with no parameters and it will go through the whole process:
CompressAndBuildISO
The script is composed of a few stages -- when you make a modification that affects only one of the later stages, you can pass a parameter to have it skip the earlier ones, in order to save time. The stages are:
rolayer - Constructs the directory tree with the contents of the LiveCD: uncompresses packages building a /Programs tree, files into /Files, and generates a /System directory with the necessary symbolic links and system files.
squashfs - Compresses this newly-constructed system into several SquashFS images: one for /Files, a few ones for sections of the big /Programs tree, and one for the rest (/System, /Mount, /Users...). This is done so that modifications on part of the filesystem do not trigger a full regeneration of the entire system's "squashed image" (a process which takes several minutes even on a 2+GHz machine).
initrd - Because the actual system is stored in the CD in a compressed format, its contents cannot be directly accessed by the disc bootloader. The bootloader launches instead an InitRD ("initial RAM-disk") image, a mini-GoboLinux system that serves the sole purpose of hosting the kernel, mounting the SquashFS system, and booting into it. This step of CompressAndBuildISO creates the CramFS image of this mini-GoboLinux to be used as the InitRD.
iso - In the final step, the ISO 9960 file system is generated, containing the bootloader, the kernel, the InitRD image and the SquashFS files.
A walkthrough of the Live CD boot process
The CD bootloader
To be written
The InitRD environment
To be completed
The InitRD environment is a mini-GoboLinux system created by the MakeInitRDTree script, which was called when you run CompressAndBuildISO. You will find it at the Output/InitRD directory.
Do not modify Output/InitRD directly: its contents are rewritten when CompressAndBuildISO runs through the initrd step. To tweak the InitRD scripts, modify instead the local SVN copy of InitRDScripts, located at LocalSVN/tools/InitRDScripts.
Currently, this part of the build environment is not very friendly to customized versions. If you want to keep a custom version of the InitRD, you need to replace LocalSVN/InitRD with your own copy after running UpdateEnvironment.
For GoboLinux devs: To have your changes done permanently, there are a
few different places where they may need to be applied:
Changes to /Programs/InitRDScripts should be comitted to the GoboLinux SVN.
If your LocalSVN/ copy was created with write access, it's only a matter of
running svn commit.
Other entries in /Programs are fetched from the initrd-packages/ repository
(see the MakeInitRDTree script for details).
The directory structure and other configuration files are generated by
MakeInitRDTree, so if you change that, modify it accordingly so that a
clean rebuild creates the files and structure as you intend it.
At the end of the startGoboLinux script of the InitRDScripts package, the SquashFS images are mounted, the pivot operation to make it the root directory is performed and init is called to proceed with the boot process.
Inside SquashFS
From there on, we're inside a GoboLinux system very much like the one that's installed in the hard disk. In fact, the same packages are used. When init runs, it calls the BootDriver from the BootScripts package. The BootDriver detects it is running from the Live CD, so instead of running its usual bootscripts, it calls the StartLiveCD script from the LiveCD package. That script is responsible for the rest of the initialization.
The SquashFS structure
The main LiveCD environment (i.e., the directory tree you see once the LiveCD booted) is stored as a series of SquashFS images. These images are built from two layers: one read-only layer that is the actual filesystem, (Programs, Files, System, etc.), and a read-write layer that sits on top for debugging purposes, containing assorted files that you may have created while logged in using ChrootEnvironment.
The main, first layer is generated at Output/ROLayer. This is built out of packages listed in Archives/Packages that are combined to build /Programs, additional files under Archives/Ext that are unpacked to their proper locations, plus a series of files and directories that are generated on-the-fly by the BuildRoot script. BuildRoot is called by CompressAndBuildISO during the rolayer step.
Keep in mind that when you make modifications that alter the LiveCD environment itself, you need to regenerate the SquashFS image. To do this, pass an additional parameter to CompressAndBuildISO:
CompressAndBuildISO squashfs
For GoboLinux devs: To have your changes done permanently, you need
to consult your changes in the Output/RWLayer and apply them to the
relevant recipes which will generate new packages.
The package set for the CD is currently at the livecd-packages
repository (see UpdateEnvironment for details). When modifying the
package set, you also need to update the
/Programs/BuildLiveCD/Current/Data/Packages-List-* files.
After modifying packages, a full rebuild starting from rolayer is needed to keep
your Output directory in sync with the package repository:
I think it will run smooth in a raw 014.01 install or in a heavily update one. Just a side note, I'm run this tutorial with Scripts 2.10.2 and Compile 1.13.3.
Prerequisites
Before anything, I advise you to create a GPG key to sign packages:
gpg --gen-key
After the first thing, you should know that as today (2010-06-05) the latest Linux kernel recipe (2.6.32.3) are compatible only with SquashFS 4.0. So we will need to update the SquashFS-Tools program and the follow command should do the trick:
Compile SquashFS-Tools 4.0
Then you should compile and pack a update Linux kernel, this step should take a long time to finish:
mkdir -p ~/014.01+ && cd ~/014.01+
Compile Linux 2.6.32.3
CreatePackage Linux 2.6.32.3
Setup
Now that we have the prerequisites satisfied, lets follow the original tutorial:
Well, today BuildLiveCD is very different from 2 years ago. This recipe just apply some patchs that fix BuildLiveCD, as it was in 2008-03-31, to run appropriately with a new kernel, fetch files correctly, and remove OpenOffice from the ISO due it's size.
mkdir /Depot/LiveCD
cd /Depot/LiveCD
UpdateEnvironment
I setup UpdateEnvironment to fetch files from gytha.org::gobolinux-packages/014/livecd/ using rsync because it's the only 014.01 original files mirror that I found. In case of this mirror isn't working, I setup another one and you can get these files from there:
I think it will run smooth in a raw 014.01 install or in a heavily update one. Just a side note, I'm run this tutorial with Scripts 2.10.2 and Compile 1.13.3.
Prerequisites
Before anything, I advise you to create a GPG key to sign packages:
gpg --gen-key
After the first thing, you should know that as today (2010-06-05) the latest Linux kernel recipe (2.6.32.3) are compatible only with SquashFS 4.0. So we will need to update the SquashFS-Tools program and the follow command should do the trick:
Compile SquashFS-Tools 4.0
Then you should compile and pack a update Linux kernel, this step should take a long time to finish:
mkdir -p ~/014.01+ && cd ~/014.01+
Compile Linux 2.6.32.3
CreatePackage Linux 2.6.32.3
Setup
Now that we have the prerequisites satisfied, lets follow the original tutorial:
Well, today BuildLiveCD is very different from 2 years ago. This recipe just apply some patchs that fix BuildLiveCD, as it was in 2008-03-31, to run appropriately with a new kernel, fetch files correctly, and remove OpenOffice from the ISO due it's size.
mkdir /Depot/LiveCD
cd /Depot/LiveCD
UpdateEnvironment
I setup UpdateEnvironment to fetch files from gytha.org::gobolinux-packages/014/livecd/ using rsync because it's the only 014.01 original files mirror that I found. In case of this mirror isn't working, I setup another one and you can get these files from there:
For the obvious reasons, I have been a GoboLinux user since release 014.01 and am patiently waiting for its next release 015. It seems the official version of GoboLinux 015 is dormant [http://lists.gobolinux.org//pipermail/gobolinux-users/2011-April/008635.html] for the foreseeable future.
Yesterday, I read the irc.freenode.net #gobolinux transcript [http://technoninja.blogspot.com/2011/07/120026-am-topic-for-gobolinux-is-latest.html] and also learnt about the Ruby Build Tools [https://github.com/shevegen/ruby-build-tools] that have adopted the KISS principle, and was instantly struck by their potential application. Definitely impressive and remarkable achievement!
To build and load software into a “GoboLinux file system” by either “CompileProgram (recipe name)” [from source] or “InstallProgram (package name)” [from binary] formats [www.ruby-forum.com/topic/2104402] could be achieved relatively easily if coupled with an established distribution.
Thus, to ensure “GoboLinux 2” has project long-levity, up-to-date software, and captive audience, it should be built upon the strengths of Linux From Scratch (LFS) and Beyond Linux From Scratch (BLFS) foundations.
Hence, it is essential to publish a supplementary guide/manual with step by step instructions (from start to finish it should be a list of commands to copy and paste for the benefit of new users to follow) of how to build a basic (core) version of the "GoboLinux File System" using the LFS/BLFS books and implementing the Ruby Build Tools.
Moreover, adapt/modify GoboLinux Manager (graphical user interface) [www.gobolinux.org/index.php?page=manager] to work with the Ruby Build Tools, and also incorporate an additional function to check and delete orphan dependency programs that are left behind after “Remove program” option is used.
If you release a version of GoboLinux 2, I am definitely more than willing to give it a try. In the meantime, I wish you all the best.
"For the archives, here are instructions for getting a working system from the 014.01 base, as written by a new user on IRC a couple of months ago: http://pastebin.com/FyJSgLGZ …
I am the original author of the RBT project. Fowl is my first user and eventually the
second developer if he so desires to and sticks around (and is patient lol). But he
complains about a few things within RBT, so I have to change that first. Which will
take a while. :)
I've been using GoboLinux in about 2004 or 2005 first and fell in love with it.
Of course as time passed by, hisham, andre and lucas no longer had the amount of
time required to maintain a whole distribution on their own. It's a lot of work
to do so. Past the student life, I don't think many could afford to commit a
lot of time to such a project.
One goal, a major one actually, for RBT is to be able to do what all the Gobolinux
scripts can do. Why? Well, because I started with RBT because of Gobolinux actually!
I couldn't understand the shell scripts, so I set out to try the things the
Goboscripts do.
Right now I am building a LFS again, but I ran into problems before and failed hehe...
I should really stick to the book ...
As for Manager, I should be able to do it in ruby-gtk as well, although it may
not look as pretty as Andre's Manager. But then again, if it works, it's alright
and can be made prettier at a later time anyway.
I am really delighted to read that you are building a basic (core) version of the “GoboLinux File System” using the LFS/BLFS books to the point when the RBT can be used for subsequent software installation.
Please do keep a detailed record of "all the steps" taken in the process from the “beginning” with the LFS/BLFS books to the “end” with the installation of the RBT. I can then attempt to duplicate the exercise following your instructions, and if successful they could be published to encourage other new users to try.
One of the joys using GoboLinux was the Manager. With it I was able to keep track of all the installed and available versions of programs at my disposal. As mentioned above, there is no function to find orphan dependency programs that are left behind after the “Remove program” option is used. Nevertheless, it is essential to have a “Graphical Package Manager” of a kind which has become the norm to be expected by new users.
I acknowledge the dedication of both you and Fowl for enhancing and promoting the “ideal operating system”.
For the obvious reasons, I have been a GoboLinux user since release 014.01 and am patiently waiting for its next release 015. It seems the official version of GoboLinux 015 is dormant [http://lists.gobolinux.org//pipermail/gobolinux-users/2011-April/008635.html] for the foreseeable future.
Yesterday, I read the irc.freenode.net #gobolinux transcript [http://technoninja.blogspot.com/2011/07/120026-am-topic-for-gobolinux-is-latest.html] and also learnt about the Ruby Build Tools [https://github.com/shevegen/ruby-build-tools] that have adopted the KISS principle, and was instantly struck by their potential application. Definitely impressive and remarkable achievement!
To build and load software into a “GoboLinux file system” by either “CompileProgram (recipe name)” [from source] or “InstallProgram (package name)” [from binary] formats [www.ruby-forum.com/topic/2104402] could be achieved relatively easily if coupled with an established distribution.
Thus, to ensure “GoboLinux 2” has project long-levity, up-to-date software, and captive audience, it should be built upon the strengths of Linux From Scratch (LFS) and Beyond Linux From Scratch (BLFS) foundations.
Hence, it is essential to publish a supplementary guide/manual with step by step instructions (from start to finish it should be a list of commands to copy and paste for the benefit of new users to follow) of how to build a basic (core) version of the "GoboLinux File System" using the LFS/BLFS books and implementing the Ruby Build Tools.
Moreover, adapt/modify GoboLinux Manager (graphical user interface) [www.gobolinux.org/index.php?page=manager] to work with the Ruby Build Tools, and also incorporate an additional function to check and delete orphan dependency programs that are left behind after “Remove program” option is used.
If you release a version of GoboLinux 2, I am definitely more than willing to give it a try. In the meantime, I wish you all the best.