- Arch-general - lists.archlinux.org

[arch-general] Extreme Minimalist Challenge
by Lonnie Cumberland 18 Nov '19

18 Nov '19

Hi All, I am new to Arch Linux and am hoping that this might be the direction that I need to look for a demo project that I am eagerly seeking to build and I really hope that someone can help me towards the right direction. The project is basically to have the absolutely smallest possible Linux distro (x86_64 based) that would be a type of LiveCD RAM-Based bootable system that has an Xserver and VirtualBox 6.0 but no real desktop running. I want it to boot directly into the VirtualBox 6.0 GUI. The other catch is that I need a system that has an extremely small footprint image and am hoping that the ISO could be between 150 MB - 200 MB in size, but of course even smaller is better. Its an ambitious project and I am seeking help on if Arch Linux may be a good starting point for the basic OS and Xorg server as well as any suggestions or advice that the mailing list might like to provide. Any suggestions or recommendations would be greatly appreciated. Best Regards, Lonnie

4 4

[arch-general] What happened to Arch Wiki recent changes news feed?
by Štěpán Němec 15 Nov '19

15 Nov '19

Hello, I noticed some time ago the feed stopped working. I used to follow it using the gwene.org gateway, but even following the link from https://www.archlinux.org/feeds/ to https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=rss sends me to a "Login Required" page. So apparently either the feed is gone for good intentionally (I hope not) and shouldn't be listed, or is broken and should be fixed? -- Štěpán

4 6

Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
by Amish 14 Nov '19

14 Nov '19

