Bubbagen live-USB for B3 version 1.16 (Gentoo Linux 6.1.12 Stable)

[Gordon]

Hi,

I've just released version 1.16 of the Bubbagen live-USB image for B3 on GitHub.



Significant change with this version is the drop of Easyfind, both in the GUI and as a service and DHCP activated module. Rodeus has announced the infrastructure for this service to be ended next month and due to lack of interest from the side of the community this has now officially been declared end-of-life.

On a positive side, apparently Debian decided to defy the ECSD binary distribution restriction quite some time ago and as there was no legal follow-up Gentoo decided to lift the flag on it as well. This means that although we are losing one feature of the original Bubba OS I have now been able to re-instate the Tor anonymous communication router to the default installed set.


The Live USB runs Linux kernel 6.1.12 and packages have been brought up to date as of May 1, 2023 ¹)

As before, two versions are supplied, one that uses the `classic` OpenRC service manager and one that uses the `modern` systemd service manager. Which version you choose is a matter of taste. People that run Linux desktop systems will likely prefer the systemd version for uniformity in their network but personally I find the command line tools for managing networking pretty complex/restricting whereas in the OpenRC version adding network functionality such as PPPoE connections and VPN is really easy.

If you don't know / can't decide, choose version 1.16.0 (OpenRC)


Key features:

• Familiar GUI for basic management (users, network, firewall, predefined services)
• Logitech Media Server version 8.3.1
• Wireguard VPN prepared (works with e.g. an Android phone)
• The Onion Router (TOR), get access to sites that are blocked by some geographic location rule
• Out of the box Windows compatible file sharing service (NAS)
• Will connect to any existing network (with a DHCP server) or create one itself (when connecting you will receive an IP in the range 192.168.10.x)

Known issues ²):

• When changing the time zone the web interface may show you an incorrect time on some pages (the extensible clock on the right is actually javascript and thus should show your client's time rather than the B3's). To align them all you should restart the B3 (or at least apache2 and bubba-adminphp services).
• Changing the network profile may completely destroy networking on the B3 if you have wifi enabled or added custom interfaces and/or bridges. If you need to change the profile please do so before making any changes to the default network setup and then never touch it again.
• Systemd has been observed to randomly experience a conflict with the DHCP client, causing it to drop the affected interface completely. A reboot will be required if you have no other method of reaching the B3 (second interface with fixed IP, serial console).
• Systemd version does not allow you to view system messages through the web based GUI. The associated links will always show an empty file. Messages from services that write their own log files, e.g. Apache webserver, Samba (windows compatible) file sharing, Logitech Media Server, can be viewed as normal.

Existing users:
There have been some troublesome updates lately that are related to a failing library inclusion in libapr referenced by e.g. Apache webserver. If you choose to continue with your existing installation, this release includes a fix for that failure. To enable that fix you will need to update virtual/bubba and app-admin/bubbagen first, then run `etc-update` (a patch file will be installed to /etc/portage/patches/dev-libs/apr/). Finish up with your regular regular update routine (eix, emerge, or sakaki's genup) to get to the current release.


Further details may be found here

Enjoy,
Gordon


¹) Some packages withheld due to patent restrictions or because the newer versions are incompatible with core Bubba functionality.
²) These truly seem unresolvable, don't they?

[MouettE]

Hello Gordon,

I tried to install your 1.16 version on a b3 for tests around kernel developments I'm working on but there was an issue after running install_on_dev_sda.sh ; after rebooting the kernel panicked trying to run systemd as init whereas I used the openrc version of the image. Maybe there is a mixup somewhere ?

EDIT : as a matter of fact in boot.ini, INIT was set to systemd, changed it to openrc and now the system boot.

[Gordon]

Hi, thanks for reporting.

Unsure at this point what might have caused this. Top of my head the boot.ini entries are set by the installer which is the same as in the previous version, since version 1.13 in fact.

Edit: found the culprit. For those interested in the details, the installer was checking for the existence of any systemd* package to enable systemd in boot.ini. The original test misidentified the image because a package named systemd-utils has been incorporated by openrc for handling tmpfiles and udev.

¹ seems to have been an issue in version 1.15 already

[elsbernd]

Hello Gordon,
As I own more than one b3, I tried to use your Gentoo Linux on my second one. Since I want to install the system I looked at the script install_on_sda.sh.

I installed a fresh/new SSD into the b3! So there no previous installation on that disk, and booted from USB

A

Code: Select all

lsblk; df -h

results in

Code: Select all

b3c ~ # lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda         8:0    1 14.6G  0 disk
├─sda1      8:1    1   64M  0 part
├─sda2      8:2    1    1G  0 part [SWAP]
└─sda3      8:3    1    6G  0 part /
sdb         8:16   0  1.8T  0 disk
mtdblock0  31:0    0  768K  0 disk
mtdblock1  31:1    0  128K  0 disk
mtdblock2  31:2    0  1.1M  0 disk

