system reproduction

iwuvkittens · 2025-08-21 10:50:58

are making scripts for installing arch good for system reproducibility, or should arch always be installed manually

mpan · 2025-08-21 11:02:53

Arch has to be installed manually in the sense, that you must be the one who takes the decisions and configures it. But there is nothing that prohibits you from automating the task.

This is the purpose of archinstall, which got Arch blessing. Or Ansible.

iwuvkittens · 2025-08-21 11:07:46

nope im talking about making ur own script

mpan · 2025-08-21 11:11:55

“But there is nothing that prohibits you from automating the task” includes your own scripts.

iwuvkittens · 2025-08-21 11:12:51

is it good to do it though or does it make you go dull relying on it

Succulent of your garden · 2025-08-21 11:51:05

I have done it and I recommend that to you if you think is worth the time invested on it. It really helps me install arch in 8 minutes or less, and have in every time the same system configurations quickly. If you like and love ricing your system [I also use my own dwm, so I do need to do the building manually, not anymore with the script] insanely as I and finish in having something unique to your needs, and also makes you more productive, then automating everything in there is a win in every sense.

Last edited by Succulent of your garden (2025-08-21 11:52:53)

iwuvkittens · 2025-08-21 11:59:14

i am already automating it but i was curious, also if you want to review my scripts and give me suggestions here

Succulent of your garden · 2025-08-21 12:33:36

You can reduce the soyfiles in your script to be less soy. for example I made the net config like this in my script:

#Network configuration part#
read -r -p "Please insert your desire hostname name: " Hostname
echo
echo "$Hostname" >> /etc/hostname
echo "127.0.0.1       localhost" >> /etc/hosts
echo "::1             localhost" >> /etc/hosts
echo "127.0.1.1       $Hostname.localdomain.$Hostname" >> /etc/hosts
systemctl enable NetworkManager.service

You can do something very similar to your soy files, but inside chroot, I'll send you the script latter. I'm in hurry now.

iwuvkittens · 2025-08-21 12:37:39

is it better to hardcode the contents of the files inside of the script or have it separated, because i have it separated currently

Succulent of your garden · 2025-08-21 18:58:25

It's going to depend with what are you working, in your case i think is better to just have one thing in one file if it's possible, but if for example you are working with secrets then probably then is better to setup the secrets in the os environment and not in the script, maybe you would like to push into a repository and oops, secrets being exposed.

Also it's going to depend how you are going to organize your script in your programming. I honestly think the best is organize everything with the better approach possible, so maybe you should ask to yourself, it is needed to separate the soyfiles from the script, or just put all on it and make good comments in the script ? That's up to you to be honest

Last edited by Succulent of your garden (2025-08-21 19:01:32)

Succulent of your garden · 2025-08-21 23:35:37

here is the first part of the script https://paste.ofcode.org/eg6rFLTTcTYBNqr8v2zwLH

Hope it helps you. The second part uses chrootPart.sh which must be in the same folder as the main script. This is because in the second part I wrote the files inside the new chroot environment as I said to you before. And made some decisions, for example if I want a user account, window manager, etc. It needed to be that way because if not you lost root privileges and the script fails, this is because you need the previous process to be related to have root permissions.

Last edited by Succulent of your garden (2025-08-21 23:37:50)

iwuvkittens · 2025-08-22 07:26:00

uhm it looks like you are using bashisms with /bin/sh shebang, also just running timedatectl just shows status by default it doesn't synchronize the clock

Succulent of your garden wrote:

you lost root privileges and the script fails, this is because you need the previous process to be related to have root permissions.

i should add a root check for good measure but i dont know because the script is only being ran by me + its supposed to be ran in the arch iso where you are already the root user

oh btw, my dotfiles script is separate

dotfiles installer
git ignore

i call sudo where necessary here because its supposed to be ran after rebooting into the new installation

Last edited by iwuvkittens (2025-08-22 08:20:31)

iwuvkittens · 2025-08-22 09:08:53

so for bios/uefi compat does this like fine?

script

Lone_Wolf · 2025-08-22 09:19:25

Not an arch discussion, moving to system administration.

Succulent of your garden · 2025-08-22 12:55:09

iwuvkittens wrote:

so for bios/uefi compat does this like fine?

Seems fine for me. Do you already test it ?

uhm it looks like you are using bashisms with /bin/sh shebang

Yes, I made it with bash since it's the default shell in arch iso. But since there is going to be sym linked somehow the /bin/sh this also works. But you get the point. If you want to use other shell for improve the speed that's fine, but my approach was to setup the less of things by myself. So just run the iso and run the script instantly. I tried to make it the more friendly user as possible.

also just running timedatectl just shows status by default it doesn't synchronize the clock

My bad you are right, nevertheless the system installation in the second part does enable ntp well, but I should put that comment with other words, and maybe improve the script to update the sys clock in that part. But most of the time in my case the sys clock is fine. Thanks for let point me that

i should add a root check for good measure but i dont know because the script is only being ran by me + its supposed to be ran in the arch iso where you are already the root user

read this https://bbs.archlinux.org/viewtopic.php?id=303359

Last edited by Succulent of your garden (2025-08-22 12:55:56)

