Gentoo live-USB for Bubba|2 updated (Linux 4.9.16 LTS)

[sakaki]

Hello,

I've just released version 1.4.0 of the live-USB image of Gentoo Linux for the Bubba|2 (B2) on GitHub (here). The kernel has been upgraded to version 4.9.16, which is a long-term-support variant. All included packages are up-to-date against the Gentoo tree, as of 25 March 2017. A full package list may be viewed here.

As before, you can burn the supplied image to a USB key (>=8GB, Lexar and SanDisk keys seem the most reliable; please see this note for a quick way to check compatibility), then boot your B2 from it, without affecting any installed (Excito) system on your B2's hard drive. (The compressed image is 354MiB; writing takes between 10 and 20 minutes, depending on your system.) You can even boot a diskless B2! No soldering, compilation or U-Boot flashing is required.

The live-USB may then be used as a rescue disk, to play with Gentoo Linux, or as the starting point to install Gentoo Linux on your B2's main hard drive. Any packages you install, or other changes you make, while running the live-USB are saved on the USB key, but do not affect your existing Excito system, so you can run Gentoo for a while, then reboot back into your Excito system and continue to use it as normal, then boot back into the USB at a later date - any changes you made will still be there when you do.

Full instructions are provided on the project's GitHub page (including how to specify initial network settings, so you can ssh in once booted, and how to install Gentoo on your B2's internal hard drive too, in case you want to do that).

Some other changes in this release:

