suggestion: adding device specyfic pages

[thenameisluk]

so currently in order to get to know more details on specific chromebook, one has to go through (in many cases) multiple issues and (often) read everything there for the most part it works but sometime information at the top of them might be outdated and make ppl think that an already fixed issue still exists

it would be nice to provide ppl with device specific markdown files with up to date information or even better use GitHub pages or for that it can also provide information on how to disable write protection (something i really struggled to find) was thinking something similar to what postmarketOS has for example page i updated some time ago for lenovo 10e

btw haven't put it on wiki for obvious reasons (don't know openRC solution) but that high pitch noise issue can also be resolve instantly by runningsystemctl --user restart pipewire.service

and I'm not saying that someone needs to go through all issues and put it inside this pages we can still keep the issues for discussions and pages can be filled up by ppl who use the device later

discord or sth similar server (probably) wouldn't hurt for general discussion (should go without saying it doesn't have to be managed by one person)

but these are just ideas/suggestions if anything i can try help with managing it, and providing information on devices i own myself (currently lenovo 10e and 100e but i am planning to buy lenovo ideapad dued 3/5 in the future)

[hexdump0815]

thanks a lot for your suggestions - i'm not having much time right now and thus will followup more detailed during the next days.

[hexdump0815]

sorry for the delay, but my time is currently a bit limited ... so let me try to respond to your suggestions:

the "documentation" of the system specific information in gh isssues is defintely not perfect, but at least gives some base information and a way for people to interact around a certain system. i actually started it after some user created such an issue for the device they used and i liked the idea so i started to create such issues at least for the most used systems and to my surprise it worked quite well. but for sure this could be improved and i'm currently thinking about maybe using the github wiki of the repo for this as it can easily be exported to have the information local or offline as well if needed. i'll look into this in more detail in the near future when i find a bit of time for that. the base for it should be a good basic structure, so that the doc for the different devices follow the same schema and it is easy to move around in the resulting documentation.

discord or some other kind of chat around the images might be a good idea to bring people together to solve potentail problems or work on improvements, but i definitely do not have enough time to manage something like that and most probably also will not be able to follow it all the time, but i think this should not be a problem. i would definitely prefer something simple and open standard like irc or matrix over discord. so if you would be interested to set something like this up and take care of it, it might be helpful for people using the images.

i hope i addressed all your points and maybe we can use this gh issue to bring those ideas into more shape over time.

[thenameisluk]

thank you for response ofc it can wait if you don't have time currently it's understandable i will look into some documentation solutions myself to try find something nice

about discord if you preffer something open source alternatives there is revolt similar to discord but under AGPL license + doesn't require you to worry about hosting (unlike irc or matrix afaik)

[thenameisluk]

any good documentation generators? was thinking lately about writing custom MarkDown+some extensions -> HTML transpiler it would make it easy for pages to have unified look across pages and not have to put more than needed effort to create each page

[hexdump0815]

@LukIsHere - first a big thank you for all your helpful responses and postings in the various github issues!

regarding improving the documentation: how about keeping it as simple as possible and using markdown (.md) files for any kind of freshly written documentation and creating a doc dir per system when additional documentation is available (like for example done already here: https://github.com/hexdump0815/imagebuilder/tree/main/systems/snapdragon_7c_woa/doc ) and then we can link this extra info from the corresponding systems readme.md ... adding and adjusting such doc files could be handled via regular github pull requests and generic documentation (i.e. not only relevant for a single system) can go into the central doc dir ... would this maybe be a useable starting point? this way everyone interested has a way to contribute and with md we have a very flexible format (i.e. easy to convert) to maybe do more things with at a later point in time.

[thenameisluk]

ofc keeping stuff simple and in markdown is a good idea

my idea is about making it also available via github pages (i think github actions or something similar should be able to auto generate the html) can use github pages domain, buy a domain or use duckdns to get a free one

i was thinking about for instance replacing _Note. some text_ with on markdown side it would stay italic but on a page it would look nicer same can be done with for example i really like dpp docs

if someone needs offline docs just git clone and run transpiler or use markdown whatever is preferred

we can keep it nice and with some simple transiler made specifically for that purpose

[thenameisluk]

@hexdump0815 a question so i did the luks encryption first try first time (somehow .-.) but one thing that caught my attention in the doc

IMPORTANT: the resulting vmlinux.kpart-initrd... files has to be smaller than 32mb for aarch64 systems and smaller than 16mb for armv7l systems - thus its nearly impossible to do this on a armv7l system as the initrd is usually too big (for exynos armv7l devices the size limit seems to be even 8mb)

32 mb limit doesn't seam to be the case, my homestar has no problem with booting 53mb (bloated depthcharge) images without any issue is it just that newer chromebooks can boot bigger partitions (i haven't tested it on my kukui or oak device) or size doesn't matter?

