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.
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!
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:
A "Raspberry Pi Imager"-rel kiírtam a network boot-os bootloadert egy sd kártyára, és feltettem a raspberry pi-re.
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))
/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 /tftpbootaz inetd-t bekapcsoltam:
/etc/rc.conf:
inetd_enable="YES"inetd szolgáltatás elindítása:
service start inetd
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.xzA 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 /mntA 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/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 -alldirsNFS elindítása:
service start rcpbind
service start nfsd
service start mountdA 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 1468Tehá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:
É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.confAz 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/rootfsTehá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 1468Lá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.
Megy most egy ilyen, hátha valakit érdekel:
https://freebsdfoundation.org/news-and-events/event-calendar/fall-2024-…
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
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.
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 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 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?
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: 1400Elő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:
Kérdések:
Köszönöm előre is.