???
So the second option is that "if the argument $1 matches xfce4 or matches * (aka anything), then use startxfce4". That makes the remaining ones mere decoration.

For sure you meant them to be in a different order.

Good idea. The next steps towards that would be to

1. get the software held as a project at the Devuan Git Store, https://git.devuan.org, and

2. enjoy and digest https://git.devuan.org/devuan/documenta … aintainers

The old devuan/setnet project is still there but it hasn't been touched for some 3 years and it sure needs a new, active maintainer. I would suggest you discuss details with LeePen over IRC at #devuan-dev on libera.chat.

Firstly, when building you should use "make |& tee LOG" so that all output is captured in LOG. That makes it possible to review it all in more details.

In this case you will need to find the "error: ..." lines to figure out what the main problems are. All the warnings should really be tended to as well, but they doesn't stop the compilation.

I mostly got missing include files and needed to install:

# apt-get install libx11-dev libxpm-dev libxext-dev libxt-dev xbitmaps libxmu-headers

plus a light manual touch to remove some misplaced "##", and

now it looks like the link recipe of the Makefile needs polishing as well.

Yes.
You download that linux tar.gz, android-studio-2021.1.1.22-linux.tar.gz
un-tar it at your favourite place, then follow its instruction (to run studio.sh)
You can do all this as "normal user", i.e. you don't need to be root.
And then it'll keep downloading stuff .. some 6G maybe.
Seems to work fine (on chimaera).

Yes I think there was a mistake on that link;
the OP had this link: https://imgur.com/8MA5SQK which does include the "swosh"

Well, it operates on the current display, as known in the DISPLAY variable or given as command parameter, and it's typically run as the logged in user (not root) in a terminal window. I.e., open your terminal window and type the command there.

The program is xrandr, on the command line.

First just

$ xrandr

so you can see what your monitor outlets are called.

Second some configuration adjustment, e.g. like:

$ xrandr --output $mon2 --auto --right-of $mon1

which would enable $mon2 in its default resolution and logically place it top aligned to the right of $mon1.

Use man xrandr for information.

I've had some luck using "-pix_fmt yuyv422" and "scale=-1:720"

It's not unusal to get all sort of such problem if you happen to omit or forget to set up the virtual filesystems (esp. proc, sysfs and devpts) and device nodes in the chroot.

grub, for instance, will want to access both the disk device as a whole as well as the boot partition on that device, and it also wants that boot directory to be present on that disk device.

But you probably don't want that installation to mess with your "outside" boot so you should refrain from bind-mounting /dev. Rather you set up the appropriate device node for the target disk image under an alias name within the chroot; i.e., for example, use mknod naming it "sda" but with major/minor identifying the actual device (perhaps "sdf" for a removable, or "loop0" for a  duly set up disk image file).

@Altoid, to recover an DOS partition table, you clear the first 1 Mb of the device:

# dd if=/dev/zero of=/dev/sdf bs=1M count=1 conv=notrunc

NOTE THIS IS HARMFUL TO A DISK. Make sure doubly /dev/sdf is the disk at hand.

Then run fdisk to create a DOS partition table as per post #3, create a single primary partition of type 83 starting at 2048 and ending at end.

Thereafter run fsck as per superblock advice at post #7, trying some of the discovered superblocks.

Then mount sdf1.

Might work, though it doesn't recover overwritten files of course.

If it was me, I would run fdisk to set up a new partition table... I would make a dos partition table starting from scratch possibly deleting whatever entries it has, then using defaults, all on my habit of normally using the defaults for my disk partitioning.

The directory /etc/modbrobe.d holds files that are used by the modrobe program/command to in particular use given parameters to modules as they are loaded.

If you want to give parameters when usbcore is loaded, then you would typically make a file named usbcore.conf in that directory, and in the file write a line

options usbcore use_both_schemes=y

That line tells modprobe to use that parameter setting when loading the module.

In order to take effect, the module must first be unloaded before loaded again; the parameter setting applies at loading.

Some modules allow some parameters to be changed also for a loaded module. You would do that with a command similar to

# echo y > /sys/module/usbcore/parameters/use_both_schemes

The redirection must be done as root of course.