[hexdump0815]

yes - some newer aarch64 chromebooks can boot larger images - see image-max-size here: https://github.com/alpernebbi/depthcharge-tools/blob/master/depthcharge_tools/boards.ini

[thenameisluk]

@hexdump0815 if i want to add mainly chromebook specyfic docs (it's still wip but 'm getting closer to finishing it) should i add it to /doc/chromebook or similar or to the other repo i don't really get why have two repos

[hexdump0815]

@LukIsHere - this other repo about running linux on arm chromebooks i started to write to put all the information i had collected over the years somewhere public and it was ment also for beyond the imagebuilder framework for everyone interested in running linux on chromebooks - its mostly all the basic stuff to prepare a chromebook for linux usage etc.

for the documentation you are working on i would suggest to use system/chromebook-xyz/doc if it is specific for one of the chromebook types only and doc/chromebook if its more generic for chromebooks or even doc if its something which might apply to even other systems/images as well

contributions are very welcome and thanks once more for all your help and responses in the github issues

i hope to have more time again for this project around end of the year and from then on and my current idea would be to create a new round of most images around february of next year based on the next lts kernel (should be v6.12 most probably) and debian trixie and ubuntu noble then and for the chromebooks hopefully using depthchargetools by then ... its still a bit to go until then, but my hope is to have some real improvements and fixes in such new images then due to the newer kernel and lts is always good as they will be supported for long and this way people can easily build newer kernels with little risk of things breaking

[thenameisluk]

@hexdump0815 on depthcharge tools, it works but i myself ditched it for modified version of script from luks install

#!/bin/bash

if [ `whoami` != "root" ]; then
  echo "This script must be ran as root."
  exit 1
fi

cd /boot

# choosing kelner version

if [ "$#" != "1" ]; then
  echo "Note. no kelner specified, going with current kelner"
  kver=`uname -r`
fi

if [ "$#" == "1" ]; then
  kver=${1}
fi

echo "kelner chosen ${kver}"

#checking presence of the kelner

if [ ! -e Image-${kver} ]; then
  echo "Image-${kver} seams to be missing"
  echo "this kelner version doesn't seam to be present"
  exit 1
fi

#it is better to regenerate initramfs everytime
#if [ ! -e initrd.img-${kver} ]; then
#  echo "initrd.img-${kver} seams to be missing, trying to generate"
  update-initramfs -c -k ${kver}
#fi

if [ ! -e initrd.img-${kver} ]; then
  echo "sorry. unable to generate one TwT"
  exit 1
fi

if [ ! -e cmdline ]; then
  echo "cmdline seams to be missing"
  echo "Note. will create one for you"
  echo "console=tty1 root=LABEL=rootemmc rootwait ro fsck.fix=yes fsck.repair=yes net.ifnames=0 ipv6.disable=1 quiet splash" > cmdline

  #cbq requires additional cmdline
  if echo $kver | grep -q "cbq"; then
    echo "there is cbq"
    echo " deferred_probe_timeout=30 clk_ignore_unused=1" >> cmdline
  fi

  cat cmdline

fi

#generating required files
cd /boot
cp -v vmlinux.kpart-initrd-${kver} vmlinux.kpart-initrd-${kver}.old 2> /dev/null
cp Image-${kver} Image
lzma -9 -z -f -k -v Image
cp initrd.img-${kver} initrd.img.xz

#moved cmdline to seperate file to make it cleaner to edit
# for cbq add: deferred_probe_timeout=30 clk_ignore_unused=1
#echo "console=tty1 root=LABEL=rootemmc rootwait ro fsck.fix=yes fsck.repair=yes net.ifnames=0 quiet splash" > cmdline

dd if=/dev/zero of=bootloader.bin bs=512 count=1

