A Cuntoo Adventure

They say the best way to tell any story is to start at the beginning. This story could be a bit long but, I'll try to tell it in the shortest way possible.

There I was about ten days ago, wanting to get a Cuntoo going not only for TRB purposes, but also for want to run TMSR~'s own UNIX. I have a number of different machines at my disposal that I could have chosen to attempt to build Cuntoo upon; however, they are all Intel hardware (for whatever reason I don't have a working AMD box at the moment - Cuntoo does ship with a APU2 kernel config), and I do have one machine that was a good choice to try Cuntoo out. This machine in particular is named 'trb-test1', and I built it in early 2018 and has been running Gentoo happily ever since. It's main job is a TRB testing environment. Never had a problem with it since I plugged it in late last spring. Let me give some context about it's hardware; the trb-test1 box is a Lenovo M-7033 with an Intel i5-2400 @ 3.10Ghz CPU, 8 Gb RAM, and a 500 Gb WD SATA SSD.

Let me give some further context about the working Gentoo environment that is installed on the 500 Gb WD SATA SSD (on SATA channel 1). Gentoo was built upon it in the usual fashion with a Live CD and through following the Gentoo Handbook. There was nothing out of the ordinary regarding its Kernel, I didn't do any custom Kernel configuration. It has a generic Grub boot-loader. The /etc/fstab/ has three partitions, as shown by the fdisk -l /dev/sda, very simple.

With all of this in mind, I went off to start on this Cuntoo adventure. To do so, I didn't want to use my existing Gentoo SSD for this, as I wanted to keep that around in case of problems. So I bought a new 250 Gb WD SSD for the job. I powered down the trb-test1 box, unplugged the CDROM from SATA channel 2, and plugged in the new 250 Gb SSD into channel 2. This allowed me to boot back into my working Gentoo and begin going through the steps as outlined on trinque's blog. To keep things totally simple, I copied over my working kernel config /usr/src/linux/.config from my working Gentoo on the same box (currently plugged into SATA channel 1, /dev/sda), and dropped it into the cuntoo/config directory and ran the following command: `./bootstrap.sh -k config/trb-test1 -d /dev/sdb`. Everything seemed to work well, however, the output genesis file didn't verify with trinque's signature. I decided to put that aside for a moment as I wanted to just see if I could get it to boot.

After the Cuntoo script had completed, I powered down trb-test1 and unplugged the 500 Gb SSD Gentoo disk from SATA1, placed it in an anti-static bag, and then unplugged the newly created Cuntoo disk from SATA2, and into SATA1, and plugged the CDROM drive back into SATA2. Now it was time to try booting Cuntoo for the first time. I powered on the box, and this was the message I received, and it just "hung" there for at least 5 minutes, which indicated to me that there was some kind of problem and it wasn't going to boot.

After that kernel hang, I was somewhat convinced that I had procured a bad SSD out of the box. So I decided to drive to go buy another one of the exact same specs, and try that one. It's never bad to have an extra laying around anyway, and I at least wanted to remove one possible variable from the equation. After a full rebuild of Cuntoo on the new 250 Gb WD SSD, I received the same panic message. If anything, it told me that it wasn't a hard drive issue. I did, many times, boot up into the Gentoo Live CD and mount the Cuntoo disk in a chroot to check various configuration files and paramters. The /etc/lilo.conf looked fine, I checked that the UUIDs for the /boot and / directories matched up from what was in /dev/disk/by-uuid, etc. And after that didn't seem to help, I went back to the /etc/lilo.conf and commented out those lines, and instead put in the proper 'boot=/dev/sda', and 'root=/dev/sda3'. After which, running `/sbin/lilo` to refresh the /boot/map and other things that lilo does when installing. Neither of which seemed to help here. I also looked over the /etc/fstab and a `fdisk -l /dev/sda` while in the chroot, all of which looked perfect. All in all, everything that I looked at that was installed by the Cuntoo bootstrap script, looked like it should have worked. Nothing at all seemed out of the ordinary.

The message at boot time was barely anything to go on, so I spent some time relearning how to get Kernel Panic messages out of the boot process. trinque's lilo configuration contained a 'console=ttyS0,115200n8' in the append section of the 'image' portion of the file. So, I unearthed my Null Modem Cable and plugged that into one of my other Gentoo boxes. On the other Gentoo box, I su'd to root, and ran the following command to enable reading from the Serial Line `stty -F /dev/sttys0 115200 raw -echo -echoe -echok`. I then executed a `dd if=/dev/ttyS0 of=kern.debug`. Back over to the Cuntoo box, I then powered it on, and when I received the hang-message, I waited about 1 minute to ensure that I had captured all of the panic output. Then I simply ^C'd the `dd` on the other box and sure enough, I had captured the panic in the file kern.debug.

