Power saving measures in command line mode?

The_Pope · Tux's lil' helper Joined: 03 Jul 2016 Posts: 111

Hello everyone,

I managed to start the installation on this UEFI tablet by booting from the liveDVD.
The problem is, the battery runs out while compiling

I boot the DVD, which defaults to GUI mode, but quickly switch to the console, pressing Ctrl+F1. Then I set the root password and start the installation normally.

What I'd like to try now is to switch off the screen before compiling. Like

"switch off screen" && emerge --oneshot whatever && "switch on screen"
Every USB device I connected to it is on a separately-powered USB hub. I also set MAKEOPTS="-j1" in the hope it will eat up less power than -j2, although I can theoretically go up to "-j4"
The tablet is connected to a 5V 3A power supply at all times, but it seems that's just not enough. That's why I'm hoping that switching off the screen will be enough to keep it going.

As a sidenote, I managed to install the resolve-march-native package, and the respective command gave me the longest -march line I've ever seen. It's some sort of low power dual-core Intel Atom with Hyperthreading, apparently.

Searching around the forum, I found this topic mentioning setterm -powersave off and setterm blank 0.

Having looked at setterm, I will try "setterm --powerdown 1" && "emerge whatever" && "setterm powerdown 0"

Any other tips to make sure I can compile at least one package at a time?
_________________
Stop the world. I want to descend.

NeddySeagoon · Posted: Fri Dec 23, 2022 9:45 pm Post subject:

The_Pope,

"switch off screen" && emerge --oneshot whatever && "switch on screen"
is probably not quite what you want. && means if the previous command is successful ... do the following command.
That is, if emerge fails. the screen stays off. That's probably not what you want.

Write a wee ditty to do three separate commands on three lines.

Thinking about installing on something like a low power Atom.
I would build it binaries on a more capable system, poor wee thing, then install the binaries on the Atom.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

The_Pope · Tux's lil' helper Joined: 03 Jul 2016 Posts: 111

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2191

NeddySeagoon · Posted: Sat Dec 24, 2022 10:48 am Post subject:

The_Pope,

Not distcc, the configure and linking still happens on the poor wee tablet.

On your favourite desktop, make a chroot. Perform the Tablet install there.
Before you build anything ... in the chroot
1. Set CFLAGS to that mouthfut that resolve-march-native gave you.
2. Run app-portage/cpuid2cpuflags on the tablet and set CPU_FLAGS_... to whatever it tells you.
3. Add buildpkg to FEATURES

Now your big hairy desktop is going to build everything in the chroot to suit the poor wee Atom.
It will save a set of binary packages for the Atom too.

Its only that easy if the build host CPU can execute all the instruction on the Atom.
It can certainly build code that way.

The code in the chroot can be divided into two groups. The code that must run there, and everything else.
If you find that the chroot gives you illegal instruction errors, some code built for the Atom has just failed to execute on the build host.
You can build a list of packages as you discover them and set more build host friendly CFLAGS, just for them.

Its time to move your binary packages to the Atom and install them there.
There are several ways to achieve that.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

The_Pope · Tux's lil' helper Joined: 03 Jul 2016 Posts: 111

The_Pope · Tux's lil' helper Joined: 03 Jul 2016 Posts: 111

NeddySeagoon · Posted: Sat Dec 24, 2022 4:32 pm Post subject:

The_Pope,

make.conf contions changes to your profile. CHOST is set in you profile.
There has been no need to change the CHOST since glibc dropped i386 support at glibc-2.2. At that time many users had no upgrade path as thef started with the i386 stage files.
It's OK to not set CFLAGS.

The_Pope · Tux's lil' helper Joined: 03 Jul 2016 Posts: 111

Uh, I was really early into the Gentoo install, so I just restarted it. I did it so many times that it doesn't bother me.

It couldn't have been the -O2 setting. The default make.conf comes with "-O2 -pipe" to which I add whatever resolve-march-native tells me, in front of -O2, and -fomit-frame-pointer after -pipe.
It definitely was due to me adding a CHOST value to make.conf - I didn't do it the second time and it just worked. I now have CPU_FLAGS_X86 defined, thanks to cpuid2cpuflags.

Your tutorial on compiling in a chroot:

NeddySeagoon · Posted: Sun Dec 25, 2022 11:57 am Post subject:

The_Pope,

The guide assumes that the host install is Gentoo. If its not, you can't share its bits.
Then you need a whole Gentoo install in the chroot.

I think the handbook covers the eventuality that the host install is systemd, which I have no experience of.
The handbook mount steps are therefore preferred as they work with either openrc or systemd.

The

The_Pope · Tux's lil' helper Joined: 03 Jul 2016 Posts: 111

Hu · Administrator Joined: 06 Mar 2007 Posts: 22918

--bind binds exactly the specified location. --rbind will do --bind as specified, then also find any mounts under the source and bind them to the corresponding locations under the destination. If the source has no mounts under it, then --rbind will have the same effect as --bind.

--make-rslave is to --make-slave as --rbind is to --bind. --make-slave marks the target as a "slave mount". Per man mount, a slave mount replicates mounts received from its master. When Linux boots, all mounts are private, so there is no need to use --make-slave. systemd has a (mis)feature that it likes to turn many mounts from private to shared. If running on a system where this was done, you may need --make-slave to prevent changes made inside the chroot from propagating back out of the chroot.