b3c ~ # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       5.7G  3.6G  1.8G  67% /
devtmpfs        248M     0  248M   0% /dev
tmpfs           248M     0  248M   0% /dev/shm
tmpfs           100M  1.6M   98M   2% /run
tmpfs           248M     0  248M   0% /tmp
tmpfs            50M     0   50M   0% /run/user/1001

this means, that the installer will install on the same (USB)-disk, the system is booted from. So I had to modify the script to install on /dev/sdb

[elsbernd]

Hello Gordon,
After (changing destination drive and) installation I tried to reboot the system with several commands, which failed always with the same errors:

Code: Select all

b3c ~ # reboot
WARNING: could not determine runlevel - doing soft reboot
  (it's better to use shutdown instead of reboot from the command line)

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:03:04 2023):

The system is going down for reboot NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory
b3c ~ # poweroff
WARNING: could not determine runlevel - doing soft poweroff
  (it's better to use shutdown instead of poweroff from the command line)

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:03:17 2023):

The system is going down for system halt NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory
b3c ~ # id
uid=0(root) gid=0(root) groups=0(root)
b3c ~ # halt
WARNING: could not determine runlevel - doing soft halt
  (it's better to use shutdown instead of halt from the command line)

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:03:36 2023):

The system is going down for system halt NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory

b3c ~ # shutdown -h now

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:04:32 2023):

The system is going down for system halt NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory

I used the more modern systemd installation.

[Gordon]

Hello Gordon,
As I own more than one b3, I tried to use your Gentoo Linux on my second one. Since I want to install the system I looked at the script install_on_sda.sh.

I installed a fresh/new SSD into the b3! So there no previous installation on that disk, and booted from USB

A

Code: Select all

lsblk; df -h

results in

Code: Select all

b3c ~ # lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda         8:0    1 14.6G  0 disk
├─sda1      8:1    1   64M  0 part
├─sda2      8:2    1    1G  0 part [SWAP]
└─sda3      8:3    1    6G  0 part /
sdb         8:16   0  1.8T  0 disk
mtdblock0  31:0    0  768K  0 disk
mtdblock1  31:1    0  128K  0 disk
mtdblock2  31:2    0  1.1M  0 disk

b3c ~ # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       5.7G  3.6G  1.8G  67% /
devtmpfs        248M     0  248M   0% /dev
tmpfs           248M     0  248M   0% /dev/shm
tmpfs           100M  1.6M   98M   2% /run
tmpfs           248M     0  248M   0% /tmp
tmpfs            50M     0   50M   0% /run/user/1001

this means, that the installer will install on the same (USB)-disk, the system is booted from. So I had to modify the script to install on /dev/sdb

Haven't seen that before. The normal disk assignment from Linux grants sda to the first drive found which is typically not a USB attached drive since this hardware has an additional initialization time of up to 5 seconds (hence the delay setting in the ini file). Possibly the latest kernels place disks that do not have any partitions defined last in the queue but that's pretty hard to test during development since you can only verify that once with any disk...

Thanks for reporting though. I guess this means I need to rethink the installer script.

[Gordon]

Hello Gordon,
After (changing destination drive and) installation I tried to reboot the system with several commands, which failed always with the same errors:

Code: Select all

b3c ~ # reboot
WARNING: could not determine runlevel - doing soft reboot
  (it's better to use shutdown instead of reboot from the command line)

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:03:04 2023):

The system is going down for reboot NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory
b3c ~ # poweroff
WARNING: could not determine runlevel - doing soft poweroff
  (it's better to use shutdown instead of poweroff from the command line)

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:03:17 2023):

The system is going down for system halt NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory
b3c ~ # id
uid=0(root) gid=0(root) groups=0(root)
b3c ~ # halt
WARNING: could not determine runlevel - doing soft halt
  (it's better to use shutdown instead of halt from the command line)

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:03:36 2023):

The system is going down for system halt NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory

b3c ~ # shutdown -h now

Broadcast message from root@b3c (pts/0) (Sun Jun 25 11:04:32 2023):

The system is going down for system halt NOW!
shutdown: /run/initctl: No such file or directory
init: /run/initctl: No such file or directory

I used the more modern systemd installation.

Yeah, I see that message from time to time but I only get that when I switch my dev environment from systemd to openrc. It appears to be related to systemd components being overwritten by other versions which of course should not happen in this case unless you are overwriting the current running OS itself because the disk assignments got changed after the SSD was partitioned and formatted (you stated before to have altered the install script to target sdb instead of sda). It's ill-advised of course but if you can verify that the disk content appears correct you can simply pull the power and then re-attach to boot the system from the SSD, provided that u-boot recognizes it.

[elsbernd]

Hello Gordon,
I used gentoo for a third exito b3 and as a rescue system for the other debian installation. Since "reboot" won't work I thought I give a system-update a try to solve the problem.
Since I'm not firm with gentoo, I used

Code: Select all

emaint --auto sync

to update the USB-Installation (systemd).

Since resolv.conf didn't work out of the box I

