Since the relatively recent discovery that Cuntoo work is apparently not really going anywhere for lack of more public testing and reporting, I'm doing my bit and publishing what I've got so far on installing Cuntoo on a local box and prodding it for a while. First, to introduce the box in question, so you can easily replicate it:

• AMD FX-8350, 4GHz, Octa Core
• Gigabyte Ultra-Durable GA-78LMT-USB3
• 2*8GB DDR3 RAM
• 1TB Seagate Barracuda

Since I wanted to do this from scratch to make sure it's easy to replicate, I ignored my previous Cuntoo-compilations and I made myself first a bootable USB-stick with Gentoo's livecd. Initially I took the minimal install_amd64_minimal_20190703T214502Z.iso but that proved iffy to use because it was apparently a bit too spartan for my requirements (esp. no make on it). So I traded space for time as it were and used instead the much larger livedvd-amd64-multilib-20160704.iso (2.2G vs 292M for the minimal iso). Perhaps this was quite overkill and there is something in between that does the job just fine so if you find/have that, just use it - the bootable USB-stick really is just a way to "get in," nothing more. Note that on some .iso images you might need to run isohybrid first if you want to use them to boot from USB (rather than burning them on a CD/DVD). As for making the bootable USB stick, that's as easy as using dd to transfer the .iso to your USB drive - do be patient if your .iso is big as dd is silent.

Armed with the bootable USB stick, I popped it into one of my USB 2.0 slots and turned the machine on. If you have the same setup as mine, the F12 key will give you the boot menu (or Delete for the full BIOS menu) and you'll need to select the USB stick *from the hard-drives* (you'll need the PgUp/PgDown keys and not the +/- as some docs mislead me). Once the live-dvd Gentoo image boots, you can proceed with the Cuntoo-related tasks, in order (note that you'll be doing all this inside the live-dvd image so if you reset, *the environment will reset too and your changes will be lost* so you'll need to start from the beginning again. With many thanks to Hannah for her mini-series of posts detailing her ordeal with Cuntoo and therefore inspiring my script-making right from the start, here are the steps and the relevant script parts:

1. Add to your /etc/hosts file the IPs of any websites you'll need - the exact list depends on what you choose to do at each of the following steps (e.g. where do you take your V from) but at the very least you'll need the IP¹ for trinque.org to get the Cuntoo tarball!
2. Obtain and import any gpg public keys you need - similar to the step above, the exact list here depends on whose stuff you use but as a minimum you'll need Trinque's key, of course. As I've used only Trinque's and my own stuff, my gpg-importing bit of the script looks like this:

   # gpg keys
   curl -v "http://ossasepia.com/vpatches/diana_coman.asc" -O
   gpg --import diana_coman.asc
   curl -v "http://wot.deedbot.org/FC66C0C5D98C42A1D4A98B6B42F9985AFAB953C4.asc" > trinque.asc
   gpg --import trinque.asc
   

3. Get and install a working GNAT. My choice here for expedience is to use the frozen Adacore version that I'm hosting on this site. Correspondingly, the relevant part of the script grabs it from my website, checks the provided sha512sum on it and installs it (if the GNAT dir doesn't already exist from a previous run perhaps):

   # GNAT
   GNAT="gnat-gpl-2016-x86_64-linux-bin";
   GNATZIP=$GNAT.tar.gz
   
   if [ ! -e $GNATZIP ]
   then
     curl -v "http://ossasepia.com/available_resources/gnat-gpl-2016-x86_64-linux-bin.tar.gz" > $GNATZIP
   fi;
   
   if [ ! -e $GNATZIP.sha512 ]
   then
     curl -v "http://ossasepia.com/available_resources/sha512sum_gnat-gpl-2016-x86_64-linux-bin.tar.gz.txt" > $GNATZIP.sha512
   fi;
   
   if [ "$(sha512sum $GNATZIP)" = "$(cat $GNATZIP.sha512)" ]
   then
     echo "Matching sha512sum for Adacore-GNAT."
   else
     echo "FAILED sha512sum test for Adacore-GNAT, stopping."; exit
   fi;
   
   if [ ! -d $GNAT ]
   then
     tar -xvf $GNATZIP
     cd $GNAT
     sudo ./doinstall
     cd ../
   else
     echo "GNAT dir already exists so GNAT is assumed installed! Skipping GNAT install."
   fi;
   
   PATH="/usr/gnat/bin:$PATH"; export PATH
   echo "Updating PATH variable to $PATH in order to use GNAT."
   

4. Get and install your favourite V. Make *sure* it can be found (e.g. update your PATH variable with V's location). Once again, since I can rely on my previous work on packing V (namely mod6's implementation of V), my life is that bit easier now and my script relies on my website to get and check everything:

   # V
   VDIR="starter_v"
   VZIP=$VDIR.zip
   if [ ! -e $VZIP ]
   then
     curl -v "http://ossasepia.com/vpatches/starter_v.zip" > $VZIP
   fi;
   if [ ! -e $VZIP.diana_coman.sig ]
   then
     curl -v "http://ossasepia.com/vpatches/starter_v.zip.diana_coman.sig" > $VZIP.diana_coman.sig
   fi;
   
   echo "gpg --verify $VZIP.diana_coman.sig $VZIP"
   gpg --verify $VZIP.diana_coman.sig $VZIP
   
   if [ ! $? -eq 0 ]
   then
     echo "FAILED sig check on $VZIP, stopping."; exit
   else
     echo "Sig check fine for VZIP"
   fi;
   
   if [ ! -d $VDIR ]
   then
     unzip $VZIP
   fi;
   
   cd $VDIR
   chmod +x build.sh
   ./build.sh
   cd ../
   PATH="$PWD/$VDIR:$PATH"; export PATH
   echo "The PATH var for using gprbuild, vk.pl, ksum, vdiff and vpatch is: "$PATH
   

