- Arch-releng - lists.archlinux.org

mailing list
by Ridwan Yoga 10 Jan '24

10 Jan '24

1 0

Venomfitness85@outlook.com
by Venom.onMicrosoft Virtual Entertainment 30 Nov '22

30 Nov '22

Venomfitness85(a)outlook.com Get Outlook for Android<https://aka.ms/AAb9ysg>

1 0

list
by Franco Frare 22 Nov '22

22 Nov '22

2 1

[arch-releng] (no subject)
by Lou B 18 Aug '21

18 Aug '21

Replying Sent from Yahoo Mail on Android

1 0

[arch-releng] (no subject)
by Lou B 07 Aug '21

07 Aug '21

2 1

[arch-releng] RFC: Automated Install
by brent s. 11 Jul '21

11 Jul '21

Hey, all. One of the things that I feel limits Arch Linux is the lack of an ability to kick off an unattended install. Sure, you can boot via PXE or the like, but the actual install does not take place. I'm in the middle of writing a tool that will do just this[0]. Much like RedHat's Kickstart or Debian's preseed, it uses kernel commandline options/parameters to fetch a configuration, parses that configuration, and then installs Arch according to that specified configuration. (Everything from partitioning disks to installing certain packages, etc.) Note that it isn't intended to make the install process "easier", per se; it intends to do it with *minimal to no user interaction*. One would need a very clear understanding and familiarity with the manual Arch install process to make use of this. The reason I'm even writing to this list instead of say, just having a package on the AUR as it makes little to no sense to run this software on anything but the install medium. In order to perform things like disk partitioning and the like, I'm thinking of using the udisks2 API via DBUS. Unfortunately, this means that it (udisks2) would need to be included in the live ISO image (or an alternate one would be spun up). Alternatively I could do it via libblockdev and gobject-introspection, but that is... significantly more complicated. As such, a couple questions: 1.) Is the RelEng team interested in adding such an unattended install ability to Arch Linux (especially one developed externally)? 2.) a.) Would udisks2 (and perhaps other libraries) be able to be added to the standard installer ISO? As of udisks2-2.9.2-1, for instance, this would add 14086.78 KiB (~14 MiB) to the squashed root (before squashing). 2.) b.) If not, would the amount of maintenance overhead required for mastering a separate ISO be worth the feature-add? Thank you in advance for your feedback. [0] In Golang so it could be easy to package, contained to a relatively localized install, and still relatively accessible to outside contributors. A couple years ago I had an implementation written in Python but this was discouraged as it would be far too complex to maintain, both from a codebase and a RelEng perspective (which, fair point). Golang also would allow for some cleaner parallel operations as well, though one may argue this is more of a nice-to-have in an install context. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info

6 10

[arch-releng] 回复： RFC: Automated Install
by George 10 Jul '21

10 Jul '21

fuck you ------------------ 原始邮件 ------------------ 发件人: "Arch Linux Release Engineering"<arch-releng(a)lists.archlinux.org>; 发送时间: 2021年7月9日(星期五) 下午4:50 收件人: "Arch Linux Release Engineering"<arch-releng(a)lists.archlinux.org>; 抄送: "Tim Meusel"<tim(a)bastelfreak.de>; 主题: Re: [arch-releng] RFC: Automated Install There exists a nice solution to install different linux operating systems, installimage: * https://github.com/virtapi/installimage (my version) * https://github.com/hetzneronline/installimage (the hetzner version) This can be executed via any live linux, for example a custom arch PXE: * https://github.com/virtapi/LARS This utilizes the mentioned .automated_script.sh to run installimage at multiple big ISPs. There is also a Python based API to manage DHCP, PXE and installimage configs via a web API at are processed by isc-dhcp (their ldap backend)/tftp-hpa with pxelinux/installimage * https://github.com/virtapi/marmoset Let me know if you've questions about any of these projects. The installimage and LARS repos also have flowcharts in their README.md. Cheers, Tim On 09.07.21 08:32, Li-Yu Yu via arch-releng wrote: > brent s. via arch-releng <arch-releng(a)lists.archlinux.xn--org>  202179-4r42cwx5hg7ac6t > 週五 下午2:24寫道： >> >> Hey, all. >> >> One of the things that I feel limits Arch Linux is the lack of an >> ability to kick off an unattended install. Sure, you can boot via PXE or >> the like, but the actual install does not take place. > Just FYI, maybe not what you want, but I have been sending the script= > kernel cmdline from the PXE server: > https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/root/.automated_script.sh > 

1 0

[arch-releng] reply to gitlab issues 139
by qinohe 07 Jun '21

07 Jun '21

