Matt Sealey from Genesi was so kind and did a 2006.1 installation with the current handbook. He summarized the problems he had during installation. > Section 4.d: > > I think you should move the discussion of the "print" command above the > "mklabel" command. It is more reasonable for the user to want to "print" > what's on the disk to see if it is partitioned at all, before telling them the > way to make the partition table. > > The disk label "BI0" is not relevant at all to MorphOS. They can call it what > they like. > > Also it might be nice to tell users how they can "name" their partitions, > since when you get GNOME or KDE up, these will appear on their desktop with > friendly names, rather than "dhx.0" and "dhx" parted defaults. > > Later on it tells users they need to put their kernels on ext2 or ext3 > partitions which is true, but we have told them in the previous section that > it should be affs too (not directly, but..). I think this is a little > confusingly written. Right, I usually use an affs-partition. > For Pegasos we should recommend against non-ext partition types simply because > you can't boot from them in the firmware, and ReiserFS is notoriously unstable > on PowerPC. There is no real benefit in using XFS or JFS, except to make your > partitioning more complicated. I don't have problems with ReiserFS on PPC for years. And I used XFS on my iBook. > Maybe we should mention the partition scheme the Genesi installer tools use, > as this is pretty good for everyone. 500MB boot partition (ext2), 2GB swap, > and the rest of the disk how they like. We don't mount the boot partition as > /boot (it is for the installer tools and documentation etc.) but there is no > reason users could not symlink to a /mnt/Genesi/boot directory. I disagree on this suggestion. It's easier for the handbook to keep a similar partition layout for quite every arch. But the user can change it to his likes. > Section 4.f, code listing 6: > > # mkdir /mnt/gentoo > # mount /dev/hda4 /mnt/gentoo > > On every Gentoo I have ever used since the dawn of time, /mnt/gentoo already > exists, so this pops up an error. Making users do things which produce errors > is a bad thing for a manual to do. It makes them think they did something > wrong :) Already discussed in bug #143048. > Section 5.b: > > "If you don't have links available you should have lynx at your > disposal. If you need to go through a proxy, export the http_proxy and > ftp_proxy variables:" > > Why doesn't the manual know which browser is installed? Hmm. Cruft from old times? > Code Listing 5 then tells the user to supply the proxy on the command line, > which makes the environment variable setting above redundant, or it makes > this extra command line stuff redundant, depending on what you think :) > Section 5.e: > > :With MAKEOPTS you define how many parallel compilations should occur > when you install a package. A good choice is the number of CPUs in > your system plus one, but this guideline isn't always perfect." > > I found that MAKEOPTS="-j2" made the compiler segfault a lot. Just ignoring > this step completely and it worked fine. If the guideline isn't perfect, > why tell it? I don't have any problems at all with MAKEOPTS="-j2" on the Pegasos. This suggestion is part of the common-handbook for all arches. So I think we will keep it. > Section 6.a: > > However I found that in the section discussing emerge, it says: > > "If you are behind a firewall that blocks rsync traffic, you can use > emerge-webrsync which will download and install a portage snapshot for > you." > > This tool did nothing for me; it locked the same way emerge did behind the > bplan firewall. I had to set RSYNC_PROXY to get it to work. This is not > mentioned at all in the manual, but I think it should be. > > Also I am annoyed, but this is just a Unix thing I guess, that environment > variables are case-sensitive and seemingly different all the time. If I set > http_proxy and ftp_proxy that is fine, but rsync wants capital letters. Is > there a way to just patch rsync so we can make this more intuitive? :( Probably. But this is something we could solve with a better documentation as well. Just warn the user. > At the end of the day, I didn't do a manual kernel configuration as I think > this entire process is rather asinine and you would only want to do it for > fairly.. odd customization reasons like a strange installed storage card > you wanted to mount very early in startup. I don't have any of that so I > opted to use genkernel. > > The documentation about genkernel is confusing. It tells you to copy over > the kernel configuration from the installer kernel (zcat /proc/config.gz > etc.) - then you never use this file. > > Code Listing 21 states; > > # genkernel --genzimage --kernel-config=/usr/share/genkernel/ppc/Pegasos all Nice catch. Somehow I never realised, that the Pegasos-default-config is used during installation instead of the just copied kernel from the CD. > This kernel simply does not build, it misses "suspend.h". Hmmyes. That is another bug. Seems to be linux-headers-related. Run genkernel a second time and it builds. > Compiling the kernel we just copied out works, but is the installer kernel > config really "ready" for a real system? Don't you need to edit it to make > the boot arguments different or does genkernel handle this? It is ready, but I guess you want to use another config. I took out audio and multimedia stuff, as we don't need it on the CD. It's hard to create a small kernel that will boot for the CD, and one that works on nearly every system... > Also genkernel put in a crazy named kernel there (vmlinuz-genkernel-blah). > On most Linux it makes a vmlinuz (and symlinks an older one to vmlinuz.old) > symlink too, could we suggest this as it > makes system updating so much easier. That is Debian's behaviour. Creating kernel-symlinks is a feature suggestion for genkernel. > Everything else worked fine and I booted up and emerged modular X and > GNOME and was running fine. Thanks for testing, Matt! I hope that our docs-team will review your suggestions.
Okay, short summary for the docs-team, what should be changed: * using affs as fs for /boot on Pegasos * browser on the CD * information about RSYNC_PROXY * config for genkernel
(In reply to comment #1) > Okay, short summary for the docs-team, what should be changed: > > * using affs as fs for /boot on Pegasos > * browser on the CD > * information about RSYNC_PROXY > * config for genkernel > 1. affs - fixed in the draft, clarified. 2. CD browser - this is from a common-arch page. some arches don't have links but lynx (i.e. alpha). it stays as-is 3. RSYNC_PROXY - this really should be its own bug (or rename this one once the others are fixed), as the portage handbook is not arch-specific. we'll need to talk to the portage guys about why webrsync doesn't work out of the box 4. genkernel config - am fixing now.
(In reply to comment #2) > (In reply to comment #1) > > > * using affs as fs for /boot on Pegasos > > 1. affs - fixed in the draft, clarified. I think you misunderstood what I meant anyway, I can't see the draft, so... What I think it should say is that you should use ext2 if you use some other filesystem for your root, as we only boot from ext2 or ext3 currently. Then, a further clarification, that if you wish to boot MorphOS with a seperate partition for the boot.img, you should use affs (for Pegasos I or people who don't like asfs - or asfs if you have a Pegasos II. However, there is no reason why MorphOS cannot have it's boot.img files on the same partition as the MorphOS install. There was only a need for seperate files in cases like the Pegasos I, where it booted from affs but not asfs, and asfs was the recommended filesystem for the system partition. Basically.. I don't think we should encourage people to use affs or asfs for Linux boot partition, even if they are running MorphOS, but if they have some crazy requirements (like running Gentoo on a Pegasos I) then they are the caveats :) Summary: Pegasos I will boot from ext2 or affs Pegasos II will boot from ext2 or affs or asfs (or FAT or BSD4.4 UFS) Please use ext2 if you can help it. Use asfs if you require MorphOS, but consider keeping MorphOS kernels in the MorphOS system partition. Use affs if you require MorphOS on a Pegasos I or really cannot help matters.
Anything need to be done about this, really? PPC handbook as is has been committed to CVS; GDP can modify as needed. Ping on IRC or comment on this bug and/or attach patches as usual. :)
Just got to re-checking this bug after talking with JoseJX a few times awhile back. Marking as RESO WORKSFORME, as we shouldn't be bending over backwards so much to accomodate alternative operating systems ('specially fringe OSes like morphos :p) in our handbook. Plus, Joe didn't indicate that the info Matt provided (though informative) was really all that important. As it is, our PPC handbook works just fine, even for those installing Gentoo on a dual-boot Pegasos variety. (The fact that the Pegasos has since been discontinued is another reason for not going into partitioning specifically for it in our HB).
