Jackass! 2005.0 Support Group

[obsidianblackhawk]

[Bob P]

probably not, as Athlon-XP may contain CPU instructions that his box cannot process. the only way it could possibly work is if the t-Bird supports the entire instruction set that is present in the Athlon-XP, and i cannot guarantee that that is the case. you absolutely MUST check the cpu flags.

as a rule, if you want compatability, you have to work with software for the OLDER/legacy hardware from a common ancestral base. you cannot use sofwware designed for NEWER hardware that has newly introduced instruction sets!

[obsidianblackhawk]

[SuperYak]

[rbiswarup]

Is it possible to install the iso image contents to a hard drive partition and install Jackass! booting from this partition? I don't have a cd-burner but would like to have Jackass! anyway.

[Bob P]

[Bob P]

[SuperYak]

Thanks anyways Bob...I will just do the Stage 1/3 install on my Duron boxes.

I also wanted to make you aware of what I think is a minor bug your jackass installation documentation. I followed the instructions step-by-step, except for doing an "emerge sync" prior to emerging gentoo-sources. On page 14, Section 9.2 Networking, it appears that it is still necessary to edit /etc/hostname. I did set /etc/conf.d/hostname, but on first boot my system complained that no hostname was found in /etc/hostname, so it reverted back to localhost. Doesn't baselayout determine which is to be used? My version of baselayout is 1.9.4-r6. I may be totally wrong here but I think the later versions (currently masked) of baselayout require the /etc/conf.d/hostname & /etc/conf.d/domainname scripts to be set.

Adding the hostname to /etc/hostname fixed it in this case.

[96140]

The old version of the install PDF--from April 26 or 28 or so, had both the "deprecated" (/etc/hostname" and "current" (/etc/conf.d/) methods listed.

Bob, it might not be a bad idea to go ahead and reference the old way that is still in the actual Gentoo handbook, despite the fact that with 2005.0 using /etc/conf.d/ is supposed to be the "preferred" way of storing hostname information in one's Gentoo system.

I know that I've never been able to have a working hostname without using /etc/hosts, regardless of the method of install.

Also, I do have a copy of the old PDF guide used just during testing, if you need one and think it's worth adding the other hostname method.

[SuperYak]

[Bob P]

the jackass documentation refers to setting the hostname and domainname using the recommended methods for the baselayout that's included in the jackass tarballs. i've never been able to get the hostname/domainname not to work following the method in the jackass! manual. perhaps some of the readers don't appreciate that you have do manually edit the files using nano or vim or some other text editor, and the cat command is just used to show the contents of existing files by typing their contents to the screen. when i wrote the documentation, i have to admit that i make the assumption that everyone knows how to use at least one of the linux text editors.

its interesting that you mention editing the docs -- i did that today, to remove the last remnants of the references to the old way of doing things. so nightmorph, it seems tthat i'm taking things in the opposite direction from what you've suggested by removing the final remnants of the old way of doing things, rather than putting them back.

[96140]

eh.

what I meant was that even when I follow the Guide's direction to only edit /etc/conf.d/hostname, the hostname would not show up; I had to also do echo **hostname** > /etc/hostname in addition to editing the conf.d hostname file. It's an odd kludge, but writing to both files was the only way to get my hostname properly specified.

So yes, it is the old way. But if users are having trouble getting their hostnames to work, perhaps this is the Gentoo baselayout's fault, and they should know about the ol' "echo **** > /etc/hostname" trick.

[Bob P]

Tarballs? Well, there are two ways to look at this:

OPEN SOURCE and FREEDOM of CHOICE

I think that we still have some loose ends to tie up related to the open source nature of the project. ie:, We need to post the specfiles for how the bootable install CD was built, including all of the components that went into the CD. Technically, this means that we need to create a "resources" page that contains the catalyst specfiles, the tarballs, the motd and isolinux files, etc. Once we do that, the tarballs will be available to anyone who wants them.

So i don't have any problems with releasing the tarballs themselves, in the context of the resources page. But for users who want to install from the tarballs instead of the ISO, there are a few caveats that need to be addressed:


DESIGN of a FAULT-TOLERANT SYSTEM

Jackass! was designed to be a fault-tolerant system. My objectives in designing it the way that I did was to look at the way that Gentoo is designed, and to "fix" what I considered to be some of the "defects" in the way that the system was designed from a fault-tolerance perspective. I've always considered Gentoo to be a distro for experts. When you know how to build a Gentoo system properly, the result is a rock-solid system that works the way that it is supposed to work. The process of installing Gentoo properly, though, is very complex, and it leaves the user subject to many opportunites to make errors during the system build that could result in a system that malfunctions and whose reason for malfunctioning can be very difficult to elucidate -- espeically for non-expert class users.

I had considered that there might be a better way to design a Gentoo installation in order to make it more fault-tolerant. The idea was that if the user could be prevented from making the most common installation errors, the installation process could be simplified and the result would be an exceptionally stable and reliable system.

After supporting a large number of installs in the Stage 1/3 Guide, it became evident to me that Gentoo does indeed work properly if you configure it properly, but Gentoo's weakest point is that it is exceptionally fault-intolerant -- if you make even a single mistake when configuring the system for a toolkit rebuild, for example, catastrophic consequences may result.

Being a specialist in the design of fault-tolerant systems, I thought that i could share some of my expertise in this area with the Gentoo community and develop a more reliable Gentoo package. So as you can see, the Jackass! Project isn't really about something as simple as just taking a Stage 1/3 install and "canning" it -- its about providing a more fault-tolerant way to distribute a Gentoo installation.

So what are some of the fault-tolerance objectives that Jackass! tries to offer as improvements?

In supporting the Stage 1/3 Installation Method, it became clear to me that the vast majority of users were making one of four mistakes when building their Gentoo boxes:

1) choosing the wrong tarball for their architecture,
2) choosing the wrong CFLAGS,
3) choosing the wrong -march setting,
4) choosing the wrong CHOST