Hi Archiso team, Thank you for considering my request at least. (see) https://gitlab.archlinux.org/archlinux/archiso/-/issues/139 I see the speech output should stay in second position. I must say, if this helps blind or visual impaired people I'm the last one to ask for it and gladly leave it like this. The syslinux change should be possible I hope ;-) Right now I have changed my PKGBUILD to adapt to the changes. I have created a fully automated create Archiso script. It can build both baseline / releng, that's why I asked for it! The script always builds with a fresh config, would there be any interest in it? It's not very short, 400+ lines, it is scripted in a similar way 'run_archiso' is... I could create a package and put it on Github, once I'm done with testing which could take a while still. Working on it for a few weeks now. Regards, Mark

1 0

[arch-releng] naming in baseline vs releng
by qinohe 03 Jun '21

03 Jun '21

Hi Archiso team, Thanks for Archiso so far it works great here, I have a request. My request is about naming in the baseline vs releng profile. I found a few files I would like to be changed if possible of course. 1. 'efiboot/loader/entries' in releng: Could you set '03-archiso-x86_64-ram-linux.conf' to '02-archiso-x86_64-ram-linux.conf' Set '02-archiso-x86_64-speech-linux.conf' to '03-archiso-x86_64-speech-linux.conf' 2. syslinux, could naming for baseline syslinux files be made similar to releng? Change syslinux-linux.cfg to archiso_sys.cfg Set syslinux.cfg in baseline to include archiso_sys.cfg instead of syslinux-linux.cfg. Building Archiso is fully scripted here and these 2 changes would shorten the build script with quite a few lines, which would be nice. I could change the nanes myself with yet another script every time I import a config (baseline / releng) But, it would be nice if every file in baseline follows the same naming as releng does. My guess is everyone that has building scripts would like that. Thank you very much in advance! Regards, Mark aka qinohe

1 0

Re: [arch-releng] Liveruser issue with 50.1-1
by Marco Obaid 04 Dec '20

04 Dec '20

> Message: 2 > Date: Thu, 03 Dec 2020 09:56:01 +0200 > From: nl6720 <nl6720(a)gmail.com> > To: arch-releng(a)archlinux.org > Subject: Re: [arch-releng] Liveruser issue with 50.1-1 > Message-ID: <1898427.4hlCs0VxHK@walnut> > Content-Type: text/plain; charset="utf-8" > > On Thursday, 3 December 2020 03:19:20 EET Marco Obaid via arch-releng > wrote: > > Greetings, > > > > After upgrading archiso to 50.1-1, I am running into an issue when > building > > the Archiso. The build stops at a point when it attempts to set > permissions > > (see below). The same process works fine in archiso 49-1. "liveruser" > > exists in both airootfs/etc/passwd and airootfs/etc/shadow. If I remove > the > > liveuser entries from the airootfs/etc/passwd and airootfs/etc/shadow, > the > > build resumes and the iso is built. > > > > ... > > [mkarchiso] INFO: Done! Packages installed successfully. > > [mkarchiso] INFO: Copying /etc/skel/* to user homes... > > [mkarchiso] ERROR: Failed to set permissions on > > 'work/x86_64/airootfs/home/liveuser'. Outside of valid path. > > > > Any advice on how to overcome this? Reviewing the documentation did not > > yield any success. > > > > profiledef.sh looks like this: > > > > #!/usr/bin/env bash > > # shellcheck disable=SC2034 > > > > iso_name=arcolinux-dev > > iso_label="arcolinux-dev-v21.01.1" > > iso_publisher="ArcoLinux <http://www.arcolinux.info>" > > iso_application="ArcoLinux Live/Rescue CD" > > iso_version="v21.01.1" > > install_dir="arch" > > bootmodes=('bios.syslinux.mbr' 'bios.syslinux.eltorito' > > 'uefi-x64.systemd-boot.esp' 'uefi-x64.systemd-boot.eltorito') > > arch="x86_64" > > pacman_conf="pacman.conf" > > airootfs_image_tool_options=('-comp' 'xz' '-Xbcj' 'x86' '-b' '1M' > > '-Xdict-size' '1M') > > file_permissions=( > > ["/etc/shadow"]="0:0:400" > > ["/root"]="0:0:750" > > ["/root/.automated_script.sh"]="0:0:755" > > ["/usr/local/bin/choose-mirror"]="0:0:755" > > ["/usr/local/bin/Installation_guide"]="0:0:755" > > ["/usr/local/bin/livecd-sound"]="0:0:755" > > ) > > > > Thank you in advance for any hints! > > > > Regards > > I think this is because the default work_dir (i.e. "work" in the current > directory) is not parsed with realpath. > To work around it for now, set the working directory explicitly using > mkarchiso -w /path/to/workdir . Most of the time you'll want to set it > explicitly to somewhere under /tmp/ anyway. > > Thank you! ... Initial test passed. I will be doing more testing this weekend. Will follow-up with results.

1 0