That’s not the real problem with an old installer. The main issue is that the packages in the iso containing the installer will get outdated.
In a few months that would mean really outdated for an Arch-based rolling distro. It’s when you attempt to update such an outdated release that problems start to appear. Same problems one would get when not updating Arch/Antergos for a long time.
I’m using grub-customizer for this. assuming you are using grub, it allows you to choose a kernel to boot as default. was using LTS myself for the same reasons as you just named, however I still ran into issues (short freezes). I moved to zen kernel and it seems to work even better than LTS.
You can find grub-customizer in the community repos, so it’s available for install through pacman
Here’s a link to the package in case you are curious https://www.archlinux.org/packages/community/x86_64/grub-customizer/
If you want to know which kernel you are currently running
uname -awill tell you that.
I guess there’s more about IP here that need to be discussed. The content of this very forum for example. I suggested simply doing a clone of it and hosting it somewhere else. However this also assumes the owners of the Antergos brand are ready to give their baby up for adoption :)
Retreat, regroup then charge back :)
There has to be someone with a strategy, willing to envision it and follow it through. I guess this thread here will mostly serve as brainstorming atm.
There are a few key roles that need to be filled:
- A strategy master
- Devs for the Forum
- Devs for maintaining the distro
- Other roles I can’t think off from the top of my head. The current distro holders are be the best qualified people to identify the needed roles.
All these roles require a strong commitment, so availability and stability of the ones filling them is a must.
Enthusiastic supporters are welcome I guess, but there is a need for people to adopt this child and stand by it while it continues its growth. In good and bad.
Here are a few thoughts on the steps needed for the forum:
Getting a decent hosting account is first. No idea about the requirements of such a project, but quality hosting is not that expensive these days.
Buying a domain is second
I guess simply moving the forum files and db-dump to another hosting company should do the trick of setting up a clone of this forum to ensure continuity. (Well there might be a need to make some adaptations to match the new domain, but that would be no issue for someone knowing what they’re doing.
Moving the forum to a new platform would be much more effort consuming, plus it might be hard to match all the features of the current platform to the new one.
Reinstalling kernel went smooth after editing vconsole.conf and setting KEYMAP=ro_std
@joekamprad I guess you are right,
sudo localectl set-keymap --no-convert ro_stdwould do the trick even better than just editing vconsole.conf (in case there are other places where the KEYMAP is being stored)
@manuel thanks for your input. your questions lead me in the right direction.
HOOKS="base udev autodetect modconf block keyboard keymap filesystems fsck"
Been doing a bit of research starting off from your question above (googled “HOOKS keymap”), and found
/etc/vconsole.conf to have the following content:
$ cat /etc/vconsole.conf KEYMAP=ro-std FONT=ter-v14b
After even more research (googled “vconsole.conf KEYMAP”) :
$ localectl list-keymaps | grep ro croat cz-lat2-prog dvorak-programmer euro euro1 euro2 mac-euro mac-euro2 ro ro_std ro_win sk-prog-qwerty sk-prog-qwertz
Apparently there is a typo in vconsole.conf as it requests ro-std instead of ro_std (this was automatically added during language install I guess, so must be a bug)
I’ve noticed lately this warning issued during kernel update. While the system is functional I was wondering if there is something I can do to stop the warning from ocuring.
I’m concerned about the line
cannot open file ro-std.
Here is a screenshot of my keyboard settings:
And here is the
LANG=en_US.utf8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE=en_US.UTF-8 LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL=
`.-/::/-`` .-/osssssssso/. :osyysssssssyyys+- OS: Antergos `.+yyyysssssssssyyyyy+. Kernel: x86_64 Linux 4.19.24-1-lts `/syyyyyssssssssssyyyyys-` Uptime: 34m `/yhyyyyysss++ssosyyyyhhy/` Packages: 1115 .ohhhyyyyso++/+oso+syy+shhhho. Shell: bash 5.0.0 .shhhhyso-/+++/-ss+++yyy+shhhhs. Resolution: 3520x1080 -yhhhh-/+++++/-ssso+++yyys+ohhddy: DE: XFCE4 4.12 -yddhhy-/+++/-syyss++++yyyyooyhdddy- WM: Xfwm4 .yddddhso++osyyyyys+++++yyhhsoshddddy` WM Theme: Cyanogen `odddddhyosyhyyyyyy++++++yhhhyosddddddo GTK Theme: Numix-Frost-Light [GTK2] .dmdddddhhhhhhhyyyo+++++shhhhhohddddmmh. Icon Theme: Papirus-Maia ddmmdddddhhhhhhhso++++++yhhhhhhdddddmmdy Font: Segoe UI 10 dmmmdddddddhhhyso++++++shhhhhddddddmmmmh CPU: Intel Core i5-3317U @ 4x 2.6GHz [55.0°C] -dmmmdddddddhhyso++++oshhhhdddddddmmmmd- GPU: Mesa DRI Intel(R) Ivybridge Mobile .smmmmddddddddhhhhhhhhhdddddddddmmmms. RAM: 2221MiB / 11631MiB `+ydmmmdddddddddddddddddddmmmmdy/. `.:+ooyyddddddddddddyyso+:.`
@rpallen in my bios there was a “Legacy and UEFI” entry, allowing any of them to be booted (citing from memory here). The mixed mode I was advising against.
USB ports are usually blue (the plastic inside the port is blue instead of the customary white or black).
See here: http://www.euask.com/topic/3768-How-to-tell-USB-20-from-USB-30-ports