5. Get Cuntoo itself (note that it's ~800M so depending on your connection, this step may take a while):

   # Cuntoo itself
   CUNTOO="cuntoo"
   CUNTOOZIP="$CUNTOO.tar"
   
   if [ ! -e $CUNTOOZIP ]
   then
     curl -v "http://trinque.org/$CUNTOOZIP" > $CUNTOOZIP
     curl -v "http://trinque.org/$CUNTOOZIP.sig" > $CUNTOOZIP.sig
   fi;
   
   echo "gpg --verify $CUNTOOZIP.sig $CUNTOOZIP"
   gpg --verify $CUNTOOZIP.sig $CUNTOOZIP
   
   if [ ! $? -eq 0 ]
   then
     echo "FAILED sig check on $CUNTOOZIP, stopping."; exit
   else
     echo "Sig check fine for $CUNTOOZIP"
   fi;
   
   tar -xvf $CUNTOOZIP
   cd $CUNTOO
   

Once all the above finished without any error or problem, all you need to do is to run the bootstrap.sh script according to Trinque's instructions. If you are at a loss as to the kernel config - by far the ugliest part in this - and your hardware is similar to mine, I was able to use Stan's "Dulap-II" config with minimal (possibly it works even without any) changes so go grab that one and feed it to the script - note that you'll get a quite spartan but absolutely functional environment and you can customize it from there as you want it. Here's the full bash script too if you want to use it: cuntooprep.sh.

NB: at the moment I'm writing this, the known path-issue within Cuntoo's scripts is still present in the Cuntoo.tar file so you'll need to do the change manually for the signature to verify on the genesis.vpatch that you obtain at the end. The change you need to make is explained in the logs and you can do it after running the bootstrap.sh script if you already started that.

Once you get the genesis.vpatch, verify it against Trinque's signature - if it doesn't verify, chances are that you still need to fix the paths issue so see the paragraph above and remember to actually re-run the scripts/make_portage_tree.sh script after you made the change! Then simply reboot and choose to boot from the disk on which you installed Cuntoo. You can then recompile the kernel to tweak any configs you want, for instance with those steps:

1. cd /usr/src/linux
2. make oldconfig
3. make menuconfig (and/or change whatever you want directly in the .config file before running this - I've ended up finding the *text* file BETTER than the bloody gui thing simply because nobody can tell where something is in there, ugh.)
4. make && make modules_install
5. cp arch/x86/boot/bzImage /boot/bzImageNew
6. change /etc/lilo.conf to add the bsImageNew as another boot option (DO keep the old one too, at least until you are sure the new one is fine!)
7. lilo
8. shutdown -r now

Once you had enough of recompiling the kernel, the next step would be to have a look at what you'd like to add to your system - chances are there'd be quite a lot of things that you need before you can actually do a lot in there. Cuntoo has its own preferred repository in /cuntoo/portage and a distant second in /usr/portage. So when you run emerge, you'll see either ::cuntoo or ::gentoo appended to the packages required, depending on which of the repositories is used. To enrich the cuntoo repository and effectively get rid of the madness where gentoo just doesn't "have" anymore the packages you want, you'll need to copy the tarball of your package into /cuntoo/distfiles and the ebuild+manifest+patches+shit into /cuntoo/portage/package-path. My initial attempt with MySQL was a step too far at this stage as it served only to point out more clearly what a mess porting the dependencies to Cuntoo will be - MySQL itself requires all sorts! So I looked among those "all sorts" and picked out one with better chances of being standalone, namely curl. With this adjusted aim, I was actually able to "port" the curl ebuild to Cuntoo as it were, simply like this:

1. Download the tarball without installing it: ebuild /usr/portage/net-misc/curl/curl-7.60.0.ebuild fetch
2. Copy then the tarball to /cuntoo/distfiles
3. Copy /usr/portage/net-misc/curl to /cuntoo/portage/net-misc/curl
4. Go into /cuntoo/portage/net-misc/curl and snip away the ebuilds that are other versions than 7.60.0 as well as the references to them in the Manifest file (NB: you'll need to keep all the patches though regardless of what their names say as they are still applied to the 7.60.0 version anyway).
5. Now run emerge --ask -v net-misc/curl and look closely: it should say ::cuntoo and it should report that it has to download precisely 0Kb. If all that is true, let it do it and you'll have gotten Curl in your new and sparkly Cuntoo!

Now I must say that I'm a bit at a loss as to whether the above curl-experience should get the grand name of "making an ebuild" or not or what - to me it looks more like hacking an ebuild at best and moreover a quick look at gentoo's docs re making ebuilds reveals enough *other* stuff to eat that I don't see it happening all that soon. So I don't even know - is *this* sort of hacking ebuilds that Trinque was asking for? Or writing them from scratch or something else entirely or what?

1. Obviously, unless you use DNS but why would you still use that anyway? ↩

Category: Coding

Comments feed: RSS 2.0