Difference between revisions of "Packaging/Consolidation"

From GalliumOS Wiki
Jump to: navigation, search
(Created page with "__NOTOC__ <div style="background-color:#fee;border:1px solid red;padding:0.2em;">'''WIP''': notes on packaging/image reorg.</div> == Goals == * Simplify support by building...")
 
 
(5 intermediate revisions by 2 users not shown)
Line 5: Line 5:
  
 
* Simplify support by building a single GalliumOS distribution image: <code>galliumos-xenon-2.1.iso</code>
 
* Simplify support by building a single GalliumOS distribution image: <code>galliumos-xenon-2.1.iso</code>
−
** Currently shipping six hardware-specific images
+
** Currently shipping nine hardware-specific images
−
*** baytrail, broadwell, broadwell-cbox, haswell, haswell-cbox, sandy
+
*** baytrail, broadwell, broadwell-cbox, haswell, haswell-cbox, sandy, braswell, skylake, samus
−
** Will add two to four more soon:
+
** '''ColtonDRG''': Only should be required for the iso. We can do any installed system stuff during installation and never think about it again at boot.
−
*** braswell, skylake, possibly samus and/or hidpi
 
  
 
== Prerequisites ==
 
== Prerequisites ==
Line 14: Line 13:
 
* Consolidate existing hardware-specific GalliumOS packages into a single package
 
* Consolidate existing hardware-specific GalliumOS packages into a single package
 
** (or possibly merge them all into <code>galliumos-core</code> and <code>galliumos-desktop</code>)
 
** (or possibly merge them all into <code>galliumos-core</code> and <code>galliumos-desktop</code>)
 +
** '''ColtonDRG''': Why? In the installed system, it would still be massively helpful to have those.
 +
** '''ColtonDRG''': Maybe keep each of the individual packages, plus a galliumos-hwsetup package that is only installed in the iso.
  
 
== Issues ==
 
== Issues ==
Line 19: Line 20:
 
* All customization in packages must be done at (first?) boot, not package install time
 
* 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
 
** Booting from the Live Image must be customized for the model
−
** Images are built on a single machince (VM, non-GalliumOS)
+
** Images are built on a single machine (VM, non-GalliumOS)
 
* Some customizations must be in place ''early'' in the boot process
 
* 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)
 
** Where not possible, they can be configured for the next boot (not useful for Live Image boot)
Line 38: Line 39:
  
 
* All images must boot a single kernel
 
* All images must boot a single kernel
 +
** '''ColtonDRG''': 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 ==
 
== Methods ==
Line 54: Line 56:
 
** 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.
−
* Configurator could detect user-changed files by timestamp and checksum
+
*** '''ColtonDRG''': ''should'' work for #2, with <code>systemctl daemon-reload</code>
−
** What to do if there is a newer GalliumOS update?
+
** Configurator could detect user-changed files by timestamp and checksum
 +
*** What to do if there is a newer GalliumOS update?
 +
* A kernel module that loaded early could handle everything necessary (except kernel selection)
 +
** Yikes

Latest revision as of 04:00, 20 December 2016

WIP: notes on packaging/image reorg.

Goals

  • Simplify support by building a single GalliumOS distribution image: galliumos-xenon-2.1.iso
    • Currently shipping nine hardware-specific images
      • baytrail, broadwell, broadwell-cbox, haswell, haswell-cbox, sandy, braswell, skylake, samus
    • ColtonDRG: Only should be required for the iso. We can do any installed system stuff during installation and never think about it again at boot.

Prerequisites

  • Consolidate existing hardware-specific GalliumOS packages into a single package
    • (or possibly merge them all into galliumos-core and galliumos-desktop)
    • ColtonDRG: Why? In the installed system, it would still be massively helpful to have those.
    • ColtonDRG: Maybe keep each of the individual packages, plus a galliumos-hwsetup package that is only installed in the iso.

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 machine (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

  1. kernel and kernel modules, e.g.:
    • /etc/modprobe.d/iwlwifi-opts.conf
  2. systemd config, e.g.:
    • /lib/systemd/system-sleep/wifi.sh
  3. services config, e.g.:
    • /etc/pulse/default.pa
  4. user config, e.g.:
    • /etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml

Limitations

  • All images must boot a single kernel
    • ColtonDRG: 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.
      • ColtonDRG: should work for #2, with systemctl daemon-reload
    • Configurator could detect user-changed files by timestamp and checksum
      • What to do if there is a newer GalliumOS update?
  • A kernel module that loaded early could handle everything necessary (except kernel selection)
    • Yikes
Retrieved from "https://wiki.galliumos.org/index.php?title=Packaging/Consolidation&oldid=1091"