Better support for Chromebooks

Chromebooks do have very limited hardware in terms of storage and RAM. But it is still the cheapest solution to a truly open source notebook, as it allows to replace its coreboot based bootloader with your own coreboot and payload (f.e. Tiano Core or Seabios).

By installing a standard proposal of Tumbleweed or Leap with btrfs you will be left with about 2-3 GB of free storage on a 16 GB eMMC storage for installing packages and saving files. In addition to that many features like hibernation, suspend and function buttons (TTY switching) don't work out of the box.

There is a special Ubuntu based distribution for Chromebooks available called "Gallium OS" (https://galliumos.org/). They do have a lot of patches and some neat configuration for XFCE4 to make it perfectly work on Chromebooks by still looking very nice and offering a lot of storage. But you know what it lacks? Correct, some Geeko love ;)

In this project following steps could be done to improve the openSUSE support on Chromebooks:

  • port Chromebook specific patches of "Gallium OS" to Factory and upstream them if necessary/possible
  • custom setup proposal for Chromebooks in Tumbleweed or a custom Image for Chromebooks
    • including a modified XFCE configuration with openSUSE branding
    • minimum selection of packages necessary for a proper desktop session (f.e. replace LibreOffice with smaller solutions)
  • openSUSE Leap 15 Image for Chromebooks
    • including a modified XFCE configuration with openSUSE branding
    • minimum selection of packages necessary for a proper desktop session (f.e. replace LibreOffice with smaller solutions)

Looking for hackers with the skills:

kiwi kernel linux ux ui yast

This project is part of:

Hack Week 17

Activity

  • about 7 years ago: tdz liked this project.
  • over 7 years ago: michals liked this project.
  • over 7 years ago: SLindoMansilla liked this project.
  • over 7 years ago: aspiers liked this project.
  • over 7 years ago: mbrugger liked this project.
  • over 7 years ago: suntorytimed liked this project.
  • over 7 years ago: suntorytimed added keyword "ui" to this project.
  • over 7 years ago: suntorytimed added keyword "yast" to this project.
  • over 7 years ago: suntorytimed added keyword "kernel" to this project.
  • over 7 years ago: suntorytimed added keyword "linux" to this project.
  • over 7 years ago: suntorytimed added keyword "ux" to this project.
  • over 7 years ago: suntorytimed added keyword "kiwi" to this project.
  • over 7 years ago: suntorytimed originated this project.

  • Comments

    • suntorytimed
      over 7 years ago by suntorytimed | Reply

      I can provide test hardware (Dell Chromebook 11 Education and Asus C200MA) with Coreboot and Tiano Core on it.

    • suntorytimed
      over 7 years ago by suntorytimed | Reply

      The more I think about it, the more I want to do this as a hacker myself. Too many project ideas but not enough time add-emoji

      • mbrugger
        over 7 years ago by mbrugger | Reply

        You know that we have support for an arm based chromebook? https://en.opensuse.org/HCL:ARMChromebook ask @algraf for more info add-emoji

    • jevrard
      over 7 years ago by jevrard | Reply

      Keep me informed, I am following GalliumOS (waiting for the new version!), and I'd be pretty happy to know more about your plans.

    Similar Projects

    pudc - A PID 1 process that barks to the internet by mssola

    Description

    As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:

    • The backend is written in a mixture of C and RISC-V assembly.
    • The backend is actually PID1 (for real, not within a container).
    • We poll and parse incoming HTTP requests ourselves.
    • The frontend is a mere HTML page with htmx.

    The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.

    I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.

    Goals

    • Have a better understanding of different Linux features from user space down to the kernel internals.
    • Most importantly: have fun.

    Resources


    early stage kdump support by mbrugger

    Project Description

    When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.

    Goal for the Hackweeks

    1. Investigate if this is possible and the implications it would have (done in HW21)
    2. Hack up a PoC (done in HW22 and HW23)
    3. Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).

    update HW23

    • I was able to include the crash kernel into the kernel Image.
    • I'll need to find a way to load that from init/main.c:start_kernel() probably after kcsan_init()
    • I workaround for a smoke test was to hack kexec_file_load() systemcall which has two problems:
      1. My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
      2. As the crash kernel is part of init.data it will be already stale once I can call kexec_file_load() from user-space.

    The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.

    update HW24

    • Day1
      • rebased on v6.12 with no problems others then me breaking the config
      • setting up a new compilation and qemu/virtme env
      • getting desperate as nothing works that used to work
    • Day 2
      • getting to call the invocation of loading the early kernel from __init after kcsan_init()
    • Day 3

      • fix problem of memdup not being able to alloc so much memory... use 64K page sizes for now
      • code refactoring
      • I'm now able to load the crash kernel
      • When using virtme I can boot into the crash kernel, also it doesn't boot completely (major milestone!), crash in elfcorehdr_read_notes()
    • Day 4

      • crash systems crashes (no pun intended) in copy_old_mempage() link; will need to understand elfcorehdr...
      • call path vmcore_init() -> parse_crash_elf_headers() -> elfcorehdr_read() -> read_from_oldmem() -> copy_oldmem_page() -> copy_to_iter()
    • Day 5

      • hacking arch/arm64/kernel/crash_dump.c:copy_old_mempage() to see if crash system really starts. It does.
      • fun fact: retested with more reserved memory and with UEFI FW, host kernel crashes in init but directly starts the crash kernel, so it works (somehow) \o/
    • TODOs

      • fix elfcorehdr so that we actually can make use of all this...
      • test where in the boot __init() chain we can/should call kexec_early_dump()


    pudc - A PID 1 process that barks to the internet by mssola

    Description

    As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:

    • The backend is written in a mixture of C and RISC-V assembly.
    • The backend is actually PID1 (for real, not within a container).
    • We poll and parse incoming HTTP requests ourselves.
    • The frontend is a mere HTML page with htmx.

    The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.

    I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.

    Goals

    • Have a better understanding of different Linux features from user space down to the kernel internals.
    • Most importantly: have fun.

    Resources