archlinux / archinstall Goto Github PK

As mentioned in #61, support for package groups doesn't work.
The idea here is that it should be supported, we simply never verified that the archinstall.find_package() function can verify those, and apparently it can't. So we have to use another API endpoint or multiple to support this.

The backplane supports it already, as the packages are sent as a unfiltered string to pacman -S more or less.

Would be neat, if the instruction set could influence which git branch to run from.
If the instruction arguments have "git" : "experimental" it would save me a bunch of time having to re-create ISO's and/or abort the installation quickly to re-run with the correct branch.

When showing "Select one of the above disks (by number):", in the list above, show the file format on those disks. And a human readable filesize perhaps. Would make it a lot easier to understand which disk is which (even tho you can ctrl+alt+f2 to run fdisk -l yourself).

Assuming the following, that someone runs the scripts/library on a docker installation or re-running it after already performing an installation. It would be nice if the installer could run again and run different profiles scenarios. But that requires the mount points to be pointed towards the correct place.

Which, perhaps the archinstall.Installer() should take care of.

As mentioned in #61:

An option to select the timezone / enable NTP would be nice.

The feature is pretty straight forward and not a bad idea.
It's mainly been put on hold because it's an easy thing to configure while inside the machine, but it makes sense to put it in now.

• Guess time-zone in examples/guided.py based on the locale selected would be nice, but not a requirement
• Listing time-zones would be nice and almost a requirement.

Makes more sense, it's a evolutionary naming decision which is BS for "I didn't know what to call it" at the beginning.

Add hardware helpers, preferably in lib/hardware.py to detect certain hardware features.
Such as ssd/nvme detection, which should be the basis for opting in for btrfs for instance, and default to ext4 or something similar if anything else (as a very generalized example).

Thanks to @grazzolni for this idea.

Hi,

I was testing the guided installer in a virtual machine, but it seems that the installation fails during package installation. I used pip install archinstall==2.0.6rc11 and python -m archinstall guided on the current Arch Linux installation image.

Installing packages: ['vim', 'gdb', 'radare2', 'pwndbg', 'tmux']
Error in profile guided: 'list' object has no attribute 'items'
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/archinstall/__main__.py", line 65, in run_as_a_module
    exec(profile)  # Is this is very safe?
  File "<string>", line 240, in <module>
  File "/usr/lib/python3.8/site-packages/archinstall/lib/disk.py", line 192, in __exit__
    raise args[1]
  File "<string>", line 240, in <module>
  File "<string>", line 66, in perform_installation
  File "/usr/lib/python3.8/site-packages/archinstall/lib/installer.py", line 78, in __exit__
    raise args[1]
  File "<string>", line 58, in perform_installation
AttributeError: 'list' object has no attribute 'items'
python -m archinstall guided  41.04s user 18.26s system 25% cpu 3:51.50 total

Full output here.

Edit: When do not select any additional packages, I get the following error:

Error in profile guided: 'packages'
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/archinstall/__main__.py", line 65, in run_as_a_module
    exec(profile)  # Is this is very safe?
  File "<string>", line 240, in <module>
  File "/usr/lib/python3.8/site-packages/archinstall/lib/disk.py", line 192, in __exit__
    raise args[1]
  File "<string>", line 240, in <module>
  File "<string>", line 66, in perform_installation
  File "/usr/lib/python3.8/site-packages/archinstall/lib/installer.py", line 78, in __exit__
    raise args[1]
  File "<string>", line 52, in perform_installation
KeyError: 'packages'

Need to configure the awesome-menu in the workstation template.

Instead of STDIN being available only for the password prompt, make it so it parses through any argument to fill it in.

ála traditional guided installations I presume.