Gentoo is actually a very reliable and very stable system if it is configured properly. The only time that Gentoo ever really fails (in the absense of the occasional borked ebuild) is when the user makes a critical error in configuring the system. Jackass! was designed as a system that implements redundant safeguards to protect the user from making any of these 4 common errors that can result in a b0rked installation. Because Jackass! consolidates all of these critical decisions into a prepackaged tarball with a pre-compiled GCC 3.4.3 toolkit, the user is protected from making any of those 4 common configuration errors.

The Jackass! tarballs were designed so that all of these settings had already been chosen, as if you had an expert looking over your shoulder, helping you with the install. For the average user, the complexity of building a GCC 3.4.3 / NPTL toolkit was reduced to simply picking the right ISO image that matches his processor. By correctly configuring all of these settings for the user, Jackass! prevents anyone from having a b0rked compiler on their system.


Another way in that Jackass! was designed to be fault-tolerant is through the use of coupled installation media. Just like the Gentoo 2005.0 tarballs, the Jackass! tarballs are sensitive to the installation media that they are installed from. We learned through our testers' mistakes that you can't install a 2005.0 tarball from 2004.3 installation media. Similarly, some versions of Knoppix work with 2005.0 tarballs, while other versions don't. To remove this potential pitfall from the complicating a Jackass! install, we developed installation media that is coupled to the tarballs on a Jackass! ISO. By coupling the media to the tarball, we were able to eliminate another source for installation errors -- installing from inappropriate media.


Though most people will probably never realize it, Jackass! was painstakingly designed after observing thousands of users making mistakes, to determine what the common installation errors are and to prevent them from re-occurring. In this respect, Jackass! is designed to be more fault tolerant than Gentoo by eliminating all of the most common causes of failure that are encountered during Gentoo installs.


BACK to the TARBALLS

The suggestion to supply tarballs independently of the appropriate installation media has to be considered for exactly what it is -- a two-edged sword. Although it provides more "choice" for the user, it also removes safeguards from the system and reintroduces the risk of user error causing a botched installation. Users that want to install directly from the tarballs need to appreciate that if they choose to worship at the altar of user choice, they run the risk of introducing errors into the system that had not previously existed.

So if the user is bent on installing from tarballs instead of from the ISO images, they should keep the following caveats in mind:

1. The Jackass! documentation was written to facilitate installing from the ISO, so if the user chooses an alternate installation medium, then they will have to adapt the installation method somewhat. This really shouldn't be too difficult for an experienced user, as you can treat the tarballs as if they were generic Gentoo 2005.0 tarballs.

