elementaryOS could be added with pantheon, elementary-photos, etc..
for example, kgamma5
no longer exists
It would be great if setup-desktop would support sway as well. This is a draft and meant to spark a little bit of conversation, e.g. if this is wanted, what scope it should have, and where parts of the new functionality would go best.
Setting up the community repositories is, for now, just a copy-paste of setup-xorg-base, but should probably be factored out into another script, either a new or an existing one.
Most of what is in the first draft is directly taken from the wiki:
The commit currently has a few TODO's. I'm not sure how to progress with most of these as I'm unfamiliar with the general philosophy of setup-desktop specifically.
Are there any thoughts on this? A bit of feedback would be appreciated!
Add loongarch64 support.
@dbradley Do I understand you correctly that you think we should merge this MR as it is? I am enabling DRC_DRV_EFI everywhere it is possible.
For x86 and x86_64 only 2 RTC modules are required to be compiled into both the linux-lts and linux-virt kernels:
rtc-cmos
andrtc-efi
(UEFI) as RTCs are standardised for PCs.
We already have CONFIG_RTC_DRV_CMOS=y
for both lts and virt kernels for x86_64 and x86. Apparently we also have it enabled for lts armv7.
CONFIG_RTC_DRV_EFI
is only available for ARM platform. It has a ! CONFIG_X86
dependency. We currently have it enabled for -virt kernels. lts aarch64 has it available as module, but it sounds like a good idea to enable it for both aarch64 and armv7.
For Raspberry Pis ...
Can you please report this to https://github.com/raspberrypi/linux/issues and suggest enable the needed RTC drivers in their defconfigs. Alpine will pick this up downstream.
For non-server non-VM Arm things are more complicated - however first there are separate Alpine kernel packages for some devices (i.e. linux-asahi, linux-elm, linux-gru) and so those can be excluded from linux-lts requirements, also some/many SBCs don't have a RTC on-board, for those that do it is likely that 2 or 3 RTC drivers in linux-lts will cover the majority of SBCs.
Are you saying that we should build separate kernels for every non RPI hardware that does not use RTC_DRV_CMOS, RTC_DRV_EFI?
I think it would be nice if we could find a way to make RTC drivers work as modules one way or the other and not rely on having it built in to kernel as a hard requirement.
I wonder if it would make more sense to set system clock from rtc from initramfs
Also if you go down this route then the alternative initramfs' in Alpine (booster and dracut) would also need to implement the same as well to ensure clocks are set early in boot...
I'm not sure how this works to be honest. I was under the impression that CONFIG_RTC_HCTOSYS depends on RTC driver to be compiled into kernel and not as module?
That is my understanding.
What happens if
CONFIG_RTC_HCTOSYS=y
but the /dev/rtc0 driver is a module and loaded later? Will kernel change the system time when rtc0 appears?
No, the kernel sets the system clock during kernel initialisation, if no RTC device exists at that stage then obviously it will not set the system clock then and it does not retry later. That is why the relevant RTC modules needs to be compiled into the kernel for this functionality to work.
What I want to avoid it to build in RTC drivers for every single RTC chip out there. I want the hardware drivers built as modules.
there are 92 RTC_DRV for aarch64. I don't think we should enable them all in kernel.
For x86 and x86_64 only 2 RTC modules are required to be compiled into both the linux-lts and linux-virt kernels: rtc-cmos
and rtc-efi
(UEFI) as RTCs are standardised for PCs.
For Raspberry Pis the majority (90%+ at a guess) of aftermarket RTC addons use the rtc-ds1307
driver which is currently the only RFC compiled into the linux-rpi* kernels. The RPI5 is the first RPI to come with an onboard RTC, I'd expected to see a (2nd) RTC driver compiled into the linux-rpi* kernels for that but there (currently) is not - the rtc-rpi
driver was added to the 6.6.18 patch last week but the defconfig does not have it enabled at all. I don't think having 2 RTC drivers enabled in the RPI kernels is an issue (if you're worried in general about "unneeded" compiled in kernel drivers then why are there not separate kernel configs for the various RPI models? Currently there is one kernel config used across all RPI models with varying hardware).
For aarch64 in general there are 3 scenarios - "proper server machines", VMs, and SBCs. As Arm SBSA (or whatever it is called these days) has standardised on UEFI for servers then only rtc-pl031
and rtc-efi
drivers would be required (in both linux-lts and linux-virt). For non-server non-VM Arm things are more complicated - however first there are separate Alpine kernel packages for some devices (i.e. linux-asahi, linux-elm, linux-gru) and so those can be excluded from linux-lts requirements, also some/many SBCs don't have a RTC on-board, for those that do it is likely that 2 or 3 RTC drivers in linux-lts will cover the majority of SBCs.
For RISCV machines I'm not that familiar but some (many?) of those support UEFI and so adding rtc-efi
makes sense. Again some lower-end RISCV SBCs may not have an RTC at all, for those that do then again 2 or specific drivers are likely to cover the majority of requirements.
I want the hardware drivers built as modules.
To clarify, are you referring to Arm specifically or to all archs and to linux-lts or also linux-virt? i.e. x86 & x86_64 only need two RTC drivers to be compiled in for all scenarios, aarch64 linux-virt likely only needs two RTC drivers. It's only armv7 and aarch86 linux-lts where things get potentially complicated but in reality not really so.
there are 92 RTC_DRV for aarch64. I don't think we should enable them all in kernel.
I'm not sure how this works to be honest. I was under the impression that CONFIG_RTC_HCTOSYS depends on RTC driver to be compiled into kernel and not as module?
What happens if CONFIG_RTC_HCTOSYS=y
but the /dev/rtc0 driver is a module and loaded later? Will kernel change the system time when rtc0 appears?
What I want to avoid it to build in RTC drivers for every single RTC chip out there. I want the hardware drivers built as modules.
I wonder if it would make more sense to set system clock from rtc from initramfs, which would correspond to CONFIG_RTC_HCTOSYS behavior.
What would be your reasoning for not relying on the kernel functionality?
e.g. without the kernel setting system clock early in boot then kernel buffer/dmesg timestamps may be incorrect.
More background info here: https://wiki.gentoo.org/wiki/System_time#In-kernel_method
I am using version 3.19.1. When installing the system with
setup-disk -e -m sys /dev/sda
# -e for encrypted
# -m for system disk
The script creates an encrypted system partition and an unencrypted swap partition, mounted at boot.
Wouldn't a plain-text swap partition leak the key material, and other confidential information, when the system is running? At the very least, I think we can suggest -s 0
for no swap for this scenario and use a swap file instead.
Natanael Copa (60f1cedb) at 26 Jan 13:17
==== release 3.17.2 ====
Natanael Copa (f976aafa) at 26 Jan 13:17
==== release 3.17.2 ====
We need fix busybox netcat to support -U
option for this so we can read the lxd metadata from the unix socket.
Currently setup-alpine adds the networking init.d to the boot runlevel:
https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in?ref_type=heads#L229
Is there a specific reason why "boot" rather than "default"? For my own (non setup-alpine installed machines) I've always enabled networking in the default run-level.
I suppose the response is "no"
setup-xorg-base ${BROWSER:-firefox} $(apk info --quiet --depends \
gnome gnome-apps-core) "$@"
It wants to find gnome packages on apk info subshell but 'setup-xorg-base' will enable community repository later. So you need to run setup-desktop twice for gnome works.
setup-desktop gnome
I checked which packages should be installed after setup-desktop gnome
and they included gnome-apps-core which contains gdm and gnome-console — most important packages for gnome desktop, that were not
setup-xorg-base ${BROWSER:-firefox} $(apk info --quiet --depends \
gnome gnome-apps-core) "$@"
It wants to find gnome packages on apk info subshell but 'setup-xorg-base' will enable community repository later. So you need to run setup-desktop twice for gnome works.