After this, I tried a myriad of other things, I initially wrote them out here, but I'm going to cut them as they are pretty much irrelevant. Every type of different attempt yielded the same panic message.

There may be something about this particular iron it does not seem to be "happy" with. It seems strange to me that the same kernel configuration that I use for Gentoo, on the exact same box, would not work here properly. However, there could be something weird happening with the boot-loader, but it's beyond my area of expertise. One thing that I did note from comparing my working Gentoo to Cuntoo, is that my Gentoo does have an initrd installed into /boot. At one point, I even hand-built an initrd and placed it into the Cuntoo /boot and re-ran /sbin/lilo, but that didn't seem to help either. It just dropped me into a shell, that didn't get me much of anywhere. And additionally, I'm not super convinced that I even did that part 100% correctly as I've never hand-rolled an initrd before. I'm not sure that I will continue to try to get Cuntoo working on this particular hardware, maybe instead I'll have to acquire some APU2 iron and try trinque's provided APU2 kernel config. If I ever do find success on this particular hardware, I'll be sure to write about it on this blog as a follow up.

6 Responses to “A Cuntoo Adventure”

  1. Hey mod6, a few things.

    Since I used the apu2 as my test hardware, the build process indeed assumes that we'll be debugging via serial. Whether my not having mentioned this was sloth or rigor is a matter of taste. I had hoped that everyone would first read my (very short!) bash scripts.

    On the matter of the boot loader, it appears to have done its job. Notice that you were able to get logging statements from the Linux kernel from your serial connection. The beauty of lilo is that it performs this handoff to the kernel and ~very little else~.

    I'm still curious what might've happened to your system's grub - particularly whether the script wantonly wrecked the host bootloader - though I did take pains to force lilo to ignore all disks but the one on the operating table. Since I took those pains, I consider any evidence that they failed to be worthy of further investigation. As an alternative hypothesis, I did at one point in development accidentally aim the bootstrapper at my host's boot volume, with predictable and lulzy results.

    Back on the subject of your failed boot, notice the following line in your log:
    VFS: Cannot open root device "sda3" or unknown-block(0,0): error -6

    The Linux kernel is telling you it didn't find the root partition specified in the lilo config. This could be for a variety of reasons.

    You mention that your kernel came from a working system, but that this working system used an initrd. The typical role for an initrd on a desktop system is to load driver modules necessary to mount root. This is done (in the most ham-fisted of manners) by looping through every single module available and loading all those that will. Those modules can just as well be compiled directly into the kernel, and thus I made no provision for doing otherwise in my instructions or script.

    Another possibility is that you are trying to boot the newly cuntooed disk via USB, or for whatever other reason the disk is not enumerated as "sda". I see a USB hub in your kernel log, so this seems likely. This is likely a deficiency in the bootloader install step of my script, in that it demands the newly minted disk be numero uno at boot time. Perhaps using disk UUIDs to refer to root would be a better approach.

    Thanks for your testing!

  2. > After that kernel hang, I was somewhat convinced that I had procured a bad SSD

    That part is a jump, so to speak -- the more likely cause was simply bad kernel.

    > It's never bad to have an extra laying around anyway

    Word. God only knows, I buy 3x what I "reasonably expect to need" and half year later I need more.

    > and ran the following command to enable

    It might be a good idea if you put commands like that alone on a line by themselves, maybe wrapped in blockquote or something. Adds a lot to readability somehow.

    > Every type of different attempt yielded the same panic message.

    This is unsurprising, the kernel's bad.

    > I'm not sure that I will continue to try to get Cuntoo working on this particular hardware

    Listen, "handrolling" initrd's and whatnot is a waste of time -- simply try with a different kernel. (The reason this is expected to work is precisely what Trinque says -- module loading is a shitpile ; your odds of encountering a kernel that happens to have baked in what you happen to need are about even over three tries or so.)

  3. mod6 says:

    Sorry for the delay in rolling in your comments! I didn't know there were any pending my approval. (I'm still getting used to this new format.) I appreciate the comments from both of you!

  4. [...] mod6's Blog « A Cuntoo Adventure [...]

  5. [...] went through both lobbes' and mod6's recent cuntoo adventure reports to look for clues on kernel configuration, and found I could [...]

Leave a Reply