# adjust to dtb names here:
# - cbg: dtb-${kver}/rk3399-gru-*.dtb
# - mt7: dtb-${kver}/mt8173-*.dtb
# - mt8: dtb-${kver}/mt8183-*.dtb
# - cbq: dtb-${kver}/sc7180-trogdor-*.dtb
# - generic: dtb-${kver}/*.dtb
#Note. you can specufy only dtb for your specyfic device to reduce space
#even further but lose portability. PLS BE CAREFUL, if you select wrong
#one the device will likely no work

ls dtb-${kver}/*.dtb | xargs printf " -b %s" | xargs mkimage -D "-I dts -O dtb -p 2048" -f auto -A arm64 -O linux -T kernel -C lzma -a 0 -d Image.lzma -i initrd.img.xz kernel.itb
vbutil_kernel --pack vmlinux.kpart --keyblock /usr/share/vboot/devkeys/kernel.keyblock --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --version 1 --config cmdline --bootloader bootloader.bin --vmlinuz kernel.itb --arch arm
cp -v vmlinux.kpart /boot/vmlinux.kpart-initrd-${kver}

#cleanning up
rm -f Image Image.lzma initrd.img.xz bootloader.bin kernel.itb vmlinux.kpart

#obtains the /dev/mmcblk1p or /dev/sda or similar
kpart=`findmnt -n -o SOURCE / | sed 's/.$//'`

#obtains parent disk, since sometimes there is p it otherwise would be tricky
pdisk=`lsblk -no PKNAME $(findmnt -n -o SOURCE /)`

#printing results
echo ""
echo "for single boot only testing:"

#echo "IMPORTANT: please double check your mmcblk device name beforehand"
#already take care of above

echo ""
echo "  dd if=/boot/vmlinux.kpart-initrd-${kver} of=${kpart}2"
echo "  cgpt add -i 2 -S 0 -T 1 -P 15 /dev/${pdisk}"
echo ""
echo "to always boot this kernel after successful testing:"
echo ""
echo "  dd if=/boot/vmlinux.kpart-initrd-${kver} of=${kpart}1"
echo ""

i've added auto kelner detection, correct disk detection, initramfs generation, storing cmdline in a diffrent file (to make it cleaner to edit) and auto cmdline generation it basically does the same job but in some way better (for instance it provides images under 32mb) and works with already provided kernels but it still needs a few tweaks for encrypted systems to propertly find the disk automatically (it works on unencrypted system without any issue but yeah it's sth i'm working on) i'm pretty sure it can be hooked to updating initramfs in same way and be way simple to setup

talking about the newer kelner i'm hoping the drm panic will be working, it would make it easier to see what went wrong instead of system freeze

[thenameisluk]

and done

#getting where root is mounted from, /dev/mmcblk0p4 or /dev/sda4 or /dev/mapper/encrypted
root=$(findmnt -n -o SOURCE /)

#encrypted partitions are inside /dev/mapper/
if echo $root | grep -q "mapper"; then
  rawname=$(echo $root | sed 's/\/dev\/mapper\///') #first we remove useless part
  root=/dev/$(lsblk -no NAME --raw | grep -B1 $rawname | head -n 1) #then we get partition before encrypted on in lsblk
fi

#obtains the /dev/mmcblk1p or /dev/sda or similar
kpart=$(echo $root | sed 's/.$//')

#obtains parent disk, since sometimes there is p it otherwise would be tricky
pdisk=$(lsblk -no PKNAME $root | head -n 1)

#printing results
echo ""
echo "for single boot only testing:"

#echo "IMPORTANT: please double check your mmcblk device name beforehand"
#already take care of above

echo ""
echo "  dd if=/boot/vmlinux.kpart-initrd-${kver} of=${kpart}2"
echo "  cgpt add -i 2 -S 0 -T 1 -P 15 /dev/${pdisk}"
echo ""
echo "to always boot this kernel after successful testing:"
echo ""
echo "  dd if=/boot/vmlinux.kpart-initrd-${kver} of=${kpart}1"
echo ""

now it works on any system, encrypted or not

[hexdump0815]

thanks a lot - that looks promising - that was my idea for a plan-b in case depthchargectl does not work as well to write some simple script to handle the boot image preparation ... i'll have a look at the script once i find some time and will also try to play around with depthchargectl to be able to compare them and then we will move on with what works best

[thenameisluk]

@hexdump0815 so i expanded upon that plan B idea

Velvet Tools

Set of tools for generating chromebook images

• vtlist lists available kernel versions
• vtbuild <version> builds a bootable image
• vtflash <version> flashes the image permamently
• vttest <version> flashes the image for testing

even made a script that produces nice .deb file so it can nicely integrate with the rest of the system :3

making tar.gz (for ppl running arch and stuff is also be possible) one should be simple

it has very simple structure

deb
├── DEBIAN
│   └── control
└── usr
    └── local
        └── bin
            ├── vtbuild
            ├── vtcommon <- some shared functionality, never meant to be run by itself
            ├── vtflash
            ├── vtlist
            └── vttest

you can look at scripts here (these are still bash scripts but without .sh extension so you can simple type for example vtflash in any directory)

there are some additional things i wanted to implement but for not there is this

i was also thinking about providing kernel images via .deb files but idk if that wouldn't be an overkill for simple framework (it would simplify installation thoe)

[hexdump0815]

i like the idea for the name for the tools :) ... will look into it in detail hopefully soon - sadly still completely out of time due to real life :(

[thenameisluk]

@hexdump0815 don't worry i understand, if i've had all the time i want, i would have already finished md to html transpiler

will keep on trying to improve stuff here and you can look into them when u find some time

[thenameisluk]

've added some more stuff to tools bash autocompletion hook to update initramfs help command and some other stuff

it grew a bit but likely won't get any more complex

deb/
├── DEBIAN
│   └── control
├── etc
│   ├── bash_completion.d
│   │   └── velvettools
│   ├── initramfs
│   │   └── post-update.d
│   │       └── velvet-build
│   └── initramfs-tools
│       └── hooks
│           └── velvet-build
└── usr
    ├── local
    │   └── bin
    │       ├── vtbuild
    │       ├── vtcommon
    │       ├── vtcommon-flash
    │       ├── vtdisable
    │       ├── vtflash
    │       ├── vthelp
    │       ├── vtlist
    │       └── vttest
    └── share
        └── velvettools
            └── help
                ├── cmdline
                ├── dtbs
                ├── vtbuild
                ├── vtdisable
                ├── vtflash
                └── vttest

seams to be in good enough state to be used

[trustytrojan]

if you guys are down i have time to manage a discord/revolt server for the people surrounding this repo! it would be nicer having realtime communication when debugging issues and whatnot.

[thenameisluk]

@trustytrojan that's not something i'm unable to do as well and i'm all for it, the thing is we haven't settled on specific realtime chat solution yet

it was just mentioned but haven't went anywhere yet @hexdump0815 if you have time, wanna move that topic forward?

[hexdump0815]

@trustytrojan @thenameisluk - my plan was to try to enable github discussions for this repo very soon to see how well that would work - maybe i'll get this forward this weekened or next one ... i would prefer this over discord as this way we would avoid information fragmentation ... in case you want to setup discord for it anyway, feel free to do so - only two things would be important: someone should take care of it (as i cannot do it and i'll most probably also not be around there) and it would be very good if anything useful brought up there (fixes, patches etc.) should somehow find its way back into this repo and the connected kernel build repos, so that we keep the essential information together at one place in the end

[thenameisluk]

@hexdump0815 it doesn't have to be as full featured as discord

i don't really know what to use discord or anything else for except realtime support (some ppl prefer to get help over realtime chat than forums, then create 5 issues about different problems with their single chromebook :3) but other than that idk

discussions sound like a good idea, honestly so for now let's stay with them and see if ppl are able to figure stuff out

@trustytrojan if you know what more discord could be used to can share

[thenameisluk]

@hexdump0815 an Idea made it easier to install kelner

kver=6.9.9-stb-cbq+

mkdir linux-${kver}
mkdir -p linux-${kver}/boot
mkdir -p linux-${kver}/DEBIAN
mkdir -p linux-${kver}/lib/modules

cp -r -v /boot/Image-${kver} linux-${kver}/boot/Image-${kver}
cp -r -v /boot/System.map-${kver} linux-${kver}/boot/System.map-${kver}
cp -r -v /boot/config-${kver} linux-${kver}/boot/config-${kver}
cp -r -v /boot/dtb-${kver} linux-${kver}/boot/dtb-${kver}
cp -r -v /boot/initrd.img-${kver} linux-${kver}/boot/initrd.img-${kver}
cp -r -v /boot/vmlinux.kpart-${kver} linux-${kver}/boot/vmlinux.kpart-${kver}
cp -r -v /lib/modules/${kver} linux-${kver}/lib/modules/${kver}

echo "Package: linux-${kver}" >> linux-${kver}/DEBIAN/control
echo "Version: ${kver}" >> linux-${kver}/DEBIAN/control
echo "Architecture: $(dpkg --print-architecture)" >> linux-${kver}/DEBIAN/control
echo "Depends: velvet-tools" >> linux-${kver}/DEBIAN/control
echo "Maintainer: $(whoami)" >> linux-${kver}/DEBIAN/control
echo "Description: kelner ${kver} package" >> linux-${kver}/DEBIAN/control

dpkg --build linux-${kver}

#rm -rf linux-${kver}

it gives us nice

linux-6.9.9-stb-cbq+.deb

while tar.gz works, we work with debian (+ debian based) so it'd be cool to use that to our advantage

[hexdump0815]

@thenameisluk - good idea - if its that easy we can really think about adjusting it in that direction, maybe even creating both a tar.gz and a .deb and then everyone can choose what is easier to deal with in a certain situation - long term i'm thinking about maybe setting up github actions to compile kernels, so that we can easily generate them for each new version which would make it easier to test where things break - but this is more something for next year i think

[thenameisluk]

@hexdump0815 added in version 0.4 of velvet tools https://github.com/thenameisluk/velvettools/blob/0.4/scripts/vtpack

#!/bin/bash
#vtpack deb <version> <maintainer>
#vtpack targz <version>

source $(dirname $BASH_SOURCE)/vtcommon

make_deb(){

    mkdir linux-${kver}
    mkdir -p linux-${kver}/boot
    mkdir -p linux-${kver}/DEBIAN
    mkdir -p linux-${kver}/lib/modules

    cp -r -v /boot/Image-${kver} linux-${kver}/boot/Image-${kver}
    cp -r -v /boot/System.map-${kver} linux-${kver}/boot/System.map-${kver}
    cp -r -v /boot/config-${kver} linux-${kver}/boot/config-${kver}
    cp -r -v /boot/dtb-${kver} linux-${kver}/boot/dtb-${kver}
    cp -r -v /boot/initrd.img-${kver} linux-${kver}/boot/initrd.img-${kver}
    cp -r -v /boot/vmlinux.kpart-${kver} linux-${kver}/boot/vmlinux.kpart-${kver}
    cp -r -v /lib/modules/${kver} linux-${kver}/lib/modules/${kver}

    echo "Package: linux-${kver}" >> linux-${kver}/DEBIAN/control
    echo "Version: ${kver}" >> linux-${kver}/DEBIAN/control
    echo "Architecture: $(dpkg --print-architecture)" >> linux-${kver}/DEBIAN/control
    echo "Depends: velvet-tools" >> linux-${kver}/DEBIAN/control
    #logname gives the username even under sudo
    echo "Maintainer: $1" >> linux-${kver}/DEBIAN/control
    echo "Description: kelner ${kver} package" >> linux-${kver}/DEBIAN/control

    echo "this might take a while, be patient"
    dpkg --build linux-${kver}

    rm -rf linux-${kver}echo "maintainer specified: $1"

    echo "maintainer specified: $1"
}

make_targz(){
    #lol 10+ lines vs oneliner :3
    tar cvzf "${kver}.tar.gz" "/boot/Image-${kver}" "/boot/System.map-${kver}" "/boot/config-${kver}" "/boot/dtb-${kver}" "/boot/initrd.img-${kver}" "/boot/vmlinux.kpart-${kver}" "/lib/modules/${kver}"
}

if [ "$#" == "0" ];then
    echo "what do you even want me to build???"
    echo "vtpack deb <version> <maintainer>"
    echo "vtpack targz <version>"
fi

get_kver "$2"

if [ "$1" == "deb" ];then 
    echo "doing deb"
    if [ "$3" != "" ];then
        make_deb "$3"
    else
        make_deb "$(logname)"
    fi
fi

if [ "$1" == "targz" ];then 
    echo "doing tar.gz"
    make_targz
fi

[thenameisluk]

@hexdump0815 on the topic of that repo i was talking about

i've finally managed to fully set it up at https://repo.velvet-os.org/repo/ it can be added using instructions in the readme

currently it only hosts velvet-tools and linux-6.9.9-stb-cbq+ (slightly newer than your latest kernel, with wayland compatible config, < still might require to edit default cmdline to enable apparmor but it's trivial with velvet tools) but it can also host other version + (for example) latest-linux-stb-cbq meta-package and the additional system specific files like https://github.com/hexdump0815/imagebuilder/tree/main/systems/chromebook_trogdor/extra-files

setting up github actions to build the kernel should be somewhat trivial but i would prefer it to not rebuild all versions with every repo upgrade so that's still sth to be figured out

so ye rn i think it might be a step in the right direction and a nice addition to the project lemme know what u think

[hexdump0815]

i just noticed that i did not respond here yet: to have that repo around sounds like a good idea - lets see how things work out with it over time and then we can decide how to move on with it ... it is definitely a good idea to experiment with something like this

[thenameisluk]

@hexdump0815 so i was working on slight rewrite of doc/chromebooks/basic-installation.md and just want to ask why even bother with "dd to emmc" approach for veyron where the "rsync to emmc" seams way simpler than looping some stuff and what not, and is giving us better system (with ability to boot usb)

could i get rid of it?

[archisman-panigrahi]

could i get rid of it?

Can we keep it as a 2nd option (just in case one wants to perform a new installation)? But we can bring the rsync approach to the first place, because it is more convenient in most use cases.

Keeping the option to use dd for writing to eMMC could be beneficial for someone in the future who wants to begin with a clean slate.

Also, most users (me included) don't have the capacity to reinvent these from scratch, so it may be useful just to keep it around.

[thenameisluk]

@archisman-panigrahi both aproaches achive very similar result

dd just dumps the image directly onto emmc rsync redoes the partitions so there is no conflict while trying to boot from usb

both wipe the drive and put image stuff onto emmc but one creates a partitions again (to avoid conflict) and doesn't require you to download the image again

imo fully dropping dd approach wouldn't be a bad idea, the only reason i hesitate is the fact i used slightly altered version of it the first time i used the image dd if=/dev/sda of=/dev/mmcblk1 i know it's a bad idea but i still went for it not knowing any better

[archisman-panigrahi]

I may be wrong but I thought dd helps you install a new image and rsync helps you copy an existing USB/sdcard installation to emmc

[thenameisluk]

@archisman-panigrahi if you haven't touched anything on the usb the rsync just basically gives you the fresh images

it's like distro usb installer, why download entire debian again if you have all the files on the usb?

[archisman-panigrahi]

Here is a use case where one may prefer dd

Suppse, there is an existing USB installation, which is not completely broken, but for some reason, something is not working correctly, and the user wants to start with a new installation.

One option is to flash the new installation to the USB drive and sync with rsync. But another option is to just perform a new installation from within the previous installation using dd. This is not always necessary, but may come handy in some cases.

(This is just my opinion.)

[thenameisluk]

@archisman-panigrahi it's like flashing debian iso directly onto pc memory

and after performing dd installation you will be unable to easily boot from usb anymore unless you nuke your fs or restore chrome os

so if you break your dd installation it's even more work for you to fix it

[archisman-panigrahi]

and after performing dd installation you will be unable to easily boot from usb anymore unless you nuke your fs or restore chrome os

I didn't know that. If that is the case, then I would also suggest removing it.

I am curious to know why performing a dd installation removes the ability to boot from USB.

[hexdump0815]

i would suggest we keep the dd instructions (i prefer to have the info still somewhere around - there might people where this option might be a good option), but maybe add some info that they have some drawbacks and the rsync way should be used as its much better ... as a result we should maybe move the rsync approach first.

[thenameisluk]

@hexdump0815 i can keep the dd approach but it'd be nice to explain who is it for? ppl who want fresh installation or sth?

[hexdump0815]

@thenameisluk - i think there is no clear target audience for it, but in some cases it might be the preferred way to do it as it might be simpler, faster etc. for someone ... i prefer to just keep the knowledge that it is possible this way too still around somewhere, but it can be really just in a small corner of the documentation as the rsync approach is definitely the better one and the one with way less problems ... i did start my old documentation with the dd approach because i thought that the rsync one might be too complicated for some people (dealing with partitioning etc.), but looks like this is really not the problem if everything is described well and in detail

[thenameisluk]

will just put it in legacy tab or sth

[thenameisluk]

@hexdump0815 btw a notes on tv boxes

from what i've tested tv boxes work well with 1920x1080 screens but some tv's don't go up to 1920x1080 but for example my tv goes to 1080x720 to mitigate that we can add video=HDMI-A-1:1280x720@60e to the cmdline so it always defaults to proper resolution and the tv doesn't say "out of range" or similar Note. some de's seams to work without it (for example cage) but it's iffy and you are still unable to see the tty

also tv boxes also can work well with retroarch and likely kodi too but i'm not really into that so making a doc on setting it up might be a good idea

precompiling additional arm64 libretro cores for velvet repo might be nice too since debian doesn't have most cool ones

i'm not sure if using them as a regular pc's is a good idea since 1/2GB ram

[archisman-panigrahi]

I am curious to know, is it possible to install kodi on these boxes?

On Sat, Oct 12, 2024, 4:37 PM luk @.***> wrote:

@hexdump0815 https://github.com/hexdump0815 btw a notes on tv boxes

from what i've tested tv boxes work well with 1920x1080 screens but some tv's don't go up to 1920x1080 but for example my tv goes to 1080x720 to mitigate that we can add @.** to the cmdline so it always defaults to proper resolution and the tv doesn't say "out of range" or similar Note. some de's seams to work without it (for example cage) but it's iffy and you are still unable to see the tty*

also tv boxes also can work well with retroarch and likely kodi too but i'm not really into that so making a doc on setting it up might be a good idea

precompiling additional arm64 libretro cores for velvet repo might be nice too since debian doesn't have most cool ones

i'm not sure if using them as a regular pc's is a good idea since 1/2GB ram

— Reply to this email directly, view it on GitHub https://github.com/hexdump0815/imagebuilder/issues/209#issuecomment-2408693839, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXL2XH72WTS6QKJEEWNKR3Z3GCBBAVCNFSM6AAAAABHGXQTJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGY4TGOBTHE . You are receiving this because you were mentioned.Message ID: @.***>

[thenameisluk]

@archisman-panigrahi sudo apt install kodi i see no reason why it shouldn't work

[thenameisluk]

the tricky part is not getting scammed when buying one

and maybe setting it up as autostart

[hexdump0815]

for kodi use a look at the libreelec project might be worth a try as they have a lot of video decoding optimization patches in their images and they also have a few (partially inofficial) tv box builds around as well ... better avoid coreelec as it does not go the mainline route and can change the emmc content of the tv box in a way so that it will be hard to impossible to install some mainline based linux on it

@thenameisluk - there are also quite a few still rather cheap tv boxes with 4gb ram available nowadays (there are even some with 8gb, but they are usually that expensive that there are usually other better options availabe in this area) which can be used as desktop systems to some degree (they are quite a bit slower than a kukui chromebook for instance) ... the lower memory boxes are usually good as little servers or build machines - i usually compile kernels and build my images on tv boxes :) ... to easily convert them into a server-like system i recently added simple scripts like https://github.com/hexdump0815/imagebuilder/blob/main/files/extra-files-bookworm/scripts/desktop-to-server.sh

[thenameisluk]

i know about the script but i prefer to not use it since it might remove some important software with auto-remove (or not) like networkmanager (for wifi in tty)

'm not sure if i know what exactly to look for when searching for the tv boxes, will focus for now on ones i got

[hexdump0815]

@thenameisluk - is that a known issue that the networkmanager goes away? if yes, then i should have a look at that at some point i guess.

[thenameisluk]

i think it might be installed as dep of task-xfce-desktop so running auto-remove just gets rid of it

[hexdump0815]

thanks for the info - i'll check at some point and if needed maybe just reinstall that one by hand again in the script ... or maybe better change the initial installation of packages in the images to install networkmanager, so that it does not get installed as dependency of xfce but on its own instead

[thenameisluk]

either way ppl who used older images will still encounter the issue

if /scripts dir was part of .deb package it could be automatically updated using the repo ;3

[thenameisluk]

@hexdump0815 untill we settle on velvet-tools or deptcharge-tools or the luks installation script progress on waydroid and splash screen is kinda stalled

• waydroid requires to edit cmdline (on top of additional modifications hopefully added in 6.11)
• slash screen need initramfs and cmdline

telling ppl to set the script up post installation might cause confusion since luks script setup already has it

while velvet tools are easy to setup to get waydroid/plymouth working and docs can make use of em it still hasn't been decided so i'm not sure if i should make use of them

[thenameisluk]

one thing is for sure

the tv boxes (at least the one i'm currently testing) seam to work well with melonds core i've prepared

the only missing thing is audio

@hexdump0815 i'm not sure if i understand the notes does it talk about hdmi audio possibly not working or jack audio (if there is hdmi video output, there should be sound over hdmi right?)