see title (I'm one of those people)

During installation, if a wrongly inputted package name is given.
It will take time for any error messages to pop up, and the installation will even continue up to the stage of strapping in additional packages.

It might be worth creating a package helper (crude, simple, nothing fancy) to search for package names and verify that they do exist in the upstream package database - prior to continuing the installation.

A novice mode/template.

Quote

aur helper, a gui, essential fonts, internet stuff, etc

A quote from #61:

A simple option to configure networking would also be useful, e.g., enabling DHCP via systemd-networkd.

We should support at least two network managers in this case, systemd-networkd for sure but perhaps also NetworkManager. Both as optional additions. Either way, supporting configuring network (at a very basic level) would be invaluable for almost any installation.

If a gateway is detected, use a geoip library to determain to the best of our ability where the user is coming from. This in order to determain the keyboard layout and suggest mirrors etc.

If two templates have the same "step name" or key, the inherited template should not replace the step of the current template.

"ubuntu" inherits "workstation"
"ubuntu" should replace whatever "desktop"-environment step "workstation" has for isntance. And not the other way around(?).

Bring back the configuration summary shown just prior to starting the formatting.
It was removed during the great .json purge, previously print(conf) was shown containing the selected config.

archinstall.Installer.show_configuration() perhaps?

I got this error after following the install instructions from the readme:

pip install archinstall
python -m archinstall guided

I also accidentally booted into BIOS mode, but retrying in EFI gives me the same error.

Currectly, there's only one trigger supported. And that's per-command-trigger set up by archinstall.py when it detects a chroot request.

However, it would be neat if the trigger-list became a normal list, and triggers from the template got merged into said list so that the template creator can choose multiple steps if need be.

Example: Say a command requires two inputs, "name" and "password". Currently, there's no way of supplying multiple triggers. Fix!

According to a harmless and rather fun joke on reddit mentioned by u/parkerlreed:

So FATT32 is the new hotness for rootfs? :D

Adding partition to BlockDevice(/dev/sda)
Adding partition to BlockDevice(/dev/sda)
Formatting Partition(path=/dev/sda1, fs=None, mounted=None) -> fat32
Formatting Partition(path=/dev/sda2, fs=None, mounted=None) -> ext4
Mounting Partition(path=/dev/sda2, fs=fat32, mounted=None) to /mnt
Mounting Partition(path=/dev/sda1, fs=fat32, mounted=None) to /mnt/boot
A new package mirror-list has been created: /etc/pacman.d/mirrorlist
Installing packages: ['base', 'base-devel', 'linux', 'linux-firmware', 'efibootmgr', 'nano']

It actually mounted EXT4 just found that funny

/dev/sda2 on /mnt type ext4 (rw,relatime,stripe=8191)

At first glance /dev/sda2 which should be ext4 in a unencrypted configuration, should actually have the status fs=ext4.
The issue is disk.py #L133-L136 which sets:

elif filesystem == 'ext4':
	if (handle := sys_command(f'/usr/bin/mkfs.ext4 -F {self.path}')).exit_code != 0:
		raise DiskError(f'Could not format {self.path} with {filesystem} because: {b"".join(handle)}')
	self.filesystem = 'fat32'     <-----------

And if we check the partition.filesystem at any given point after this, it will give wrong indications.
It does get mounted correctly, it's just the soft login ontop that will break after this point if ever used.

Currently, one of the bigger limitations are that the installer/guided templates only support UEFI with Systemd-boot as the default bootloader.

We'll need to add archinstall.MBR as an alternative to:

with archinstall.Filesystem(harddrive, archinstall.GPT) as fs:
    ...

And installation.add_bootloader() should probably take a parameter for which bootloader to install. Currently it doesn't take any arguments, so adding one won't brake anything. Suggestion: installation.add_bootloader("grub")

Currently, all the log data is stored in ~/.cache/archinstall/workers/<id>.
That's a little bit to technical for each and everyone most likely, especially considering the targeted users.

This goes hand in hand with #45 (Create a installer.help extension).
But this issue revolves around how to gather the logs for sending.

It's also not very well documented, both in terms of how to find the logs, but also how to submit them or even what to submit. So that needs a big overhaul.

Currently, encrypted drives default to using btrfs inside.
Un-encrypted drives default to ext4.

There's no real reason why these has to be forced upon the users.
But for development purposes (and test support of different FS's), this was chosen as a starting point.

Anyone can use the library to format whatever they want, but this is the default of minimal_installation() and the guided.py template currently. All we have to do is expand on guided.py and add another question, and test the support in the lib to support other formats.

The current design goal is to support:

• Format the entire drive
• Format entire drive but keep "unsupported" partitions (windows, mac etc)
• Use the current setup as-is
  • Autodetects pre-mounted partitions and uses them, or
  • Asks which partition to mount where

Just getting back into this project, have been busy wrapping up some things for work.

One of the things I noticed the last time I was diving into this project, is that the sys_command class has a huge implict set of dependencies on things passed in via kwargs. Is there a reason for this?

It seems like it only ever looks at a few keys within kwargs

• debug
• emulate
• events
• ignore_errors
• on_output
• suppress_errors
• worker
• worker_id

Having those be explict arguments should make things easier to document. I also worry a bit about kwargs being passed through. For example right now the all_disks function passes through kwargs, but it's not clear that the kwargs for all_disks should be passed to sys_command, and most likely the extra partitions key should not be passed along.

if you're amenable to this I can fix this and send over a PR.

When prompted by the installer script to select a pre-programmed profile, selecting option 1 (desktop) and then trying to skip by pressing enter crashes the installer.

When prompted (using the guided.py examples) for AUR support.
The AUR support needs to temporarily grant itself password-less sudo permissions. This because we don't want to accidentally set a root password and something goes wrong. And cleaning up a text file should be easier.

But in all haste of 2.0, the AUR process was simply lifted from the v1.0 branch, which may have the same issue.

Just add a little 5-10 sec timer between the settings being shown and the wiping+deploy actually starts.

all most all of the profiles use A desktop environemtn using "Awesome" window manager. even though the should be separate descriptions pertaining to the specific environment.

Hi,

I'm creating a package of this on Arch and I would like to ask for PGP signed releases to be created. If possible, also add the keys to the release artifacts. Also, it would be a bonus if all commits and tags were signed. I've noticed a few of the previous tags were signed, but not the most recent ones.

Another thing that would be nice to have, is if we could build a chain of trust for all the keys that could make releasesl, not sure if one already exists.

Thanks

Something along the lines of archinstall.Installer.help() which would print all the debug statistics needed.
And potentially a very optional archinstall.Installer.submit_debug(), but not until thoroughly thought out with better masking of passwords and stuff. The default archinstall.log function should probably have a filter=True for credential sensitive log data.

Since AUR isn't officially supported, we need to remove it before it can be offered to a wider public.

Fuzzy title..
Make it so LUKS is default on, but add an option some where to turn it off.
There are rare edge cases where disk encryption won't work for unattended stuff and we can accept the risk of not having disk encryption. But default should be to always have it enabled!

So far, the instruction set has only come from the online github repo.
Adding support for the local files would greatly help.

Now that archinstall is packaged on the official repos, it would be nice to have man pages for it as well. I think that, with some adaptation, they could be created from the docutils documentation.

Some template steps might deliberately cause a error.
Forcing he installer to crash. Having a "ignore-errors" : True makes sense.

Latest master branch have an issues in guided.py#59 that incorrectly assumes 'profile' exists when in fact no profile was selected.

This is partially a dummy issue to test signed PGP releases. #74

The search feature by entering ?<enter> is a bit unclear.
And the scrollback history via Shift+PageUp is not always available (in most tty's).

It would there for be nice to break up larger lists into columns over the width of the terminal, as well as make the input text more descriptive.

As pointed out over at reddit, the preferred method of launching KDE appears to be not via xorg-xinit, but a displaymanager (much like Gnome which is launched via gdm).

The thing we need to change is profiles/applications/kde.py among other things. And investigate the most supported method in the KDE community.

SDDM appears to be the recommended for Plasma.

Add a silent parameter, making the script as less noisy as possible on the network.
The name of the parameter might be discussable, but should be added at least.

When running in --offline mode, turn every online feature off.
When in --online mode so to speak, mute only automated features like country guessing and stuff. But leave the online-template fetching active.

Imported profiles doesn't work with URL's.
Root cause is Profile.load_instructions() which gives the URL as a file name.

The reason for this bug is when run in module-mode, the working path is wonky (will look at it) and there for it resorts back to HTTP-lookup.

There's a issue over at Unix Stackexchange on the topic.

Essentially it boils down to when /run is mounted into the chroot, and you chroot /mnt /bin/bash. Something with /run breaks name resolves if you're not root.

I'm seeing a lot of splitting the output of sys_command using it's iterable, only to immediately rejoin it via b''.join(sys_command(...)). Is there a reason you've used this pattern so widely, since it seems to serve no purpose.

https://downforeveryoneorjustme.com/archlinux.life?proto=https

Can't reach archlinux.life.

Would you be interested/open to contributions that allow for installations that need to co-exist with other installations of operating systems?

Based off #65, it would be nice with a wifi option.
Since laptop users and other devices more or less defaults to using wifi rather than ethernet, this would be a welcome addition I think.

During installation, the guided template lack the option to select local mirrors.
rankmirrors doesn't do a good enough job of selecting a appropriate mirror, causing:

Some NVME drives are to quick to respond to parted and mkfs, which makes them unavailable when cryptsetup execution attempts to encrypt the drive. The underlying issue is that the disk haven't entered "ready state" in kernel in between sys calls.

A simple time.sleep(5) at luks() proved to solve the issue. A better approach would be to assert and evaluate the state of the drive and release a lock whenever the devices becomes ready.

Temporary solution: Re-run the installation as it's more of a race condition or skip encryption and manually encrypt.

Correction: This has to do with the formatting, not encryption. The disk formatting is to quick on some drives. Fix is on it's way although this happens rarely on most systems.

As of now, the intention of make_offline took a slightly different turn.
It's need came up when we tried to incorporate AUR packages into a ISO/Offline environment.

However, it does the job of building AUR packages and putting them into the ISO pretty neatly.
What it doesn't do, is make a offline-installable version of Arch Linux from the ISO (much like the other Linux distro's got, a CD jamed with all the packages).

So rename this script to ./AUR, and create a new ./make_offline that actually creates a local-hosted mirror on the ISO, that the ISO can use to install itself from. Including others who point their mirror to the ISO. (this is tested and works, that commit is here https://raw.githubusercontent.com/Torxed/Scripts/a7119ecb29b6e9b65936875a051b35d46de57c7f/systemd/offline_arch_mirror/make_mirror)