hello
linux

kube-proxy가 자구 crashbackoff 상태로 감

JHL

JHL

— 1 min read 
I0419 13:36:28.785450       1 proxier.go:833] "Sync failed" ipFamily="IPv6" retryingTime="30s"
E0419 13:36:58.830412       1 proxier.go:1564] "Failed to execute iptables-restore" err=<
	exit status 2: Warning: Extension MARK revision 0 not supported, missing kernel module?
	ip6tables-restore v1.8.9 (nf_tables): unknown option "--xor-mark"
	Error occurred at line: 17
	Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
 > ipFamily="IPv6"

로그를 확인하니 이런 상태

아래 문서를 보니

kube-proxy Pods Stuck in Crashloopbackoff Cycle
guide: how to fix kube-proxy pods stuck in crashloopbackoff
jmcglockjmcglock

커널 버전을 올려야 한다고 합니다.

그래서 아래 명령어로 강제로 6.8.0-58 버전으로 업그레이드 하였습니다.

sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu jammy-proposed main universe restricted multiverse"
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-22.04
sudo add-apt-repository -r "deb http://archive.ubuntu.com/ubuntu jammy-proposed main universe restricted multiverse"

Read more

llama4 실제 구현 결과 비교: Scout VS Maverick

당연히 Maverick이 압도적이겠지만 unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF/Llama-4-Scout-17B-16E-Instruct-UD-IQ2_XXS.gguf unsloth/Llama-4-Maverick-17B-128E-Instruct-GGUF/UD-IQ1_S/Llama-4-Maverick-17B-128E-Instruct-UD-IQ1_S-00001-of-00003.gguf 이 두개를 비교하고자 한다. 비교 방법은 코드 생성을 시켜서 그 코드가 의도한 결과가 나오는지 비교하는것이다. 프롬프트 " Write a single `app.py` file using **FastAPI** that does the following: 1. **GPU Monitoring Logger**: - Run

By JHL

llama4 돌려보기 (llama.cpp)

rtx4090, rtx3090x2 으로 총 72GB 구성된 환경에서 아래 모델을 돌려봄. 방법은 https://docs.unsloth.ai/basics/tutorial-how-to-run-and-fine-tune-llama-4 참고 unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF/Llama-4-Scout-17B-16E-Instruct-UD-IQ2_XXS.gguf ./llama.cpp/llama-cli --model unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF/Llama-4-Scout-17B-16E-Instruct-UD-IQ2_XXS.gguf --threads 32 --ctx-size 16384 --n-gpu-layers 99 --seed 3407 --prio 3 --temp 0.6 --min-p 0.01 --top-p 0.

By JHL