On 11/11/19 3:11 am, Arch Linux: Recent news updates: Giancarlo Razzolini wrote: > All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore. I would like to report an issue I faced due to this. Not an issue for everyone but can be an issue in a certain special cases. I have a custom package (in my custom repo) which modifies grub UI / menus (cosmetic change only) by putting some files in /etc/grub.d/ and regenerates /boot/grub/grub.cfg (by calling grub-mkconfig in package's post install script). This has been working fine from 2 years or so. Recently I released an update to that custom package but at the same time, upgrades to linux as well as linux-lts packages were also available in arch repository. And after upgrade, grub.cfg lost linux and linux-lts menu entries completely. What happened is: 1. mkinitcpio hook first removed vmlinuz-linux, vmlinuz-linux-lts and initrd files from /boot 2. My package got updated along with new versions of linux and linux-lts 3. My package's post install script ran grub-mkconfig but new vmlinuz files did not exist yet in /boot. So grub entries were not created for them. 4. mkinitcpio-install post transaction hook runs and copies kernel to /boot (but its too late for my post install scripts) So effectively this created an un-bootable system requiring manual booting. This is going to happen every time my package plus linux / linux-lts package get upgraded in the same pacman run. (i.e. this will not happen always but only in certain conditions) I know my issue is not common and I will also change my script to post transaction hook. But this is to warn anyone who has a custom package with post install script which looks for / expects kernel files in /boot. (like grub-mkconfig). Those scripts are going to break with the recent changes to kernel package and it would be advisable to put them in post transaction hook and that too after mkinitcpio-install scripts run. Regards, Amish

3 4

[arch-general] electron upgrade (7.1.1-1 -> 7.1.1-2) sort of broke functionality on several electron apps
by Javier 11 Nov '19

11 Nov '19

The 1st thing I noticed was that after the upgrade, the lectron apps no longer show up under the legacy tray, but instead on the more modern notification area (under LXQT). The 2nd thing, was the tray icons not doing any action. The 3rd thing, was that in order to use the electron apps, I had to call them with starting on tray, since the tray icons don't respond. And finally I can't try to iconify on tray, given the tray icons don't respond... Any one else experiencing the same? Other than just reverting to the prior electron, is there known workarounds for these issues? Has anyone faced them already, and dealt with them? Just in case a few electron apps experiencing the same: signal-desktop-bin whatsapp-nativefier slack-desktop Thanks ! -- Javier

1 1

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks
by Damjan Georgievski 11 Nov '19

11 Nov '19

> This has been discussed a bit on the dracut thread, as well on some other threads over time. > I *personally* don't like the complexity of kernel-install that much. I've now read this twice on Arch mail lists, so I have to ask, without any presumptions on my side, what are the arguments against kernel-install? I must say, I don't see much complexity in it. It's only a 184 line bash script[1]. And as added feature, it decouples the kernel install from the kernel package install (and pacman), also defines couple of easy-to-use config locations like /etc/kernel/cmdline But I guess I might be missing something. [1] especially compared to dracut (not that they do the same thing), which seems much more complex, and that complexity did introduce bugs - for which I've sent a PR -- damjan

3 2

[arch-general] New kernel packages and mkinitcpio hooks? What does this mean to the average user?
by David C. Rankin 11 Nov '19

11 Nov '19

All, I have read the latest note from 11-10-19 at archlinux.org, e.g. New kernel packages and mkinitcpio hooks https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/ However, I'm still left confused exactly "What this means to the average user?" When I read: <quote> All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore. The installation is done by mkinitcpio hooks and scripts, as well as removals. There is no need for any manual intervention. ... </quote> That tells me that I am not going to have to change the way I update kernels and that I won't have to do anything special to ensure all current hooks are run (mdadm_udev, etc...). The only changes I see in the mkinitcpio.pacnew file is that all double-quotes have been replaced by parenthesis, e.g. HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck" to HOOKS=(base udev autodetect modconf block mdadm_udev filesystems keyboard fsck) Which appears to effectively turn HOOKS into a bash array instead of a simple list/string. But beyond that I don't see anything that will have an impact on how kernels are installed or removed on update. Am I missing something there? -- David C. Rankin, J.D.,P.E.

3 3

Re: [arch-general] New kernel packages and mkinitcpio hooks
by Ondřej Hruška 11 Nov '19

11 Nov '19

Hi, I have a question regarding the kernel changes. It sounds like it might break my dm-crypt/luks setup with un-encrypted /boot partition, if the kernel is not in /boot anymore? Are there migration steps needed? I set it up exactly following the wiki. It is my understanding that it is the kernel who handles the password prompt and decryption. Or am I misunderstanding how it works? Ondrej Hruska

3 2

Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
by Kusoneko 11 Nov '19

11 Nov '19

On November 10, 2019 9:41:24 PM UTC, "Arch Linux: Recent news updates: Giancarlo Razzolini" <arch-announce(a)archlinux.org> wrote: >All our official kernels: linux, linux-lts, linux-zen and >linux-hardened, do not install the actual kernel to /boot anymore. > >The installation is done by mkinitcpio hooks and scripts, as well as >removals. There is no need for any manual intervention. > >The intention is to make the kernel packages more self-contained, as >well as making the boot process more flexible, while also keeping it >backwards compatible. > >As of now, only mkinitcpio has hooks for handling kernels installations >and removals. We do not ship any for dracut yet, but it will have >similar hooks in the near feature. > >URL: >https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/ >_______________________________________________ >arch-announce mailing list >arch-announce(a)archlinux.org >https://lists.archlinux.org/listinfo/arch-announce Hello, in the short time I've been subscribed to a bunch of these archlinux mailing lists, I've seen a few threads about mkinitcpio and dracut. What exactly are they for and what is the differences between the 2? Should one prefer to use dracut when equivalent support for it is implemented?

2 1

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks
by Amish 11 Nov '19

11 Nov '19

On 11/11/19 3:11 am, Giancarlo Razzolini via arch-dev-public wrote: > Hi All, > > As most of you have noticed already, the kernel packages had some > recent changes > where they do not install the kernel to /boot, as well as they do not > have any kmod [0] > nor mkinitcpio hooks anymore. Neither they do install mkinitcpio > presets [1]. > > ... > > Also, kernel removals are handled by mkinitcpio as well. We want to > make the boot process more > flexible, while also keeping it backwards compatible by default. There > are a few changes I have > planned for the next mkinitcpio release [4] that will help even > further to achieve this. > > Thank you for the detailed explanation. However I have a question related to this change. Due to e1000e related bug in kernel 5.3, few of systems that I manage are still on kernel 5.2.5. # pacman -Q kmod mkinitcpio linux linux-lts kmod 26-2 mkinitcpio 25-2 linux 5.2.5.arch1-1 linux-lts 4.19.61-1 I am planning to do full system upgrade except linux package. i.e. pacman -Syu --ignore linux --ignore linux-lts Would the change in mkinitcpio and /boot create a broken system for me? You have written it is backward compatible. So do you mean it is backward compatible with older linux / linux-lts? In short, can I upgrade the system while still keeping older linux packages (till the e1000e bug is not resolved)? Thank you Amish.

2 1

[arch-general] Archlinux fail2ban not working
by Maykel Franco 09 Nov '19

09 Nov '19

Hi, I have this rule: jail.conf: [app-user] enabled = true port = 443 filter = user-app logpath = /var/log/user-app.log findtime = 1200 bantime = 480 maxretry = 3 ------------------------------- filter.d: user-app.conf [Definition] failregex = Unknown User .* \(<HOST>:.*\) ignoreregex = ------------------------------- The content is logfile test /var/log/user-app.log: [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) ------------------------------- And when test it, not working: fail2ban-regex /var/log/user-app.log /etc/fail2ban/filter.d/user-app.conf Running tests ============= Use failregex filter file : user-app, basedir: /etc/fail2ban Use log file : user-app.conf Use encoding : UTF-8 Results ======= Failregex: 0 total Ignoreregex: 0 total Date template hits: |- [# of hits] date format | [6] {^LN-BEG}24hour:Minute:Second `- Lines: 6 lines, 0 ignored, 0 matched, 6 missed [processed in 0.02 sec] |- Missed line(s): | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) Whats wrong? Maybe the left timestamp? Thanks in advanced.

3 8