• The image now has the getbinpkg FEATURE set by default, and is subscribed to my PORTAGE_BINHOST (at https://isshoni.org/b2); I have a B2 setup now to do a weekly genup run, with the resulting binary packages being rsync'd to this host. I can't guarantee to keep this going forever, but it should significantly shorten the future update process, at least for those packages included on the image). Packages not available on the binhost will be compiled locally as normal. If you don't want to use this facility, just edit out the appropriate FEATURES line in /etc/portage/make.conf. Use the provided binary packages at your own risk.
• Migrated from the sakaki-tools-lite tools to the regular sakaki-tools variants (genup and showem).

The GitHub project has an associated wiki. I have a few notes there on how to set up your PC as a cross-compilation / distcc server for the B2, to accelerate builds (you don't need to do this just to play with the image, of course). Feel free to add your own material!

Have fun ^-^

best,
sakaki

PS - many thanks to NorseMaN for kindly gifting me his old B2 server, which has enabled me to get this project back up running again.

[andy_b2_user]

Hi Sakaki

Unfortunately the image fails to boot needed to rescue the main system which has updated and now also fails to boot.

Screen shot of the terminal output in the attachments.

Andy

[sakaki]

Hi Andy,

seems you are booting 8313E21.itb, which is the same as that used by my local B2, so it is a little strange that it doesn't work (as I tried downloading, burning and booting the image before announcing). Do you have another USB device connected to your B2? Have you tried booting the new image more than once? Try booting the live USB with no other USB device on the bus and see what happens (U-boot's drivers can be flaky, unfortunately, and a read error during boot would cause a corrupted FIT).

If that fails, please try writing the previous live-USB image and booting that, so that the issue can be isolated to the new live-USB. Take heart that a valid, up-to-date B2 can be achieved (I am currently logged into one!) so I'm sure we can get yours up and running OK in relatively short order ^-^

Best, sakaki

[sakaki]

Hi again Andy -

To expand on my previous reply a little - when the B2 boots from USB, U-Boot tries to load (for 2nd rev B2 systems such as yours) the Flat Image Tree (FIT) file 8313E21.itb into memory, from the 'install' directory on the USB key's first partition. U-Boot, which is a standalone mini operating system, uses its own USB drivers to do this. Once loaded, the FIT file checksums are tested and, if good, the FIT image (which contains a kernel and device tree blob) is decompressed into memory and booted. From this point, Linux takes over as the operating system, and uses its own drivers to access the USB, HDD etc.

Unfortunately the U-Boot drivers are somewhat unreliable, which can lead to the FIT image being read partially, or with corruption, leading to a failed boot. With the same USB key, the boot can fail one time, but succeed on a second attempt.

Your console output shows the line "Bad FIT kernel image format!" which suggests that the 8313E21.itb file has been corrupted during load. To rule out any other problem, you can first check that the (latest 1.4.0) live USB 8313E21.itb file is OK on the USB itself, by mounting the first partition (of the USB key onto which you have written the gentoo-on-b2 image) on your Linux PC, and then running "md5sum *" in the install directory. This should yield the following checksums (unless you have modified any of the files yourself of course):

Code: Select all

/run/media/sakaki/boot/install $ md5sum *
5111f2c198e19f63bbd0855f39a7e0ec  8313E21.itb
2f036e4b2ac35c7b1e27ad9959e3e88b  System.map
31ac0ccf3390cd48c7a4901a771ca1e2  config
eb13f82ad52188809780674b6c2f4c30  install.itb
137cb8367a30b37395926439ddee23e9  net
bd57bd63ad934b40b5bdb297c868e6c2  resolv.conf

If you have the mkimage command available on your Linux PC, you can even validate the 8313E21.itb layout:

Code: Select all

/run/media/sakaki/boot/install $ mkimage -l 8313E21.itb 
FIT description: Excito B2 Gentoo Image with Kernel and DTB
Created:         Thu Mar 23 18:24:05 2017
 Image 0 (kernel@1)
  Description:  Shimmed Linux 4.9.16-gentoo-mod-b2
  Created:      Thu Mar 23 18:24:05 2017
  Type:         Kernel Image
  Compression:  uncompressed
  Data Size:    7176328 Bytes = 7008.13 kB = 6.84 MB
  Architecture: PowerPC
  OS:           Linux
  Load Address: 0x02000000
  Entry Point:  0x02000000
  Hash algo:    sha1
  Hash value:   6aa53444d6f3ecfb71def00d19b561f57d53302f
 Image 1 (fdt@1)
  Description:  Flattened Device Tree Blob for B2 (rev2)
  Created:      Thu Mar 23 18:24:05 2017
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    7631 Bytes = 7.45 kB = 0.01 MB
  Architecture: PowerPC
  Hash algo:    sha1
  Hash value:   1390ad1b966c4a623ff6184c517fd26f39a1aeb8
 Default Configuration: 'config@1'
 Configuration 0 (config@1)
  Description:  Boot Excito B2 with Supplied Kernel and DTB
  Kernel:       kernel@1
  FDT:          fdt@1

This second step is entirely optional.

In any event, if the checksums match, then the genb2img.xz image has been written to the USB key correctly. In that case, try booting your B2 from the key a few more times. Start with no other devices on the USB bus, and the power cable removed, each time. Do you see the same console error message on each attempt, or does the kernel unpack and boot correctly now?

Best, sakaki

[andy_b2_user]

Hi Sakaki.

Success after a few problems and Kernel Panics.
The usb stick booted correctly after I removed the hard disk and installed itself. I suspect it was picking up the older version image files on the hard disc and not the updated ones on the usb stick. I decided to start the build again as all the script files needed updating. The 1st run failed due to a Kernel panic and the logging stopped after the disc had been formatted. Doing repeated testing, I found that the only way the files will copy was to alter the install script to sync after 2 directory's had been copied, may be that the image file should be updated. (The disk was a 16GB sandisk Cruzer Dial for reference.)

For example

Code: Select all

cp -axr /bin /dev /mnt/sdaroot >>"${LOG}" 2>&1
sync
cp -axr /etc /home ...
sync

Many thanks again for the work in producing this update. The system is currently running "Genup" before I create a weekly cron job

Thanks

Andy

[sakaki]

Hi Andy -

glad to hear that your system is now up ^-^

What configuration exactly do you have for the HDD on your B2? Is the 16GB Cruzer Dial the USB stick you mention the one you wrote the live-USB image to, or are you trying to use this as your main drive (i.e. have you got a SATA disk in your B2 as /dev/sda that you are installing to?) The provided kernels make certain assumptions about where the root filesystem lives. For the live-USB kernel (also /root/kernels/uuid_5sdelay/... on the image):

Code: Select all

CONFIG_CMDLINE="root=PARTUUID=BBF82D16-03 rootfstype=ext4 rootdelay=5 console=ttyS0,115200n8"

For the kernel installed by default by the install_on_sda.sh script (/root/kernels/sda3_nodelay/...) however:

Code: Select all

CONFIG_CMDLINE="root=/dev/sda3 rootfstype=ext4 console=ttyS0,115200n8"

Also, FYI my automated genup / rsync run triggers on Saturdays, so if you are setting up a weekly genup cron script, and using the isshoni.org binhost, probably best to set this to run on e.g. a Monday, so that you have maximum chance of using the resulting binary package files on each cycle, for efficiency.

Best, sakaki

[andy_b2_user]

The hard disc was the original one supplied by excito which I had the previous gentoo version copied onto it. As the previous script failed I did a rsync of the files on the USB stick to the hard drive and it is very possible that a incorrect file was copied in error.

At the start of this process I was using the usb stick as the main drive. It will not work, as the number of writes made to complete a full emerge is greater than the design life quoted.

Andy

[sakaki]

If you have installed to the original HDD you should be fine, you'll have sufficient capacity and inodes for Gentoo. But I'll have a look at the install_on_sda.sh script to see what might be causing the need for the extra sync's during the install copy.
Do let me know if you have any problems completing the current genup run, or if your cron-driven genup doesn't appear to pull the binary packages correctly etc.
Best, sakaki

[sakaki]

Hi,

the first automated weekly B2 build / rsync run appears to have gone through OK this weekend, with new-version binary packages for sqlite and mariadb (amongst others) having been pushed to the archive at https://isshoni.org/b2.

If you are putting together a crontab script to automate genup at your end, remember that you need to provide an appropriate environment (per the manpage). For example, you could put in /usr/local/sbin/run_genup:

Code: Select all

#!/bin/bash
export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin"
genup >/var/log/latest-genup-run.log 2>&1
# get rid of the lines below if you don't have mail sending configured on your b2
RC=$?
if ((RC==0)); then
	mail -s "B2 genup run SUCCEEDED" your@email.address < /var/log/latest-genup-run.log
else
	mail -s "B2 genup run FAILED" your@email.address < /var/log/latest-genup-run.log
fi

Make this file executable, then setup a crontab entry for root - e.g. to run at 1am every Tuesday, run crontab -e and add:

Code: Select all

0 1 * * Tue /usr/local/sbin/run_genup

I would avoid using cron.weekly, as that'll usually run on the weekend and so risks missing any binary packages built and uploaded by my B2 on its weekly cycle (resulting in duplicated compilation).

Best, sakaki

[andy_b2_user]

Hi Sakaki.

Yes the "genup" script completed last night, the only draw back was that the --depclean removed the apps-editor/nano which was not in @world. I have emerged it back with the --no-replace option. If required I can post the large log file. I now need to setup the email account as your script below has saved me a load of testing.

Thanks

Andy

[sakaki]

Hi Andy -

yes, apps-editor/nano is actually cited indirectly, via virtual/editor (part of the @system set) on the live-USB image, so if you explicitly emerge another editor that satisfies this virtual, such as vim or emacs (see /usr/portage/virtual/editor/editor-0.ebuild for the full list), nano will become "surplus to requirements" (from Portage's perspective) and so be removed by genup's depclean step. Which I guess is what happened.

Now you have explicitly emerged nano however, it will be cited in /var/lib/portage/world, and not be removed by depclean.

By the way, for emailing results out, if you want to use gmail or similar, you may find it easier to uninstall postfix (which is a full-blown MTA and fairly complex to configure) and just install mail-mta/nullmailer and mail-client/mailx instead; see for example these notes for configuration of nullmailer. mail-client/mailx provides the "/bin/mail" binary.

Best, sakaki

[sakaki]

Hi -

For anyone who is running Gentoo on their B2, and is subscribed to the https://isshoni.org/b2 binhost, please note that the weekly binary package update has not yet been pushed. Version 5.4.0-r3 of gcc went stable for ppc in the Gentoo tree last week, and this package (which has to build locally on the B2) is still compiling as I write this ><

I would hope that the binary sys-devel/gcc-5.4.0-r3 package (together with the other pending updates from last week) will be pushed in the next day or so.

Best, sakaki

[sakaki]

Hi again -

OK, sys-devel/gcc-5.4.0-r3 and libtool have now been successfully built on the B2, and the binary packages pushed.

However, per this Gentoo news item, because gcc 5 uses the new C++ 11 ABI by default, I am currently running a precautionary rebuild of the affected packages using:

Code: Select all

b2 ~ # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

This is going to take a while. When that's done I will push the resulting packages and then run genup again.

This is a one-off consequence of migrating from GCC 4 to 5. I'll post here again once the migration is complete and the isshoni.org binhost has been updated.

In the meantime, if you are subscribed to this binhost, the best thing is to hold off any cron-based genup jobs until my notification. That way, you'll be able to take advantage of the binary packages rather than tying your own machine up in a lengthy rebuild.

Best, sakaki

[sakaki]

OK, the affected libraries have now been rebuilt and their binary packages pushed, and genup's latest automated weekend run has also just completed successfully.

Therefore, if you are using Gentoo on your B2, and are subscribed to the the https://isshoni.org/b2 binhost, it is now safe to run genup again - everything you need to update should be present on the server.

One point - when you do run genup, your gcc compiler will be upgraded to version 5 from version 4. Once genup completes, check this is so:

Code: Select all

b2 ~ # gcc --version
gcc (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and then ensure that all C++ apps are rebuilt (this is a one-off requirement of moving to gcc v5; see the news item linked in my previous post). Issue:

Code: Select all

b2 ~ # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

(As mentioned, binary packages for all the affected items have been pushed, so this update shouldn't take too long.)

Any problems please let me know, best,
sakaki

[Gordon]

I think that last command should be

Code: Select all

b2 ~ # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc --getbinpkg

?