NetBSD

10.0-RC2 már commitolva, de hír még nincs belőle a főoldalon, gondolom készülnek a lemezképek hozzá. 2020. februárjában jelent meg a 9.0, úgyhogy várós már. DRM/KMS frissítést kapott a linux 5.6 verziójára, a legnagyobb munka talán azzal volt/van.

> 2024.01.17. 

Lesz 10.0-RC3 is, már commitolva van.

> 2024.02.07.

10.0-RC4

> 2024.02.27.

10.0-RC5, elvileg ez az utolsó...

> 2024.03.29.

Közben volt RC6 is, de a 10.0 már commitolva van. Hír még nincs, valamint az ftp szerveren is üres még a 10.0 könyvtár, de közel van.

Felhasználtam @uzsolt autologin megoldását NetBSD-n, zsh-val.

/etc/gettytab -hoz:

autologin:\
        :al=kikadf:tc=Pc:

/etc/ttys -ben:

# Backup:
#constty        "/usr/libexec/getty Pc"         wsvt25  on secure
constty "/usr/libexec/getty autologin"          wsvt25  on secure

~/.zprofile -ban (a ~/.login úgy olvasom csh specifikus):

if [ "$(tty)" = "/dev/constty" ]; then
        startx
fi

Én nem használom fel a kilépés/újraindítás részt, mert azt a wm-ből kezelem.

A wm indítását a ~/.xinitrc -ben kell beállítani. 

pulseaudio beállítása NetBSD-n (például chromium-hoz) egy régi tutorial alapján:

1) dbus engedélyezése, ha még nincs

# cp /usr/pkg/share/examples/rc.d/dbus /etc/rc.d/
# /etc/rc.d/dbus onestart

/etc/rc.conf: dbus=YES hozzáadása

2) /usr/pkg/etc/pulse/default.pa szerkesztése:

- #load-module module-oss device="/dev/dsp" sink_name=output source_name=input
+ load-module module-oss device="/dev/audioX" sink_name=output source_name=input

audioX nálam audio0, 'audiocfg list' listázza az eszközöket.

Ha NetBSD-n valami miatt a latest pkgsrc csomagok kellenek, akkor azt forrásból kell telepíteni, bináris csomagok csak a quarterly repókban vannak. Ebben az esetben a csomagok frissítése:

cd /usr/pkgsrc
git pull
sudo pkg_rolling-replace -uv

Viszont a pkg_rolling-replace nem kezeli a verziózott csomagokat, pl a python csomagokat. Van egy pkgsrc default python verzio, ez jelenleg a 312, viszont a felhasználó ettől eltérhet és használhat teszése szerint (a lehetőségeken belül persze)  más python verziót is. Emiatt a pkg_rolling-replace nem bántja a python verziót, hacsak valami másik csomagnak nem kell konkrétan egy verzió és az addigi pythonverzióval frissíti a csomagot. Így történt meg, hogy volt egy csomó py310-*, py311-* és py312-* python csomagom is feleslegesen.

Összesen 100+ py- csomagom volt szóval szkripteltem:

#!/bin/sh

if [ -z "$1" ]; then
        echo ">>> Missing python version!"
        echo ">>> Usage: sudo $(basename $0) 311"
        exit 1
else
        _pyver=$1
fi

die() {
        _errc=$?
        echo ">>> ERROR: $1 ($_errc)"
        exit $_errc
}

