Archive for the ‘Cuntoo’ Category

A Cuntoo Adventure Part Two

Sunday, March 3rd, 2019

Let's continue from the earlier cuntoo adventure.

So there I was, attempting to build a Cuntoo from my Gentoo installation on my system: Lenovo M-7033; Intel i5-2400 @ 3.10Ghz CPU; 8 Gb RAM; 500Gb SATA SSD.

To recap a bit from last time, the system's working Gentoo installation was on a 500 Gb WD SATA SSD, plugged into SATA channel 1 on the motherboard. To create a cuntoo, I simply powered down the box. Unplugged the mains, disconnected the CDROM drive from the power supply and it's SATA cable from SATA channel 2. I then proceeded to connect a 250 Gb WD SATA SSD to the power supply and then SATA channel 2. This way I could boot up gentoo, build/configure cuntoo, and target /dev/sdb (250 Gb WD SSD) as the block-device in-which to inflate cuntoo upon. These are the same initial steps that I had taken all during part one of this adventure.

I stopped into the forum for some help, however, I didn't go about all of this in the correct manner, so I caused more harm than good. But asciilifeform did mention to me that I needed to remove all modules from the kernel config. I then proceeded to build Cuntoo without any modules, but actually didn't return to check or work on it for about five days. Once I did manage to get more time to work on it, I did the following steps; powered down Gentoo, unplugged mains, unplugged the Gentoo 500 Gb SSD from the power supply, unplugged its SATA cable from channel 1, unplugged the Cuntoo 250 Gb SSD from the power supply, unplugged its SATA cable from channel 2, then plugged the Cuntoo 250 Gb SSD into the power supply and the SATA cable into channel 1. Additionally, I plugged the CDROM drive's power supply cable and the SATA cable back into channel 2. With that, everything was in place on the inside of the box for a test-boot. On the outside of the box, I ensured that my Null Modem cable was plugged in to the serial port, and to another machine where I could capture the output in case of Kernel Panic.

I set:

stty -F /dev/sttys0 115200 raw -echo -echoe -echok

on my secondary box, then immediately ran:

dd if=/dev/ttyS0 of=kern.nomods

Now that I was collecting output data from the serial line, it was time to power on the Cuntoo box and see if it helped anything by having no kernel modules at all, everything compiled in directly. After the box started up, the Cuntoo Lilo screen came up as expected, and then after 5 seconds, proceeded to boot. What was interesting was, I had the same output message on the screen as the previous times:

boot:
Loading Cuntoo.......................................
BIOS data check successful
early console in extract_kernel
input_data: 0x0000000001dd23b4
input_len: 0x0000000004f8f38
output: 0x0000000001000000
output_len: 0x00000000012b9908
kernel_total_size: 0x000000000106c000

Decompressing Linux... Parsing ELF... done.
Booting the kernel.

The main difference here was that instead of 39 dots after Cuntoo, there were hundreds (maybe?). My guess at that being that the kernel, with no modules, is just larger which outputs more dots during extraction time. Fine. Then after that message above posted, the screen flickered (which didn't happen on any previous attempt), and then changed fonts to a much smaller point value and displayed 4 penguins at the top of the screen (also something not seen in any previous attempt). I was somewhat convinced that this may just fully boot up! But after about 5 or 6 minutes (I wanted to give it time since it's a fairly large kernel), I finally powered it down. Snake-eyes. And with that I had run out of time to work on for another four or five days.

Side quest: We've gotten a whopping 51.4 inches of snow in February. It's been keeping me hopping from one foot to the next to keep it all cleared. I've also used 250 pounds of salt in one single month! I bought three hundred pounds, which I figured would easily last me a year, and maybe two. One month later, I'm pretty convinced I'll go through the remaining 50 pounds before it's all over.

Back to our adventure... I'd been rightly flogged for being an asshat and idiotically tilting at windmills. So I decided to slow down, and take a measured and calculated approach to figuring out what the problem might be. The first step here being to look at the kernel panic output from the 'no kernel modules' build that I had made a number of days prior. At first glance, I didn't see anything really too different in the actual reported error, with the subtle difference this time that the VFS was not able to mount root fs on unknown-block(8,3). Which in previous attempts it had said unknown-block(0,0). I walked away for about half an hour to think on it, and decided to read through the entire huge readout from the kernel panic. This one was much larger output from the first part of the adventure as this time, everything was compiled in directly.

Going through the entire massive output, I happened across the following:

[ 18.289235] sd 1:0:0:0: Attached scsi generic sg1 type 0
[ 18.289271] sd 1:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[ 18.289480] sd 1:0:0:0: [sdb] Write Protect is off
[ 18.289526] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 18.320978] Initializing XFRM netlink socket
[ 18.321079] sdb: sdb1 sdb2 sdb3
[ 18.321383] sd 1:0:0:0: [sdb] Attached SCSI disk
[ 18.322469] scsi 2:0:0:0: CD-ROM HL-DT-ST DVD-RAM GH70N NYA2 PQ: 0 ANSI: 5

Now this really struck me, because this part was never present before in the previous kernel panics that I had read through during the adventure. In this case, it seems that it found my disk! But it was strange to me that I found it labeled 'sdb', where I expected it to be 'sda'.

Once again, I put the Gentoo Live CD into the CDROM drive, booted into the live disk, and made a cuntoo chroot. Inside there, I simply changed the /etc/fstab to the following:

/dev/sdb1 /boot ext2 noatime 1 2
/dev/sdb2 none  swap sw      0 0
/dev/sdb3 /       ext4 noatime 0 1

And then I only changed 1 line in lilo.conf, from:

append="root=/dev/sda3 console=ttyS0,115200n8 net.ifnames=0"

to:

append="root=/dev/sdb3 console=ttyS0,115200n8 net.ifnames=0"

Then I ran the following command to update the lilo:

/sbin/lilo

Once that was finished, I exited the chroot, and did a shutdown on the box. I removed the Live CD, and then I booted my first Cuntoo.

That's all there really is to tell for this part of the adventure. There is more yak shaving to be done, of course. I'll post more when I have updates.

A Cuntoo Adventure

Sunday, February 10th, 2019

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.