2. The user subjects themselves to some risk of a b0rked install if they attempt to install from inappropriate installation media. By separating the tarball from the Jackass! ISO, we're essentially removing one of the safeguards that has been designed into the system for the purpose of giving user's alternative choices. If the user isn't conscientious, installing from a tarball instead of the ISO could be the equivalent of abandoning the fault-tolerant design of the system in the name of "choice." There is some risk associated with doing that.

Just so that nobody gets burned by this, I want to point out that for the install to work, you must use the Jackass! Install CD or a Gentoo 2005.0 Install CD. An older CD, such as the 2004.3 Gentoo install CD will not work. If you decide to install from another boot medium, then bear in mind that you're stripping fault-tolerance out of the system and assuming some degree of risk. In this case, you're not using a Gentoo product, and you're not using a supported Jackass! medium either, so if you decide to go down that path and things break... you get to keep the pieces.

3. The Jackass! tarballs contain a portage snapshot that was selected specifically because that snapshot of the portage tree was stable and free of all major glitches in the toolkit and in the ebuilds that are used to perform a Stage 1/3 install. We actually spent a period of months testing a large number of portage snapshots for the presence of defects, and kept working until we found one that fit the bill. Users that decide to sync to an alternate version of the portage tree will need to understand that doing so constitutes throwing away yet another one of the fault-tolerant designs that went into Jackass! Re-syncing is a crapshoot, and we can't guarantee a successful install if you use a different portage snapshot.


CLOSURE

In closing, I'd like to say that having spent an awful lot of time thinking about how to design a system that is as free of errors as is humanly possible, I have mixed feelings about the idea of throwing away some of the system's safeguards after the project has been completed just because a few people insist that they want tarballs in the name of "choice." I think that an awful lot of linux users make the fundamental mistake of viewing "choice" as an endpoint in itself, rather than as a means to an end. Knowing as much as I do about the Gentoo, Jackass!, and fault-tolerant systems, I think that the user would be best advised to leave Jackass!'s fault tolerant safeguards in place instead of removing them. Jackass! is an exceptionally fault tolerant system. If you use the packages as they have been provided , they are GUARANTEED to work. If you alter them, or if you choose not to follow the Installation Handbook, all bets are off. Personally, I am not too enthusiastic about undermining the design of the system in the name of user choice. I think that idea is exceptionally naive. Ultimately, it will cause more people to have problems with Jackass! than would have had problems with Jackass! otherwise. The net result will be that by circumventing the safeguards that were designed into the system, the system will appear to be less robust than it really is. I would have preferred to have released a system that is 100% reliable and guaranteed to work. But if users prefer the illusion of "choice" over robustness, who am I to argue?

Tarballs will be posted as soon as Sith can get around to it.

[SuperYak]

[Bob P]

don't worry -- i don't think you're trying to be a pain.

back to the subject of getting your host to work -- are you remembering to do this?

[SuperYak]

[Bob P]

okay, lets dig a little deeper into this. can you tell me exactly which installation media and/or tarball you installed from, and post the output of emerge --info?

its possible that you may be using a Jackass! package that i did not personally build, or one that i have not personally installed on my systems. and if that's the case, its possible that there may be an idiosyncracy that i am not personally familiar with, and i may need to enlist the services of one of the other builders to answer this question.

[Bob P]

[SuperYak]

[Bob P]

i'm a little confused by your post. did you perform a Stage 1/3 install using Gentoo tarballs, or a Jackass! install using the Pentium 3 ISO?

[SuperYak]

[Bob P]

ok, i'm was a little confused by this, as the P3 Jackass! tarball is supposed to have a subtle difference in its emerge --info output. your emerge info output looks like the output from a Stage 1/3 install, not from a Jackass! P3 install. although this isn't anything that would effect your system, it does bring up a QA issue that i need to discuss with the Development Team.

i'm going to ask for help on this one -- the method of implementing hostnames works exactly as specified in the docs on all of the tarballs that i have built, and i'm wondering if there may be some subtle differences in the P3 tarball that could be causing the problem you've observed in setting the hostname and domainname. from a QA perspective, i'm glad that you pointed this out.

just out of curiosity, how did you configure your hostnames and domainnames? did you try the second method recommended in Section 10.2 of the Stage 1/3 guide, and find that it didn't work? am i correct in understanding that you reverted to the first method recommended in the Stage 1/3 guide, and that worked?

[obsidianblackhawk]

[SuperYak]

[obsidianblackhawk]