for _pypkg in $(pkg_info -a | sed -n "s|\(py$_pyver-[^ ]*\) .*|\1|p"); do
        _pypkgpath=$(echo "$_pypkg" | sed -n 's|\(py\)[0-9]*\(-.*\)-[^-]*|\1\2|p')
        cd /usr/pkgsrc/*/"$_pypkgpath" || die "cd $_pypkgpath"
        echo ">>> $(pwd): replace $_pypkgpath"
        pkg_delete -f "$_pypkg" || die "pkg_delete -f $_pypkg"
        make install || die "make install $_pypkgpath"
done

echo ">>> Remove python$_pyver"
pkg_delete -f "python$_pyver" || die "pkg_delete -f python$_pyver"

pkg_admin rebuild-tree

exit $?

Annyi történik, hogy a for ciklusban megkeresi az összes paraméterben kapott python verziós csomagot, törli force kapcsolóval (hogy hagyja figyelmen kívül a függőségi problémákat), majd újrafordítja a default python verzióval. Ha végzett a csomagokkal, törli a megadott verziójú python-t is, majd a pkg_admin helyrehozza a függőségi leírásokat.

Ezt követően, python verzió váltásnál a pkg_rolling-replace előtt futtatom a scriptet.

Kernel panic. Nem túl friss wiki oldal kiindulásnak. A /var/crash könyvtárba kerülnek a dump-ok:

cd /var/crash && sudo gunzip -d *gz
sudo dmesg -M netbsd.1.core -N netbsd.1
[   512.917593] fatal protection fault in supervisor mode
[   512.917593] trap type 4 code 0 rip 0xffffffff80db14f4 cs 0x8 rflags 0x10206 cr2 0x7dbd48c2e600 ilevel 0 rsp 0xffffc18242975d40
[   512.917593] curlwp 0xffffe53d60a3ca00 pid 3297.3302 lowest kstack 0xffffc182429712c0
[   512.917593] panic: trap
[   512.917593] cpu2: Begin traceback...
[   512.918047] vpanic() at netbsd:vpanic+0x183
[   512.919505] panic() at netbsd:panic+0x3c
[   512.920481] trap() at netbsd:trap+0xbaf
[   512.920481] --- trap (number 4) ---
[   512.920969] videoclose() at netbsd:videoclose+0xbb
[   512.921941] cdev_close() at netbsd:cdev_close+0x92
[   512.922414] spec_close() at netbsd:spec_close+0x188
[   512.923403] VOP_CLOSE() at netbsd:VOP_CLOSE+0x44
[   512.924378] vn_close() at netbsd:vn_close+0x51
[   512.924873] closef() at netbsd:closef+0x58
[   512.925838] fd_close() at netbsd:fd_close+0x140
[   512.926349] sys_close() at netbsd:sys_close+0x22
[   512.927307] syscall() at netbsd:syscall+0x1fc
[   512.927770] --- syscall (number 6) ---
[   512.927770] netbsd:syscall+0x1fc:
[   512.927770] cpu2: End traceback...

[   512.928265] dumping to dev 168,1 (offset=8, size=2097039):
[   512.928265] dump

• ChatGPT szerint:

A megosztott NetBSD panic log arról tanúskodik, hogy a kernel egy "fatal protection fault" miatt pánikolt. Az üzenetben szereplő információk alapján elindulhatunk a hiba okának felderítésében. Nézzük meg a részleteket:

Hiba okának lehetséges forrásai

1. fatal protection fault in supervisor mode:

   • A "protection fault" arra utal, hogy a kernel egy érvénytelen memóriahozzáférést próbált végrehajtani, amely védett vagy nem létező memóriacímre mutat.
   • A "supervisor mode" azt jelzi, hogy a hiba kernel módban történt, nem pedig egy felhasználói folyamatban.

2. trap type 4:

   • A trap type 4 egy "protection fault", amely tipikusan olyan helyzetben fordul elő, amikor a kernel védett memóriaterületet próbál olvasni vagy írni.

3. rip 0xffffffff80db14f4:

   • Ez a kernel kódjában az utasításmutató (Instruction Pointer) aktuális értéke. Ez a konkrét utasítás okozta a hibát.
   • A címet a kernel szimbólumtáblájával lehet feloldani, hogy megállapítsuk, pontosan melyik kódrész érintett:
     

     gdb netbsd.gdb (gdb) list *0xffffffff80db14f4 

4. cr2 0x7dbd48c2e600:

   • A CR2 regiszter a hibás memóriahozzáférés címét tartalmazza.
   • Az 0x7dbd48c2e600 cím egy valószínűleg érvénytelen vagy felszabadított mutatóra utal.

Stack trace elemzése

A stack trace fontos információkat nyújt a hiba okáról:

1. videoclose():

   • A hiba a videoclose() függvényben történt, amely valószínűleg egy karakteres eszköz lezárásával kapcsolatos.
   • Ez utalhat egy probléma forrására a videóeszközök kezelése során.

2. cdev_close() → spec_close() → VOP_CLOSE():

   • Ezek a hívások az eszközfájl lezárásának tipikus lépései a NetBSD kernelében.
   • A hiba valószínűleg az eszköz struktúrájának helytelen kezelése során keletkezett, például:
     • Érvénytelen mutatóra történő hivatkozás.
     • A lezárni próbált eszköz már felszabadított állapotban volt.

3. fd_close() → sys_close():

   • A felhasználói folyamat (PID 3297) egy close() rendszerhívást hajtott végre, ami kiváltotta a problémát.

• gdb:

sudo gdb /netbsd --eval-command="target kvm netbsd.1.core"
...
(gdb) list *0xffffffff80db14f4
0xffffffff80db14f4 is in videoclose (/usr/src/sys/dev/video.c:2481).
warning: Source file is more recent than executable.
2476                             "tearing down bufs while streaming\n"));
2477            }
2478
2479            /* dequeue all buffers */
2480            while (SIMPLEQ_FIRST(&vs->vs_ingress) != NULL)
2481                    SIMPLEQ_REMOVE_HEAD(&vs->vs_ingress, entries);
2482            while (SIMPLEQ_FIRST(&vs->vs_egress) != NULL)
2483                    SIMPLEQ_REMOVE_HEAD(&vs->vs_egress, entries);
2484
2485            err = video_stream_free_bufs(vs);
(gdb)

Régi Raspberry Pi 2 lapot találtam. 

NetBSD telepítése rá, ALARM-szerű leírásban:

Replace sdX in the following instructions with the device name for the SD card as it appears on your computer.

1. Download and extract the image:

wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/evbarm-earmv7hf/binary/gzimg/armv7.img.gz
gunzip armv7.img.gz

2. Write the image to SD card:

dd if=armv7.img of=/dev/sdX bs=1m conv=sync progress=1

3. To remote access add user with creds_msdos:

mkdir boot
mount /dev/sdXe boot
echo "useradd user passwd" > boot/creds.txt
umount boot

4. Insert the SD card into the Raspberry Pi, connect ethernet, and apply 5V power.

5. Use the serial console or SSH to the IP address given to the board by your router.

• Login as the user what set with creds_msdos.
• The default root password is empty.

6. To install binary packages:

export PKG_PATH=https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r | cut -d_ -f1)/All
pkg_add pkgin

• pkgin

Elsőnek egy IRC szervert állítok be rajta, aztán majd meglátom...