Difference between revisions of "Packaging/Consolidation"
From GalliumOS Wiki
Line 55: | Line 55: | ||
** Existing <code>galliumos-laptop</code> service does some model detection, but it is late in the boot | ** Existing <code>galliumos-laptop</code> service does some model detection, but it is late in the boot | ||
** Should work well for Customization categories #3 and #4; ''might'' work for #2, probably can't work for #1. | ** Should work well for Customization categories #3 and #4; ''might'' work for #2, probably can't work for #1. | ||
+ | *** ''should'' work for #2, with <code>systemctl daemon-reload</code> | ||
** Configurator could detect user-changed files by timestamp and checksum | ** Configurator could detect user-changed files by timestamp and checksum | ||
*** What to do if there is a newer GalliumOS update? | *** What to do if there is a newer GalliumOS update? | ||
* A kernel module that loaded early could handle everything necessary (except kernel selection) | * A kernel module that loaded early could handle everything necessary (except kernel selection) | ||
** Yikes | ** Yikes |
Revision as of 06:26, 22 August 2016
WIP: notes on packaging/image reorg.
Goals
- Simplify support by building a single GalliumOS distribution image:
galliumos-xenon-2.1.iso
- Currently shipping six hardware-specific images
- baytrail, broadwell, broadwell-cbox, haswell, haswell-cbox, sandy
- Will add two to four more soon:
- braswell, skylake, possibly samus and/or hidpi
- Currently shipping six hardware-specific images
Prerequisites
- Consolidate existing hardware-specific GalliumOS packages into a single package
- (or possibly merge them all into
galliumos-core
andgalliumos-desktop
)
- (or possibly merge them all into
Issues
- All customization in packages must be done at (first?) boot, not package install time
- Booting from the Live Image must be customized for the model
- Images are built on a single machince (VM, non-GalliumOS)
- Some customizations must be in place early in the boot process
- Where not possible, they can be configured for the next boot (not useful for Live Image boot)
Customizations
Categories
- kernel and kernel modules, e.g.:
-
/etc/modprobe.d/iwlwifi-opts.conf
-
- systemd config, e.g.:
-
/lib/systemd/system-sleep/wifi.sh
-
- services config, e.g.:
-
/etc/pulse/default.pa
-
- user config, e.g.:
-
/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml
-
Limitations
- All images must boot a single kernel
- Maybe not - We can have a GRUB menu to select an appropriate kernel for device class. Also thought of a way of detecting the device and selecting the correct kernel, maybe kexec?
Methods
Detection
- Model detection via
dmidecode -s system-product-name
-
Peppy
-
- CPU detection via
dmidecode -s processor-version
as fallback-
Intel(R) Celeron(R) 2955U @ 1.40GHz
-
- Display resolution detection for selecting HiDPI pkg?
- Some models (YUNA) ship with identical CPU (3205U) for both 1366x and 1920x displays
- Can't detect by the usual methods (xdpyinfo, xrandr) in early boot -- no X server running
Process
- A
systemd
one-shot could set config files before reaching an early target- Existing
galliumos-laptop
service does some model detection, but it is late in the boot - Should work well for Customization categories #3 and #4; might work for #2, probably can't work for #1.
- should work for #2, with
systemctl daemon-reload
- should work for #2, with
- Configurator could detect user-changed files by timestamp and checksum
- What to do if there is a newer GalliumOS update?
- Existing
- A kernel module that loaded early could handle everything necessary (except kernel selection)
- Yikes