FreeBSD-all

A FreeBSD nem csatlakozik a hálózathoz [MEGOLDVA]

Vad — Thu, 10 Jul 2025 15:26:41 +0000

A FreeBSD nem csatlakozik a hálózathoz, sem vezetéken, sem wifin keresztül. Kb másfél éve telepitettem a 14.1 verziót, ami normális módon mükődőtt, minden tekintetben, de néhány napja nem csatlakozik az internethez.

Ugyan ezen a gépen a Suse linuxnál nem jelentkezik a probléma.

Áramszünet esetén kontrollált leállítás

dlaszlo — Sun, 09 Feb 2025 15:10:09 +0000

FreeBSD-all

Sziasztok!

Áramszünet esetén kontrollált leállítást szeretnék beállítani egy FreeBSD-t futtató gépen. Jelenleg egy UPS beszerzésén gondolkodom, de nincs semmi tapasztalatom ezen a téren.

Tud esetleg valaki javasolni olyan UPS-t, amely akár USB-n keresztül csatlakoztatható egy FreeBSD rendszert futtató gépre, és van hozzá megfelelő utility vagy driver a FreeBSD-hez, ami egy áramszünet esetén el tud indítani egy graceful shutdown-t?

A cél az lenne, hogy a gép védve legyen a feszültségingadozásoktól (bár feltételezem, hogy a mai tápegységek ezt már megoldják, de nem árt, ha van UPS is), és a hirtelen lekapcsolástól, elkerülve a fájlrendszer (ZFS) sérülését. Felesleges "nagyágyút" sem szeretnék venni, vagy olyan típust, ami problémás valami miatt.

Ez az előzmény: https://hup.hu/node/187365 (szerencsére eddig nem történt valós adatvesztés, de szeretném elkerülni, hogy ez ismét előforduljon).

Előre is köszönöm a segítséget!

Raspberry PI 4 - FreeBSD PXE boot konfigurálás

dlaszlo — Sat, 28 Dec 2024 13:57:41 +0000

FreeBSD-all

Sziasztok!

FreeBSD szerverről szeretnék bebootolni netboot-tal (PXE) egy Raspberry PI-t, amin szintén FreeBSD futna.

A következőket csináltam:

1. Bootloader frissítés

A "Raspberry Pi Imager"-rel kiírtam a network boot-os bootloadert egy sd kártyára, és feltettem a raspberry pi-re.

2. Router konfigurálás

Egy Mikrotik routerem van, és ott a DHCP beállításoknál megadtam az adott klienshez a 66-os, és 67-es opciót, ami elvileg kell a netboot-hoz:

66 s'192.168.4.200'
67 s'bootcode.bin'

És a networks-nél beállítottam a next-server-t a 192.168.4.200-ra. (megj.: ha a next-server-t nem állítom be, akkor később a routerről akarja letölteni a fájlokat, miután az uboot elindult (de nem tudom, hogy miért))

3. Elindítottam a TFTP-t a FreeBSD szerveren

/etc/inetd.conf:

tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

(a sorból kiszedtem a commentezést)

Létrehoztam egy /tftpboot könyvtárat:

mkdir /tftpboot

az inetd-t bekapcsoltam:

/etc/rc.conf:

inetd_enable="YES"

inetd szolgáltatás elindítása:

service start inetd

4. Letöltöttem a Raspberry PI image-et, és kicsomagoltam

cd ~
wget https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.2/FreeBSD-14.2-RELEASE-arm64-aarch64-RPI.img.xz
xz -d FreeBSD-14.2-RELEASE-arm64-aarch64-RPI.img.xz

A boot particiót bemásoltam a /tftpboot könyvtárba:

