[SOLVED] brl fetch solus

marcin- · 08-11-2019, 03:52 PM

I noticed that brl fetch solus fails due to unresolved dependency.
After this update util-linux needs python3 which is not a part of system.base component and it breaks eopkg install -c system.base. I fixed this issue modifying /bedrock/share/brl-fetch/distros/solus file.
from

Code:

	chroot "${bootstrap_dir:-}" eopkg -y -D/target-root install -c system.base

to

Code:

	chroot "${bootstrap_dir:-}" eopkg -y -D/target-root install -c system.base --ignore-dep
        # python3 is required dependency for util-linux
	chroot "${bootstrap_dir:-}" eopkg -y -D/target-root install python3

ParadigmComplex · 08-12-2019, 03:08 AM

Thanks! I'll see about including this in an upcoming point update.

marcin- · 08-24-2019, 10:59 AM

I noticed another issue for brl fetch solus. It occurred for hijacked void and artix linux.

Quote:

[11/17 ( 64%)] Running bootstrap software
dbus[25867]: Unknown username "systemd-timesync" in message bus configuration file
dbus[25867]: Unknown username "systemd-resolve" in message bus configuration file
dbus-daemon[25867]: Failed to start message bus: Could not get UID and GID for username "messagebus"
ERROR: Unexpected error occurred.

after short research I found solus passwd file and added the appropriate group and user.

Code:

# groupadd -g 18 messagebus
# useradd -c 'D-Bus Message Daemon' -u 18 -g messagebus -d '/var/run/dbus' -s '/bin/false' messagebus

brl fetch solus works fine.

Quote:

* Successfully fetched a new solus stratum with name solus

Seems "systemd-timesync" and "systemd-resolve" are needed to avoid "Unknown username ... in message bus configuration file"

ParadigmComplex · 08-24-2019, 11:34 AM

I've applied your initial fix in 0.7.7beta1, which you can try with https://bedrocklinux.org/0.7/beta-channel.html

If you find the time, please do test it and confirm it resolves the original issue. Thanks again for the fix!

I'll look into this new item and either add it to 0.7.7 before it leaves beta or queue it up for 0.7.8.

marcin- · 08-24-2019, 12:06 PM

I can confirm that original issue gone, checked today with 0.7.7beta1.

I have to say I like bedrock linux and I follow commits on github recently.

ParadigmComplex · 08-24-2019, 12:30 PM

Happy to hear it

marcin- · 08-29-2019, 08:54 AM

I tested latest improvements for src/slash-bedrock today.
brl fetch solus works fine. dbus-daemon problem gone.

ParadigmComplex · 08-29-2019, 11:24 AM

The latest release - 0.7.7 - includes your python fix but, as far as I recall, not your dbus fix.

By latest improvements do you mean the master branch? I did include the dbus fix there, but didn't want to get your attention to fix it until I pushed a beta release with it. If that's what you mean, awesome

marcin- · 08-29-2019, 02:53 PM

Yes, I used the master branch.
I tried interrupt fetching bootstrap packages due to I wanted to check caching support. Seems it works as well. I had only run brl remove solus before second brl fetch solus.
Do you think about checking if brl fetch is executed for resume? (to avoid run brl remove when something went wrong at the first attempt)

ParadigmComplex · 08-29-2019, 03:45 PM

Quote:

Originally Posted by marcin-

Yes, I used the master branch.
I tried interrupt fetching bootstrap packages due to I wanted to check caching support. Seems it works as well.

Excellent!

Quote:

Originally Posted by marcin-

I had only run brl remove solus before second brl fetch solus.
Do you think about checking if brl fetch is executed for resume? (to avoid run brl remove when something went wrong at the first attempt)

If `brl fetch` detects an error, it will `brl remove` the partially fetched stratum itself. Try cutting giving it an obviously bad mirror, cutting off your internet connection while it's running, or killing one of its sub-processes such as a wget or bootstrap tool like debootstrap while it's running. I could have it do this for ctrl-c/SIGINT, but it seems safer to stop immediately just in case there's a bug in the clean up code the user is attempting to stop.

Resuming an interrupted fetch is difficult, because:

If the interruption lasts a non-trivial amount of time, details like the packages in the remote repository may change. In these cases we'd have to back out and restart anyways with new packages anyways.
A lot of `brl fetch`'s code is actually running some bootstrap tool by the fetched stratum where we don't have enough control to add in logic to resume.

Given the new caching feature, the need to resume should be greatly diminished, as it should be able to re-run the initial steps with cached content relatively quickly. The main non-cached steps are verifying the cached files are current - something we'd have to do if resuming as well - and applying the cached data.