iwuvkittens · 2025-08-22 13:48:31

hmm yes the default is linked to bash i guess in the arch iso it doesnt matter much but it feels wrong to have the shebang sh instead of just bash since there are bashisms theoretically it could be linked to something else in the arch iso either done manually or in a custom iso sooo

Succulent of your garden wrote:

Seems fine for me. Do you already test it ?

nope but it lgtm i should probably put -e back just incase

hmm actually before i do that i should probably do something like this:

[ -d /sys/firmware/efi ] && firmwaretype="uefi" || firmwaretype="bios"

looks better than?:

firmwaretype=$(cat /sys/firmware/efi/fw_platform_size)

product

Last edited by iwuvkittens (2025-08-22 13:58:02)

Succulent of your garden · 2025-08-22 15:26:17

iwuvkittens wrote:

but it feels wrong to have the shebang sh instead of just bash since there are bashisms theoretically it could be linked to something else in the arch iso either done manually or in a custom iso sooo

Well it is my personal script, anyone can use it or fork it, but the main reason is to have my "personal" setup as soon as possible when I need to do an installation, it's not like a product than I'm promoting that anyone can use it, it's just my personal stuff for my personal tastes. So therefore:

1) If you are going to use it, I'm assuming you checked before and saw the bashisms.

2) I need to check this, but in a chris titus tech streaming of many months [or years maybe] ago, someone said that if you put the shebang as /bin/sh in a bash script the bash script will go faster. TBH I need to check this, it doesn't make sense to me in some points.

3) I don't use custom iso. I can in windows but in arch I don't see any point in doing that.

4) default arch shell is bash, so I stick with that for the installation process as you know before.

May I ask you in which context you would like to use a custom arch iso ? I can get it in windows but in arch ? apart of maybe using not an x86_64 arch system where you could use it ?

Also assuming you are trying to be 100% posix complaint your script. Why not use dash instead of zsh in your script ? Is faster than zsh. Or it just that you know zsh better ?

[ -d /sys/firmware/efi ] && firmwaretype="uefi" || firmwaretype="bios"

mmm yeah I think that should work faster also, but not sure if you need to specify fully the /sys/fimrware/efi/fw_platform_size or just /sys/firmware/efi as you made.

Last edited by Succulent of your garden (2025-08-22 15:27:43)

iwuvkittens · 2025-08-22 15:33:19

hm my bin/sh is linked to dash

lrwxrwxrwx 1 root root 9 Aug 15 03:11 /bin/sh -> /bin/dash

note the output, so it runs through dash instead of zsh

Succulent of your garden wrote:

mmm yeah I think that should work faster also, but not sure if you need to specify fully the /sys/fimrware/efi/fw_platform_size or just /sys/firmware/efi as you made.

i could do that with the -f instead of -d but idk it doesnt matter

Succulent of your garden wrote:

2) I need to check this, but in a chris titus tech streaming of many months [or years maybe] ago, someone said that if you put the shebang as /bin/sh in a bash script the bash script will go faster. TBH I need to check this, it doesn't make sense to me in some points.

it will only go faster if bin/sh is linked to dash instead of bash, but you shouldnt use bin/sh shebang in a bash script instead you should use bin/bash because bashisms wont work in dash or anything thats similarly posix

Succulent of your garden · 2025-08-22 15:39:51

Oh so you are using dash. Okey I get it, you really like to embrace the perfomance

i could do that with the -f instead of -d but idk it doesnt matter

Well, that's easy to fix, since is the first part ot if your script is going to break if the path is wrong

it will only go faster if bin/sh is linked to dash instead of bash, but you shouldnt use bin/sh shebang in a bash script instead you should use bin/bash because bashisms wont work in dash or anything thats similarly posix

Well that is what I think also, but since the Chris Titus stream I was not so sure[ it could be missinformation without evil intentions] . Do you really think that's the case ? I also think that but if that's the case then yeah probably I would switch to /bin/bash

Last edited by Succulent of your garden (2025-08-22 15:41:04)

Arch Linux

#1 2025-08-21 10:50:58

system reproduction

#2 2025-08-21 11:02:53

Re: system reproduction

#3 2025-08-21 11:07:46

Re: system reproduction

#4 2025-08-21 11:11:55

Re: system reproduction

#5 2025-08-21 11:12:51

Re: system reproduction

#6 2025-08-21 11:51:05

Re: system reproduction

#7 2025-08-21 11:59:14

Re: system reproduction

#8 2025-08-21 12:33:36

Re: system reproduction

#9 2025-08-21 12:37:39

Re: system reproduction

#10 2025-08-21 18:58:25

Re: system reproduction

#11 2025-08-21 23:35:37

Re: system reproduction

#12 2025-08-22 07:26:00

Re: system reproduction

#13 2025-08-22 09:08:53

Re: system reproduction

#14 2025-08-22 09:19:25

Re: system reproduction

#15 2025-08-22 12:55:09

Re: system reproduction

#16 2025-08-22 13:48:31

Re: system reproduction

#17 2025-08-22 15:26:17

Re: system reproduction

#18 2025-08-22 15:33:19

Re: system reproduction

#19 2025-08-22 15:39:51

Re: system reproduction

Board footer