mdconfig -a -t vnode -f FreeBSD-14.2-RELEASE-arm64-aarch64-RPI.img 
mount -tmsdosfs /dev/md1s1 /mnt
cp -a /mnt/* /tftpboot/

umount /mnt

A root particiót bemásoltam a /tftpboot/rootfs könyvtárba:

mkdir /tftpboot/rootfs
mount /dev/md1s2a /mnt
cp -a /mnt/* /tftpboot/rootfs/

umount /mnt
mdconfig -d -u md1

5. NFS bekonfigolása:

/etc/rc.conf:

nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfs_server_flags="-u -t -n 4"
mountd_enable="YES"
rpcbind_enable="YES"

/etc/exports:

/tftpboot/rootfs -maproot=root -alldirs

NFS elindítása:

service start rcpbind
service start nfsd
service start mountd

6. Tesztelés, hogy eddig működik-e:

A root fájlrendszert (/tftpboot/rootfs) NFS-sel a gépemen (egy Fedora desktop) fel tudom mountolni. Tudok írni a fájlrendszerbe. - szerintem ez működik.

A TFTP működik, a Raspberry PI elkezdi letölteni a U-Boot-ot, ami szépen elindul a Raspberry PI-n.

tcpdump-pal megnézve, hogy mi történik:

# tcpdump -i re0 port 69

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on re0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:31:13.684042 IP 192.168.4.15.53678 > 192.168.4.200.tftp: TFTP, length 49, RRQ "d84f375f/start4.elf" octet tsize 0 blksize 1468
14:31:13.687051 IP 192.168.4.15.53679 > 192.168.4.200.tftp: TFTP, length 48, RRQ "d84f375f/start.elf" octet tsize 0 blksize 1468
14:31:13.689934 IP 192.168.4.15.53680 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:13.693358 IP 192.168.4.15.53681 > 192.168.4.200.tftp: TFTP, length 39, RRQ "vl805.sig" octet tsize 0 blksize 1468
14:31:13.695819 IP 192.168.4.15.53682 > 192.168.4.200.tftp: TFTP, length 42, RRQ "pieeprom.sig" octet tsize 0 blksize 1468
14:31:13.698766 IP 192.168.4.15.53683 > 192.168.4.200.tftp: TFTP, length 42, RRQ "recover4.elf" octet tsize 0 blksize 1468
14:31:13.701738 IP 192.168.4.15.53684 > 192.168.4.200.tftp: TFTP, length 42, RRQ "recovery.elf" octet tsize 0 blksize 1468
14:31:13.704156 IP 192.168.4.15.53685 > 192.168.4.200.tftp: TFTP, length 40, RRQ "start4.elf" octet tsize 0 blksize 1468
14:31:14.482638 IP 192.168.4.15.53686 > 192.168.4.200.tftp: TFTP, length 40, RRQ "fixup4.dat" octet tsize 0 blksize 1468
14:31:14.712457 IP 192.168.4.15.49153 > 192.168.4.200.tftp: TFTP, length 42, RRQ "recovery.elf" octet tsize 0 blksize 1468
14:31:14.714849 IP 192.168.4.15.49154 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:14.717775 IP 192.168.4.15.49155 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:14.720940 IP 192.168.4.15.49156 > 192.168.4.200.tftp: TFTP, length 41, RRQ "dt-blob.bin" octet tsize 0 blksize 1468
14:31:14.777910 IP 192.168.4.15.49157 > 192.168.4.200.tftp: TFTP, length 42, RRQ "recovery.elf" octet tsize 0 blksize 1468
14:31:14.780326 IP 192.168.4.15.49158 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:14.783019 IP 192.168.4.15.49159 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:15.237028 IP 192.168.4.15.49160 > 192.168.4.200.tftp: TFTP, length 41, RRQ "bootcfg.txt" octet tsize 0 blksize 1468
14:31:15.290138 IP 192.168.4.15.49161 > 192.168.4.200.tftp: TFTP, length 40, RRQ "u-boot.bin" octet tsize 0 blksize 1468
14:31:15.292956 IP 192.168.4.15.49162 > 192.168.4.200.tftp: TFTP, length 40, RRQ "u-boot.bin" octet tsize 0 blksize 1468
14:31:15.300129 IP 192.168.4.15.49163 > 192.168.4.200.tftp: TFTP, length 49, RRQ "bcm2711-rpi-4-b.dtb" octet tsize 0 blksize 1468
14:31:15.303253 IP 192.168.4.15.49164 > 192.168.4.200.tftp: TFTP, length 49, RRQ "bcm2711-rpi-4-b.dtb" octet tsize 0 blksize 1468
14:31:15.325274 IP 192.168.4.15.49165 > 192.168.4.200.tftp: TFTP, length 54, RRQ "overlays/overlay_map.dtb" octet tsize 0 blksize 1468
14:31:15.403776 IP 192.168.4.15.49166 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:15.406407 IP 192.168.4.15.49167 > 192.168.4.200.tftp: TFTP, length 40, RRQ "config.txt" octet tsize 0 blksize 1468
14:31:15.430249 IP 192.168.4.15.49168 > 192.168.4.200.tftp: TFTP, length 47, RRQ "overlays/mmc.dtbo" octet tsize 0 blksize 1468
14:31:15.433207 IP 192.168.4.15.49169 > 192.168.4.200.tftp: TFTP, length 47, RRQ "overlays/mmc.dtbo" octet tsize 0 blksize 1468
14:31:15.495247 IP 192.168.4.15.49170 > 192.168.4.200.tftp: TFTP, length 54, RRQ "overlays/disable-bt.dtbo" octet tsize 0 blksize 1468
14:31:15.497989 IP 192.168.4.15.49171 > 192.168.4.200.tftp: TFTP, length 54, RRQ "overlays/disable-bt.dtbo" octet tsize 0 blksize 1468
14:31:15.639655 IP 192.168.4.15.49172 > 192.168.4.200.tftp: TFTP, length 41, RRQ "cmdline.txt" octet tsize 0 blksize 1468
14:31:15.642530 IP 192.168.4.15.49173 > 192.168.4.200.tftp: TFTP, length 41, RRQ "cmdline.txt" octet tsize 0 blksize 1468
14:31:15.916083 IP 192.168.4.15.49174 > 192.168.4.200.tftp: TFTP, length 46, RRQ "armstub8-gic.bin" octet tsize 0 blksize 1468
14:31:15.919120 IP 192.168.4.15.49175 > 192.168.4.200.tftp: TFTP, length 46, RRQ "armstub8-gic.bin" octet tsize 0 blksize 1468
14:31:15.922126 IP 192.168.4.15.49176 > 192.168.4.200.tftp: TFTP, length 46, RRQ "armstub8-gic.bin" octet tsize 0 blksize 1468
14:31:15.925035 IP 192.168.4.15.49177 > 192.168.4.200.tftp: TFTP, length 46, RRQ "armstub8-gic.bin" octet tsize 0 blksize 1468
14:31:15.928720 IP 192.168.4.15.49178 > 192.168.4.200.tftp: TFTP, length 40, RRQ "u-boot.bin" octet tsize 0 blksize 1468
14:31:15.932184 IP 192.168.4.15.49179 > 192.168.4.200.tftp: TFTP, length 40, RRQ "u-boot.bin" octet tsize 0 blksize 1468
14:31:36.970228 IP 192.168.4.15.3526 > 192.168.4.200.tftp: TFTP, length 73, RRQ "pxelinux.cfg/01-dc-a6-32-11-d3-13" octet timeout 5 tsize 0 blksize 1468
14:31:36.993175 IP 192.168.4.15.3549 > 192.168.4.200.tftp: TFTP, length 61, RRQ "pxelinux.cfg/C0A8040F" octet timeout 5 tsize 0 blksize 1468
14:31:37.015680 IP 192.168.4.15.3571 > 192.168.4.200.tftp: TFTP, length 60, RRQ "pxelinux.cfg/C0A8040" octet timeout 5 tsize 0 blksize 1468
14:31:37.038105 IP 192.168.4.15.3594 > 192.168.4.200.tftp: TFTP, length 59, RRQ "pxelinux.cfg/C0A804" octet timeout 5 tsize 0 blksize 1468
14:31:37.060190 IP 192.168.4.15.3616 > 192.168.4.200.tftp: TFTP, length 58, RRQ "pxelinux.cfg/C0A80" octet timeout 5 tsize 0 blksize 1468
14:31:37.083776 IP 192.168.4.15.3640 > 192.168.4.200.tftp: TFTP, length 57, RRQ "pxelinux.cfg/C0A8" octet timeout 5 tsize 0 blksize 1468
14:31:37.105659 IP 192.168.4.15.3662 > 192.168.4.200.tftp: TFTP, length 56, RRQ "pxelinux.cfg/C0A" octet timeout 5 tsize 0 blksize 1468
14:31:37.127351 IP 192.168.4.15.3683 > 192.168.4.200.tftp: TFTP, length 55, RRQ "pxelinux.cfg/C0" octet timeout 5 tsize 0 blksize 1468
14:31:37.148962 IP 192.168.4.15.3705 > 192.168.4.200.tftp: TFTP, length 54, RRQ "pxelinux.cfg/C" octet timeout 5 tsize 0 blksize 1468
14:31:37.174139 IP 192.168.4.15.3730 > 192.168.4.200.tftp: TFTP, length 76, RRQ "pxelinux.cfg/default-arm-bcm283x-rpi" octet timeout 5 tsize 0 blksize 1468
14:31:37.200294 IP 192.168.4.15.3756 > 192.168.4.200.tftp: TFTP, length 72, RRQ "pxelinux.cfg/default-arm-bcm283x" octet timeout 5 tsize 0 blksize 1468
14:31:37.223482 IP 192.168.4.15.3779 > 192.168.4.200.tftp: TFTP, length 64, RRQ "pxelinux.cfg/default-arm" octet timeout 5 tsize 0 blksize 1468
14:31:37.245857 IP 192.168.4.15.3802 > 192.168.4.200.tftp: TFTP, length 60, RRQ "pxelinux.cfg/default" octet timeout 5 tsize 0 blksize 1468
14:31:37.275392 IP 192.168.4.15.3831 > 192.168.4.200.tftp: TFTP, length 52, RRQ "C0A8040F.img" octet timeout 5 tsize 0 blksize 1468

Tehát látszik, hogy a pxeconfig.cfg könyvtárból már nem tud semmit letölteni, és a C0A8040F.img-t sem. - De ez még rendben van ezen a ponton, azt most kell létrehoznom:

Kérdések:

És itt vagyok elakadva, sok mindent kipróbáltam, de nem találok egy jó leírást.

Létrehozom a pxelinux.cfg-ben a default-ot:

/tftpboot/pxelinux.cfg/default:

DEFAULT FreeBSD

LABEL FreeBSD
    KERNEL rootfs/boot/kernel/kernel.bin
    APPEND -dhcp -v vfs.root.mountfrom="nfs:192.168.4.200:/tftpboot/rootfs" rootfs/boot/loader.conf

Az APPEND sorban már tuti hülyeség van, de sok mindent kipróbáltam.

A /tftpboot/cmdline.txt-be felvettem ezt:

vfs.root.mountfrom=nfs:192.168.4.200/tftpboot/rootfs

Ezt a sort /tftpboot/rootfs/boot/loader.conf-ba is felvettem:

vfs.root.mountfrom=nfs:192.168.4.200/tftpboot/rootfs

Tehát a teljes fájl tartalma:

# Configure USB OTG; see usb_template(4).
hw.usb.template=3
umodem_load="YES"
# Multiple console (serial+efi gop) enabled.
boot_multicons="YES"
boot_serial="YES"
# Disable the beastie menu and color
beastie_disable="YES"
loader_color="NO"
vfs.root.mountfrom=nfs:192.168.4.200/tftpboot/rootfs

Így most látszik a tcpdump kimenetében, hogy lölti a kernel.bin-t:

...
14:36:55.505766 IP 192.168.4.15.3801 > 192.168.4.200.tftp: TFTP, length 60, RRQ "pxelinux.cfg/default" octet timeout 5 tsize 0 blksize 1468
14:36:55.543131 IP 192.168.4.15.3839 > 192.168.4.200.tftp: TFTP, length 69, RRQ "rootfs/boot/kernel/kernel.bin" octet timeout 5 tsize 0 blksize 1468

Látszik a raspberry pi HDMI kimenetével, hogy el is indítja a kernel-t (Startint kernel... üzenet jelenik meg), majd teljesen sötét képernyőre vált, és minden kifagy.

A loader.conf-ot semmi nem tölti le (TFTP-vel).

Itt a vége fele már teljesen el vagyok veszve, mit hogyan kellene, nem igazán találok teljesen jó leírást, ami RPI alatt is működik, és FreeBSD-n van a PXE környezet.

Csinált esetleg valaki ilyet már FreeBSD-vel, és Raspberry PI-vel?
Látszik, hogy a pxelinux.cfg/default-ba írok elérést, azt TFTP-n akarja elérni. Pontosan hova kellene tenni a tftpboot/rootfs/boot könyvtárat?
Ezt TFTP-vel fogja elérni a boot, vagy NFS-sel?
A cmdline.txt fájl tartalma mi legyen?

Köszönöm előre is.

Fall 2024 FreeBSD Summit

dlaszlo — Thu, 07 Nov 2024 17:38:48 +0000

FreeBSD-all

Megy most egy ilyen, hátha valakit érdekel:

https://freebsdfoundation.org/news-and-events/event-calendar/fall-2024-…

https://www.youtube.com/watch?v=jZ3mjJZEqs0

FreeBSD telepítése kérdés

Vad — Fri, 16 Aug 2024 03:36:57 +0000

FreeBSD-all

Lehet e FreeBSD-t erre a gépre telepiteni? :Lenovo ThinkStation P510. Processzor: 12x Intel Xeon CPU E5-1650 v4 3,60 GHz. Memoria: 32 GiB ECCRam . Grafika: AMD Radeon RX 570

Mi a bibi program telepítéskor?

Vad — Mon, 12 Aug 2024 08:24:17 +0000

FreeBSD-all

Tegnap óta , mikor is telepíteni akartam néhány programot a következőket tapasztaltam pl:

/home/vadbsd # pkg install handbrake
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'handbrake' have been found in the repositories

Bármit akrtam ugyan ez történt, Net van amit bizonyit ezaz üzenet is.

FreeBSD konzolban sh script futtatása. Hogyan? [ Megoldva ]

guszti — Thu, 11 Jul 2024 10:17:32 +0000

FreeBSD-all

Találtam egy desktop istaller script-et.
https://forums.freebsd.org/threads/desktop-environments-installation-script.93020/

Letöltöttem innen:
https://git.asdf.cafe/majekla/freebsd/src/branch/master/freebsd-desktop.sh

A fájlt futtathatóvá tettem chmod +x fájlneve módszerrel. A telepítés friss, root fiókban vagyok.

Nem tudom elindítani a scriptet, syntax error jön állandóan.

Erre:
sh freebsd-desktop.sh
Ezt kapom:
1: Syntax error: newline unexected (expecting word)

[Láma :-)] Konzolban hogyan görgetem vissza a képernyő tartalmát? [ Megoldva ]

guszti — Tue, 09 Jul 2024 16:28:56 +0000

FreeBSD-all

Láma kérdés, mert ezidáig nem nagyon kellett X nélkül konzolos felületen matatnom. Most jó lenne vissza nézni a képernyő tartalmat. FreeBSD telepítésben vagyok még GUI nélkül.

:-) :-)

GhostBSD-Van is hang, meg nincs is

guszti — Sun, 07 Jul 2024 18:27:44 +0000

FreeBSD-all

GhostBSD közösségi kiadás: Xfce4 környezettel. Ezen szinte nincs mit faragni, csak egy-két xfce4 kiegészítőt adtam hozzá. A grafikus csomagkezelővel "gyerekjáték".

Nagy bánatomra nem akar megszólalni a notim. Pedig YT video lejátszásakor a mixerben "mozog a csúszka", csak a hangszórókból nem jön hang.

Ilyen hibaüzit dob az egyik tálcaikon a tulajdonságokra:
"A GStreamer nem észlelt hangeszközöket. Lehetséges, hogy egyes hangrendszer-specifikius GStreamer csomagok hiányoznak.
Jogosultsági probléma is fennállhat."

Egy inxi kimenetből ollózva ilyen audio serverek vannak:

Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio driver: hdac
bus-ID: 0:0:31.3 chip-ID: 8086:a170
Sound Server-1: OSS v: 2009061500 running: yes
Sound Server-2: sndio v: N/A running: no
Sound Server-3: JACK v: 1.9.22 running: no
Sound Server-4: PulseAudio v: 16.1 running: yes

A felhasználóm ezen csoportoknak a tagja:

myzbook@myzbook-ghostbsd ~/Asztal> groups
myzbook wheel operator

Kell-e, van-e külön audio csoport, ha hangot szeretnék használni?
Alsamixer szerint semmi nincs lenémítva.

Szóval merre kéne indulni? Jogosultság? Initben valamit "beröffenteni"? Egyéb más csomagokat még feltenni?

"Otthoni szerver" fogyasztás optimalizálás

dlaszlo — Wed, 05 Jun 2024 19:25:28 +0000

FreeBSD-all

Kaptam kölcsön egy fogyasztásmérőt, amivel egy kis AMD-s otthoni szervert figyelek most meg:

AMD 5600G
Gigabyte B550M alaplap
Kingston DDR4 memória, 32 Gb.
2 db WD Red, és 1 db Toshiba HDD
550W-os Seasonic gold tápegység
Silicon Power M.2 SSD

Ez egy FreeBSD, de szerintem mindegy, hogy mi, az alapelvek ugyanazok lehetnek. Ebben a NAS-os thread-ben is felmerült az otthoni NAS-ok fogyasztása: https://hup.hu/node/185371

A gépen egy Samba fut, ZFS a fájlrendszer. Jailekben fut: AdGuard, Unifi kontroller, Transmission, Plex, Prometheus + Grafana (a transmission, és a plex csak alkalmanként futnak)

Jelenleg max 40W-ot jelez az eszköz, (36.5W - 38.4W között), ha ami csak a csövön kifér meghajtom a procit, akkor 100W-ot. Egy hét múlva ránézek erre az eszközre, hogy mennyit fogyaszott átlagosan, de ha 40W teljesítménnyel számolok, akkor ez kb 2000 Ft-ot jelent az áramszámlában. Ez elfogadható is lehet, de arra gondoltam, hogy ez kevesebb lesz, hiszen szinte semmit nem csinál a gép.

Ha próbaképpen leállítom a jail-eket, akkor 35-36W-ot mutat az eszköz (persze, lehet hogy ezt így nem lehet mérni, hanem ki kell várni hosszabb időket, és megnézni, hogy hány kWh volt a fogyasztás, mutatja ezt is)

Amivel próbálkoztam: https://man.freebsd.org/cgi/man.cgi?powerd

A powerd-t elindítottam, és itt ha a konnektorba van dugva a gép, akkor a default hiadaptive volt, ezt adaptive-ra állítottam. Most mindhárom beállítás adaptive:
       -a mode       Selects the mode to use while on AC power.
       -b mode       Selects the mode to use while on battery power.
       -n mode       Selects the   mode to   use normally when the AC line state is unknown.

A powerd szépen vissza is veszi a CPU frekvenciát:

# sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 3900/5265 1700/1615 1400/1277

# sysctl dev.cpu.0.freq
dev.cpu.0.freq: 1400

Előtte ez 3900 volt.

A C-stateket próbáltam még ki:

# sysctl dev.cpu |grep  cx
dev.cpu.0.cx_method: C1/hlt C2/io C3/io
dev.cpu.0.cx_usage_counters: 10 1748 0
dev.cpu.0.cx_usage: 0.56% 99.43% 0.00% last 22407us
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_supported: C1/1/1 C2/2/18 C3/3/350
stb...

A leírás alapján:

C1 stops clock on some parts of CPU core during inactivity. It is safe, cheap and supported by CPUs for ages. System uses C1 state by default.

C2 state allows CPU to turn off all core clocks on idle. It is also cheap, but requires correct ACPI-chipset-CPU interoperation to be used. Use of C2 state can be enabled by adding to /etc/rc.conf:
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"
Effect from this state is not so big when powerd is used, but still noticeable,

C3 state allows CPU completely stop all internal clocks, reduce voltage and disconnect from system bus. This state gives additional power saving effect, but it is not cheap and require trade-offs. As soon as CPU is completely stopped in C3 state, local APIC timers in each CPU core, used by FreeBSD as event sources on SMP, are not functioning. It stops system time, breaks scheduling that makes system close to dead. The only solution for this problem is to use some external timers.

C2-re állítottam a minimum szintet, ameddig lemehet. Ha jól értem, akkor a C3-ból a feléledés sok ideig tarthat, és költséges lehet. Ez mit jelent a gyakorlatban? Tehát ha pl a gépen fut egy adguard (dns szűrő), egy unifi controller, transmission, és fut prometheus, exporterekkel (kb 5 másodpercenként), tehát mindig van egy 0.5% CPU terheltség, akkor ha ez a C3 mód be is tud kapcsolni, lehet, hogy energiaigényesebb innen visszaállni?

A HDD-ket nyugodtan leállíthatom (szerintem), a rendszer SSD-ről megy, a HDD csak akkor kell elméletben, amikor tényleg adatot akarok elérni a NAS-ról, vagy másolok rá. Ezt még megnézem, hogy hogyan kell. - (bár 15 percenként van egy snapshot készítés 24 óráig, utána napi, heti, havi, stb... egy évig a zsaroló vírusok miatt.)

Az AMD Ryzen 5600G-re azt írják, hogy a default TDP 65W, de konfigurálható 45W-ra is. https://www.amd.com/en/product/11176

Amit még néztem:

rctl: https://klarasystems.com/articles/controlling-resource-limits-with-rctl… de most nem látok olyan folyamatot, amit limitálni kellene.
hdd standby mód.

Kérdések:

Valakitől, aki ért ehhez esetleg kérhetek segítséget, hogy mit lehet érdemes beállítani? A cél, hogy lekapcsoljak, minimumra vegyek mindent, ami éppen nem kell, ha használatban van a gép, akkor "mehet a kakaó".
Mi a helyzet ezzel a C3 state-tel? (amit fent írtam)
Az AMD-s 45W-os beállítást hol kell megtenni? A BIOS-ban nem találtam egy egyszerű kapcsolót erre. (Gigabyte B550M)
Mit lehet még tenni? (mi indokolja a 35W - 40W fogyasztást (0.5% CPU terhelés mellett) :)
Amúgy a synology-ban ezt baromi jól megcsinálták, szinte teljesen lekapcsol, ha nem használod (nekem sok dolog nem futott rajta). Idő is, amíg eléred a HDD-t utána. (egyébként ez egy nagyon jó példa, hogy miért érdemes a dobozos megoldást választani, ha valaki ezzel nem akar foglalkozni, ezek ott be vannak állítva :)

Köszönöm előre is.

tmux -> urxvt passthrough nem megy

uzsolt — Fri, 31 May 2024 05:25:07 +0000

FreeBSD-all

Nemrég találtam, hogy urxvt (rxvt-unicode) esetében is lehet háttérképet állítani (ld. pl. itt). Az eset, hogy tmux-szal a passthrough nem megy (szerintem).

Azaz urxvt-ben (zsh shellel megnyitva) a

printf "\e]20;/path/hatterkep.jpg;\a"

parancs hatására az urxvt háttere a megadott háttérkép lesz.

Viszont ha az urxvt-ben indítok egy tmux-ot, akkor az alábbi parancsnak nincs meg a várt eredménye:

 printf '\ePtmux;\e]20;/path/hatterkep.jpg;\a\e\\'

A tmux manuálja szerint:

 allow-passthrough [on | off | all]
               Allow programs in the pane to bypass using a terminal
               escape sequence (\ePtmux;...\e\\).  If set to on,
               passthrough sequences will be allowed only if the pane is
               visible.  If set to all, they will be allowed even if the
               pane is invisible.

Elvileg rendben van:

$ grep passthrough ~/.tmux.conf
set -p allow-passthrough on

Ha a link alapján a Ptmux; után dupla \e-t írok, akkor se megy.

Nem tudom, számít-e, de az operációs rendszer FreeBSD.

Hol rontom el? Hogyan bírhatnám a megfelelő működésre?

Konzol módba lépés bootoláskor

Vad — Mon, 15 Apr 2024 08:01:22 +0000

FreeBSD-all

Hogyan léphetek konzol módba a FreeBSD rendszer bootolásakor.

Ugyanis próbáltam az Alt+Ctrl+F1(F2) billentyű kombinációjával, mint ahogy a linuxnál szoktam de nem reagál.

PCI kártya, USB kártya

Vad — Fri, 08 Mar 2024 14:06:35 +0000

FreeBSD-all

A telepített rendszerre elkezdtem, sokszor csak próbaképpen, felrakni különféle alkalmazásokat. A bluetooth dolog még nem egészen tökéletes, mert az igaz, hogy most már a telefonok és a bluetooth fülhallgató és a FreeBSD látják egymást, viszont a fájlátvitel még megoldatlan. Kábelen tudok átvinni fájlokat a gépre a telefonról. Jó lenne valami Bluetooth GUI, mint ahogy a Wifinek már sikerült kreálnom. Megy a szkennelés, a nyomtatás viszont függőben van a nyomtató hibája miatt. Érdekes, hogy a gépben van PCI WiFi kártya de a bsd nem látja csak az USB WiFi kártyát, amit, ahogy írtam, be tudtam állítani és müködik. Aztán így vagyok a TV-tuner kártyákkal is. Az USB-s tunerkártya konfigurálva, bár még kép nincs, de a Web-kamera müködik. A PCI tunert viszont nem látja. Mi ennek az oka? A tunerkártyákról nem sok mindent találtam a handbookban. Tulajdonképpen a Tv-kártyák nem lét fontosságuak, inkább csak a kihívás miatt foglalkozok velük.

[Megoldva] xinit: server error

Vad — Wed, 24 Jan 2024 17:32:50 +0000

FreeBSD-all

Talán 8-10 éve telepítettem először a Free BSD-t. Emlékezetem szerint akkor a telepítéssel nem nagyon szenvedtem, annál inkább a grafikus driverrel és a bluetooth beállítással, a telepítés utáni gyatra felbontás miatt. Kb két évig használtam a rendszert aztán nem tudom miért, mást telepítettem a gépre. Néhány napja ujra fel akartam telepíteni, illetve fel is telepítettem vagy nyolc tíz alkalommal de a grafikus felületet nem töltötte be a rendszer hivatkozva a server hibára, illetve, hogy a rendszer nem kapcsolódik a szerverre. Két alkalommal a startx parancsra alcsony felbontásban elindult a grafikus felület, egyszer a KDE, egyszer pedig az XFCE, mindezek anélkül, hogy legalább a hálózati kártyá látható lett volna. A neten kutattam a hiba okára és látom, hogy nem ritka a probléma, aminek az okát talán valaki tudja itt a fórumon. A válaszokat előre is köszönöm.

OPNsense NAT Reflection (kérdések)?

veresh — Mon, 27 Feb 2023 09:48:19 +0000

FreeBSD-all

Sziasztok!

Szombaton Zentyal-ról átálltunk OPNsense-re. Minden a - korábban letesztelt - elvárt módon működik egy dolgot kivéve. A belső hálózat gépeiről nem érhetők el a belső hálózatban lévő weboldalak publikus URL-lel (az internet felől elérhető a belső hálózatban lévő weboldal; a szükséges NAT > Port Forward szabály fel van véve).

Az OPNsense dokumentációjában olvastam a NAT Reflection-ról, de nem fordítottam nagy figyelmet rá, és nincs is túl sok információ ezzel kapcsolatban az OPNsense dokumentációjában.

A Firewall > Settings > Advanced oldalon a Network Address Translation részben az alábbi három beállítás közül, az elsőt és a harmadikat bejelölve, a belső hálózat gépeiről is elérhető publikus URL-lel a belső hálózatban lévő egyik weboldal:

Reflection for port forwards
Reflection for 1:1
Automatic outbound NAT for Reflection

1. Kérdés: Ezt így kell / így a legjobb beállítani?

Azonban ezekkel a beállításokkal egyelőre csak a 80-as porton lévő weboldal érhető el. De ugyanazon a szerveren van egy másik weboldal is a 8080-as porton, és az nem érhető el (pedig a Firewall > NAT > Port Forward oldalon a 80 és a 8080-as portra is fel van véve a szabály).

2. Kérdés: Miért nem érhető el a 8080-as porton lévő weboldal a fenti beállítások mellett?

A pfSense oldalán találtam bővebb leírást: https://docs.netgate.com/pfsense/en/latest/recipes/port-forwards-from-l…

Itt írnak a DNS Split módszerről, amely "hasonló" lenne ahhoz, ahogy a Zentyal-on oldottam meg eddig (fel volt véve a külső publikus domain is a szükséges host / IP párral, ahol az IP-cím a belső privát címe volt a webszervernek), és ez annak ellenére működött, hogy nem a Zentyal volt a DNS szerver a hálózatban (igaz ez valószínűleg azért azért működhetett mert a Zentyal transzparens proxy volt).

3. Kérdés: A pfSense dokumentációban részletezett DNS Split módszer OPNsense esetén is beállítható, ha az OPNsense lenne a DNS forwarder a belső hálózatban lévő DNS szerver számára?