Code: Select all

ln -snf /run/systemd/resolve/resolv.conf /etc/resolv.conf
root #systemctl enable systemd-resolved.service
root #systemctl start systemd-resolved.service 

It loaded a lot of packages and finaly finished. Later I realized, that one could use genup for updating the system.
Nevertheless, it generated a lot of error messages, like

Code: Select all

>>> Jobs: 0 of 0 complete                           Load avg: 2.45, 1.54, 0.74
* Bringing genup itself up to date...
Calculating dependencies //usr/lib/portage/python3.11/ebuild.sh: line 628: /usr/local/portage/bubba/media-sound/forked-daapd/forked-daapd-26.4.ebuild: Permission denied
 * ERROR: media-sound/forked-daapd-26.4::bubba failed (depend phase:
 *   error sourcing ebuild
 *
 * Call stack;
 *   ebuild.sh, line 628:  Called die
 * The specific snippet of code:
 *                      source "${EBUILD}" || die "error sourcing ebuild"
 *
 * If you need support, post the output of `emerge --info '=media-sound/forked-daapd-26.4::bubba'`,
 * the complete build log and the output of `emerge -pqv '=media-sound/forked-daapd-26.4::bubba'`.
 * Working directory: '/usr/lib/python3.11/site-packages'
 * S: '/var/tmp/portage/media-sound/forked-daapd-26.4/work/forked-daapd-26.4'

So what's the correct procedure to update the system?
And is there a solution for reboot? Because I mounted the B3 in a location, which I can't access easily.

[Gordon]

So what's the correct procedure to update the system?

The recommended way is to use Sakaki's `genup`. The manual alternative is to use:

Code: Select all

eix-sync
emerge -1avuND --with-bdeps=y @world

You may be prompted that some packages reference libraries for which newer versions have been installed. This notably happens with `boost` and in such a case you are asked to emerge @preserved-rebuild. I recommend that you run this as `emerge -1av @preserved-rebuild`. Packages may also want to replace files in /etc in which case you need to run `etc-update` - do examine what it wants to change because this can disable e.g. remote access to cups print server (default for this service is local host only).

Note: `emaint --auto sync` is essentially the same as `emerge --sync`. The `eix-sync` command used above does some extra things, including syncing additional repositories called overlays. This method compares to Debian as `apt update`.

Since resolv.conf didn't work out of the box I

Code: Select all

ln -snf /run/systemd/resolve/resolv.conf /etc/resolv.conf
root #systemctl enable systemd-resolved.service
root #systemctl start systemd-resolved.service 

I'm not sure what could cause that. It needs to be noted though that the Bubbagen Live USB like the original Bubba OS aims to allow the system to set up its own network. Since systemd does not feature setting up a fall-back IP address Bubbagen uses DHCPcd to retrieve a dynamic address and this causes issues with systemd-resolved (the entries randomly get deleted as NetworkManager wants to overrule the external DHCP client).

If you don't need the fall-back IP functionality you can alter the configuration to use NetworkManager's internal DHCP client. You may even change to systemd's own networkmanager but in that case the Bubba GUI will no longer be able to access the network configuration.

Nevertheless, it generated a lot of error messages, like

Code: Select all

>>> Jobs: 0 of 0 complete                           Load avg: 2.45, 1.54, 0.74
* Bringing genup itself up to date...
Calculating dependencies //usr/lib/portage/python3.11/ebuild.sh: line 628: /usr/local/portage/bubba/media-sound/forked-daapd/forked-daapd-26.4.ebuild: Permission denied

Seems that there is a permissions issue with some of the files in the overlays. Admittedly my (cross-)dev machines use a somewhat more complex environment which apparently defeats this problem. The quick fix is to add o:rx to everything under /usr/local/portage

Note: regarding this particular build I just noticed an incompatibility with >= ffmpeg-4 so it would have failed either way. I pushed a fix for it to the bubbagen project earlier today. You can grab the patch file here: https://github.com/gordonb3/bubbagen/co ... 4867.patch (apply from file system root)

And is there a solution for reboot? Because I mounted the B3 in a location, which I can't access easily.

Saving the best for last I guess. I had not actually been affected by this before but it turns out that the Gentoo devs forcibly disabled the initv compatibility in systemd. I suspect they did this because many initv scripts bear different names from their systemd equivalents and their presence on the system causes the logs to be flooded with warnings. The trouble here is that Bubbagen relies on the initv compatibility for correctly handling both the power button on the B3 as well as the `halt` command. Granted, the hardware implementation of the `power down` situation is most likely less power efficient than if you let systemd handle the power on state but the latter will require you to power cycle the PSU to be booted back up again whereas the initv method allows you to do this using the power button on the back of the B3.

You can get the patch for this here: https://github.com/gordonb3/bubbagen/co ... 8fe8.patch (apply from file system root, then reinstall systemd).

Note: in the current situation it should be possible to do a clean reboot using `systemctl reboot`. If that still fails you can do `sync && reboot -f`.