Gigabyte MJ11-EC1 NAS Server

[MrOpuki]

@F|Marsman Ja ich denke auch dass das Board hin ist. Ich lasse es jetzt noch mit dem TrueNAS Scale laufen und schauen ob bzw. wie lange die Verbindung stabil bleibt.

Mittlerweile habe ich mal zum Test mit dem Board unter Proxmox ein "virtuelles NAS" gebaut und 2 andere HDDs durchgereicht, was erstaunlicher Weise echt gut klappt. Per virtio NIC bekomme ich von Win 11 aus 98 MB/s rübergeschoben. Das ist gar nicht so schlecht.

Nur blöd dass ich für meine 10 GBit/s jetzt nen anderen Adapter brauche der liegt in NL (kommt aus China) und ist dann hoffentlich die Tage hier. Wäre dann ne Wollmilchsau aus Proxmox mit NAS drin und allen VMs.

 

[F|Marsman]

Ist ja grundsätzlich auch sone Eierlegendewollmilchsau wenns denn läuft... also schon sone kleine Zicke

 

[marco-mh]

das Problem mit den Netzwerkanschlüssen on Board hab ich glaub ich auch. auf einmal keine Verbindung mehr und alle netztlaufwerke melden sich ab. hmmm @F|Marsman vielleicht ist das nicht nur nen RAM Problem. ich hab jetzt mal die NIC Bündelung deaktiviert, aber bringt auch nix. auf einmal nicht mehr erreichbar. Weiß aber nicht ob es wirklich an den NICs liegt. er macht nämlich nen Array Check wo die Festplatte rappeln und auf einmal ist ruhe. wenn ich so drüber nachdenke wahrscheinlich doch die RAMs. hmmm

 

[MrOpuki]

@marco-mh also zum Vergleich, im NAS Board habe ich 2x 16GB ECC 2133er, Samsung. Im Proxmox 4x 32GB ECC Regged und die laufen ganz brav mit 2133. vielleicht ist das Board ja auch zickig mit nicht Regged RAM.

*Edit*
Nevermind, eben gesehen dass dein HMA84GR7AFR4N-UH RAM Regged ist. Dann brauche ich das nicht mit meinem Proxmox RAM testen :/

Aber das Verhalten ist bei mir identisch.

PS ich hatte den schon auf 933 also 1866 im BIOS gesetzt - brachte auch nix.

 

[marco-mh]

ich hab 4 von denen, mom aber nur 2 auf dem Board. Diese Rigel stehen ohne UH in der Liste. die kleinen Details ... hab sie mit Hilfe von @F|Marsman auf 2133 begrenzt. aber so richtig wolle sie noch nicht, nen häufen ECC Fehler und Abstürze. Von was auch immer, NIC Fehler sind auch dabei. So möchte ich das nicht als meinen Unraid Daten, Paperless-ngx und HA Server laufen lassen. Das ist mir zu gefährlich. Ich hab mir das Datenblatt des Herstellers besorgt, mal sehen ob da was geht.

 

[Paddy600]

Die einfachste (ram bezogene) Lösung wäre halt Samsung Riegel zu verwenden. Dieses board ist halt etwas wählerisch bei RAM.

Da scheint hier im Forum ja bis jetzt keiner wirklich Probleme gehabt zu haben.

 

[MrOpuki]

@Paddy600 Wie man es nimmt Ich habe ja 2x Samsung ECCs in dem betroffenen Board -> Samsung 2x16GB (32GB) 2Rx4 PC4-2133P Server RAM ECC DDR4 M393A2G40DB0-CPB0Q

Ok jetzt bin ich verwirrt - der ID des RAMs nach ist das sogar auch ECC Regged (-> Samsung Webseite)

Hier mal aus einem Chat mit ChatGPT was man noch machen könnte:

Da die externe ConnectX-3 SFP+-Karte stabil läuft, scheint das Problem tatsächlich auf die onboard NICs beschränkt zu sein. Hier sind einige weitere Vorschläge:

### 1. **Interrupt-Balancing optimieren**
- Verteile die Interrupts gleichmäßiger, um mögliche Ressourcenprobleme zu minimieren:

bash
     apt install irqbalance
     systemctl enable irqbalance --now

### 2. **Link-State-Überwachung deaktivieren**
- Die NIC könnte durch fehlerhafte Link-State-Checks in den Ruhezustand wechseln:

bash
     ethtool -s eth0 wol d

### 3. **Hardware-Fehler ausschließen**
- Teste die onboard NICs unter einem anderen Betriebssystem (z. B. Windows oder einem Linux Live-System), um ein Hardwareproblem sicher auszuschließen.

### 4. **Netzwerkdiagnose erweitern**
- Überwache die onboard NICs mit Tools wie `ip monitor` oder durch Analyse der System-Logs:

bash
     dmesg | grep -i eth
     journalctl -k | grep e1000e

Falls die onboard NICs trotz aller Tests weiterhin instabil bleiben, könnte es eine Inkompatibilität oder einen Hardware-Defekt geben. In diesem Fall wäre Gigabyte-Support oder ein dauerhafter Wechsel auf die stabile ConnectX-3-Lösung sinnvoll.

Ich mache gerade das Update auf die BMC Version 12.61.21. Vielleicht hilft's ja. F09 haben beide Boards, aber die aktuelle BMC Version nur der Proxmox Server.

 

[MrOpuki]

Guten Morgen/Mittag,

ich habe das TrueNAS mit den Änderungen seit gestern durchlaufen lassen, bis 6:00 heute Morgen war alles super, als ich dann gegen 10:30 nochmal nachgeschaut habe, war es dunkel auf der NIC (onboard, unterer Port - das Problem hatte ich aber auch auf dem oberen Port zuvor).

Zum Glück kann ich über die 10G Karte noch per SSH rein. Hier mal der Logauszug:

Spoiler: Logauszug

Nov 16 10:03:29 truenas kernel: ------------[ cut here ]------------
Nov 16 10:03:29 truenas kernel: NETDEV WATCHDOG: enp5s0 (igb): transmit queue 3 timed out 9248 ms
Nov 16 10:03:29 truenas kernel: WARNING: CPU: 6 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel: Modules linked in: sr_mod(E) cdrom(E) joydev(E) cdc_ether(E) uas(E) usbnet(E) usb_storage(E) mii(E) xt_nat(E) xt_tcpudp(E) veth(E) xt_conntrack(E) nft_chain_nat(E) xt_MASQUERADE(E) nf_nat(E) nf_conntrack_netlink(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) xfrm_user(E) xfrm_algo(E) xt_addrtype(E) nft_compat(E) nf_tables(E) libcrc32c(E) crc32c_generic(E) nfnetlink(E) br_netfilter(E) bridge(E) stp(E) llc(E) nvme_fabrics(E) nvme_core(E) overlay(E) sunrpc(E) binfmt_misc(E) ntb_netdev(E) ntb_transport(E) ntb_split(E) ntb(E) ioatdma(E) ipmi_ssif(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) edac_mce_amd(E) kvm_amd(E) kvm(E) irqbypass(E) ghash_clmulni_intel(E) sha512_ssse3(E) sha256_ssse3(E) sha1_ssse3(E) aesni_intel(E) crypto_simd(E) cryptd(E) rapl(E) snd_hda_intel(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) evdev(E) ast(E) snd_timer(E) snd(E) drm_shmem_helper(E) acpi_cpufreq(E) pcspkr(E) sp5100_tco(E) soundcore(E) k10temp(E) drm_kms_helper(E) watchdog(E)
Nov 16 10:03:29 truenas kernel:  ccp(E) acpi_ipmi(E) ipmi_si(E) ipmi_devintf(E) ipmi_msghandler(E) button(E) sg(E) loop(E) efi_pstore(E) drm(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) zfs(POE) spl(OE) efivarfs(E) mlx4_ib(E) ib_uverbs(E) ib_core(E) mlx4_en(E) hid_generic(E) usbhid(E) hid(E) sd_mod(E) t10_pi(E) crc64_rocksoft(E) crc64(E) crc_t10dif(E) crct10dif_generic(E) ahci(E) ahciem(E) libahci(E) libata(E) xhci_pci(E) crct10dif_pclmul(E) crct10dif_common(E) crc32_pclmul(E) xhci_hcd(E) scsi_mod(E) crc32c_intel(E) i2c_piix4(E) scsi_common(E) igb(E) usbcore(E) usb_common(E) i2c_algo_bit(E) mlx4_core(E) dca(E)
Nov 16 10:03:29 truenas kernel: CPU: 6 PID: 0 Comm: swapper/6 Tainted: P           OE      6.6.44-production+truenas #1
Nov 16 10:03:29 truenas kernel: Hardware name: GIGABYTE G431-MM0-OT/MJ11-EC1-OT, BIOS F09 09/14/2021
Nov 16 10:03:29 truenas kernel: RIP: 0010:dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel: Code: ff ff ff 48 89 df c6 05 b6 26 40 01 01 e8 f3 2c fa ff 45 89 f8 44 89 f1 48 89 de 48 89 c2 48 c7 c7 60 f9 d1 9b e8 cb 16 6b ff <0f> 0b e9 2a ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90
Nov 16 10:03:29 truenas kernel: RSP: 0018:ffffa0b600600e70 EFLAGS: 00010286
Nov 16 10:03:29 truenas kernel: RAX: 0000000000000000 RBX: ffff8fbdea82c000 RCX: 0000000000000000
Nov 16 10:03:29 truenas kernel: RDX: ffff8fc4bd3adb00 RSI: ffff8fc4bd3a13c0 RDI: 00000000000400f6
Nov 16 10:03:29 truenas kernel: RBP: ffff8fbdea82c488 R08: 0000000000000000 R09: ffffa0b600600cf8
Nov 16 10:03:29 truenas kernel: R10: 0000000000000003 R11: ffff8fc4bd1fffe8 R12: ffff8fc1682843c0
Nov 16 10:03:29 truenas kernel: R13: ffff8fbdea82c3dc R14: 0000000000000003 R15: 0000000000002420
Nov 16 10:03:29 truenas kernel: FS:  0000000000000000(0000) GS:ffff8fc4bd380000(0000) knlGS:0000000000000000
Nov 16 10:03:29 truenas kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 16 10:03:29 truenas kernel: CR2: 00007f6aeaffdd58 CR3: 0000000192988000 CR4: 00000000003506e0
Nov 16 10:03:29 truenas kernel: Call Trace:
Nov 16 10:03:29 truenas kernel:  <IRQ>
Nov 16 10:03:29 truenas kernel:  ? dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel:  ? __warn+0x81/0x130
Nov 16 10:03:29 truenas kernel:  ? dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel:  ? report_bug+0x171/0x1a0
Nov 16 10:03:29 truenas kernel:  ? apic_mem_wait_icr_idle+0x14/0x20
Nov 16 10:03:29 truenas kernel:  ? handle_bug+0x41/0x70
Nov 16 10:03:29 truenas kernel:  ? exc_invalid_op+0x17/0x70
Nov 16 10:03:29 truenas kernel:  ? asm_exc_invalid_op+0x1a/0x20
Nov 16 10:03:29 truenas kernel:  ? dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel:  ? __pfx_dev_watchdog+0x10/0x10
Nov 16 10:03:29 truenas kernel:  call_timer_fn+0x27/0x130
Nov 16 10:03:29 truenas kernel:  ? __pfx_dev_watchdog+0x10/0x10
Nov 16 10:03:29 truenas kernel:  __run_timers+0x222/0x2c0
Nov 16 10:03:29 truenas kernel:  run_timer_softirq+0x1d/0x40
Nov 16 10:03:29 truenas kernel:  handle_softirqs+0xda/0x2c0
Nov 16 10:03:29 truenas kernel:  __irq_exit_rcu+0x98/0xc0
Nov 16 10:03:29 truenas kernel:  sysvec_apic_timer_interrupt+0x72/0x90
Nov 16 10:03:29 truenas kernel:  </IRQ>
Nov 16 10:03:29 truenas kernel:  <TASK>
Nov 16 10:03:29 truenas kernel:  asm_sysvec_apic_timer_interrupt+0x1a/0x20
Nov 16 10:03:29 truenas kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x440
Nov 16 10:03:29 truenas kernel: Code: 8a 7d 53 ff e8 35 f4 ff ff 8b 53 04 49 89 c5 0f 1f 44 00 00 31 ff e8 f3 b9 52 ff 45 84 ff 0f 85 57 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 85 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d
Nov 16 10:03:29 truenas kernel: RSP: 0018:ffffa0b6000f7e90 EFLAGS: 00000246
Nov 16 10:03:29 truenas kernel: RAX: ffff8fc4bd3b3440 RBX: ffff8fbde9f28400 RCX: 000000000000001f
Nov 16 10:03:29 truenas kernel: RDX: 0000000000000006 RSI: 000000002f684d00 RDI: 0000000000000000
Nov 16 10:03:29 truenas kernel: RBP: 0000000000000002 R08: 0000000000000002 R09: 0000000000000501
Nov 16 10:03:29 truenas kernel: R10: 0000000000000018 R11: ffff8fc4bd3b1fe4 R12: ffffffff9c5a6380
Nov 16 10:03:29 truenas kernel: R13: 000041ff1040fd35 R14: 0000000000000002 R15: 0000000000000000
Nov 16 10:03:29 truenas kernel:  cpuidle_enter+0x2d/0x40
Nov 16 10:03:29 truenas kernel:  do_idle+0x20d/0x270
Nov 16 10:03:29 truenas kernel:  cpu_startup_entry+0x2a/0x30
Nov 16 10:03:29 truenas kernel:  start_secondary+0x11e/0x140
Nov 16 10:03:29 truenas kernel:  secondary_startup_64_no_verify+0x18f/0x19b
Nov 16 10:03:29 truenas kernel:  </TASK>
Nov 16 10:03:29 truenas kernel: ---[ end trace 0000000000000000 ]---
Nov 16 10:03:29 truenas kernel: igb 0000:05:00.0 enp5s0: Reset adapter

Klar, ohne Netzwerk kein NTP, was er dann auch beanstandet, zumindest der Plex Container:

Nov 16 11:00:13 truenas dockerd[4475]: time="2024-11-16T11:00:13.138646511+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.16.1.2:52395" dns-server="udp:10.0.0.1:53" error="read udp 172.16.1.2:52395->10.0.0.1:53: i/o timeout" question=";plex.tv.\tIN\t AAAA"
Nov 16 11:00:13 truenas dockerd[4475]: time="2024-11-16T11:00:13.138630201+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.16.1.2:47939" dns-server="udp:10.0.0.1:53" error="read udp 172.16.1.2:47939->10.0.0.1:53: i/o timeout" question=";plex.tv.\tIN\t A"

Auf 10.0.0.1 läuft bei mir der UniFi Cloud Gateway Ultra auf dem auch DNS und NTP laufen.

Für mich sieht das Log oben irgendwie aus wie nen "kleiner" Kernel Panic, Hardwarefehler würde ich sagen.

Ich glaube mit dem Board bin ich durch. Ich werde heute meine 3x 18TB schnappen und das NAS dann im Proxmox System virtualisieren, wobei ich noch mit mir hadere ob es nun Xpenology (läuft im Test mit meinen 2x 6TB WDs einwandfrei) oder TrueNAS Scale wird (dann bräuchte ich den zpool nur importieren). Ein Fan von TrueNAS bin ich allerdings nicht wirklich, weil ich mich mit den Backups schwer tu, bei DSM steckste ne USB Platte an, Hyper Backup -> da hin. Fertig. Bei TrueNAS geht es wohl ähnlich mit ner Snapshot Replikation - aber da müsste ich mich belesen.

Nochmal zusammengefasst was ich ausprobiert hatte:

• anderen NIC Port ausprobiert
• BMC Firmware aktualisiert auf die neuste Version
• CMOS & BIOS Reset
• BMC Reset
• BMC NIC auf "dedicated" gestellt
• Netzteil Reset
• RAM auf 933/1866 gedrosselt im BIOS

Ich glaube mehr kann ich jetzt von meiner Seite aus nicht mehr machen. Auch wenn es blöd ist, aber so werde ich das Board dem Händler wohl zurückgeben müssen.

Positiv ist allerdings: das virtualisieren des NAS klappt so wunderbar, dass es mir auch ordentlich Strom sparen wird + ich kann Snapshots vor Updates machen, zumal ich die komplette Perfomance von dem Epyc nicht für nen NAS "vergeude".

Leider hat es die PostNL noch nicht geschafft den 8i auf PCIe x8 Adapter an unsere Post zu übergeben, so dass ich dann wohl ein paar Tage auf die 10G verzichten muss. Ist zum "Betanken" des NAS dann natürlich doof Oder ich gedulde mich bis das hier ist.

---
Als ob der Post noch nicht lang genug wäre, habe ich nochmal alles bei ChatGPT eingeworfen und der hat folgendes empfohlen:

Die Fehlermeldung im Syslog deutet auf einen Timeout der Transmit-Queue und einen Reset des Adapters hin. Es könnte mehrere Ursachen geben, darunter Hardware-Fehler, Firmware-Fehler oder Treiberprobleme. Folgende Ansätze könnten helfen:

---

### **1. Power Management deaktivieren**
Die **igb**-Treiber könnten durch Energiesparfunktionen instabil werden. Deaktiviere Power-Management-Optionen für die betroffenen NICs:

ethtool -K enp5s0 tx off tso off gso off gro off

Zum Testen kannst du diese Einstellungen in `/etc/network/interfaces` oder in einer anderen netzwerkbezogenen Konfigurationsdatei für den Bootvorgang dauerhaft machen.

---

### **2. Offloading deaktivieren**
Deaktiviere TCP-Offloading, da dies häufig mit NICs wie **igb** Probleme verursacht:

ethtool -K enp5s0 rx off tx off

---

### **3. Kernel-Parameter anpassen**
Ergänze folgende Parameter beim Bootvorgang in der GRUB-Konfiguration (`/etc/default/grub`):

GRUB_CMDLINE_LINUX="pci=noaer pcie_aspm=off"

Aktualisiere GRUB anschließend:

update-grub
reboot

Diese Parameter deaktivieren ASPM (Active State Power Management) und unterdrücken PCI-Fehlermeldungen.

---

### **4. Treiber-Spezifische Einstellungen**
Passe die Interrupt-Moderation für den **igb**-Treiber an, was die Stabilität erhöhen könnte:

echo "options igb InterruptThrottleRate=1,1" > /etc/modprobe.d/igb.conf
update-initramfs -u
reboot

Anmerkung: Das klappt in TrueNAS Scale nicht:

root@truenas:~# update-initramfs -u
ln: failed to create hard link '/boot/initrd.img-6.6.44-production+truenas.dpkg-bak': Read-only file system
cp: cannot create regular file '/boot/initrd.img-6.6.44-production+truenas.dpkg-bak': Read-only file system

---

### **5. Test mit anderem Kernel**
Teste einen alternativen Kernel (z. B. einen LTS-Kernel), da Fehler in neuen Kernel-Versionen nicht ausgeschlossen sind. Du kannst dies mit TrueNAS einfach umsetzen, indem du eine andere Version bootest.

---

### **6. Hardware-Überprüfung**
Da der Fehler auch bei anderen Mainboards mit diesem Chipsatz auftritt, könnte es ein spezifisches Problem mit der Hardware sein. Wenn Gigabyte den Fehler nicht beheben kann, bleibt die Nutzung eines externen NICs (z. B. deiner ConnectX-3-Karte) eine stabile Lösung.

---

Falls das Problem weiterhin besteht, könnten Logs von `dmesg` während des Ausfalls helfen, weitere Einblicke zu erhalten.

 

[Paddy600]

Also ich hab das Board jetzt seit mehr als 6 Monaten mit TrueNAS Scale am laufen und hatte nie Probleme mit dem LAN. Ohne irgendwelche Settings etc. Zu ändern.

Wenn es bei Dir also out of the box nicht geht, dann wird wohl einfach dein Board ne Macke haben.

Aber unabhängig davon, würde ich sowieso empfehlen die 10G Karte für das Netzwerk zu nehmen. Die Dinger sind einfach viel zuverlässiger als die internen.

 

[MrOpuki]

Da fehlt mir leider aktuell der 10G Switch für

Ich habe aktuell eine Direktverbindung mit nem 30m Kabel von meinem Arbeitszimmer aus in den Keller direkt in die 10G Karte. Da ich vor kurzem erst auf UniFi im ganzen Haus umgestellt habe und in dem Zuge auch den PC meiner Frau und meines Kindes auf 2,5G anheben würde, wäre ich direkt mal eben knappe 480€ für sowas hier los: Ubiquiti UniFiSwitch Enterprise 8 Desktop 2.5G Managed Switch, 8x RJ-45, 2x SFP+, 120W PoE+

Klar, da könnte mal sein einen Zyxel zwischen setzen oder den Mikrotik mit 4x SFP+, aber fände ich dann irgendwie "doof".

---

Ist es nicht "merkwürdig", dass ausgerechnet die Intel Karten (igb Treiber) hier die AER Fehler melden?

---
Na immerhin ist die Verbindung zwischen dem nun virtualisierten NAS (TrueNAS Scale) und einer anderen VM (Win Server 2022) recht zügig (auf dem gleichen Host natürlich)

 

[Paddy600]

Ich würde so was hier nehmen. Hab ich bei meinem Windows PC auch seit Jahren im Einsatz weil der Intel 2,5gbit andauernd ausfälle hat. Gibts auch günstiger als 1gbit Version.

https://www.amazon.de/Transceiver-10GBase-T-Kompatibel-SFP-10G-T-S-UF-RJ45-10G/dp/B01M8O3MAL?th=1

Ein Port für die direktverbindung und ein port per rj45 Adapter in den Router.

Ein 10/25gbit Swtich ist (Meiner Meinung nach!) in 99% der Fälle komplett überzogen. Allein der Stromverbauch von so einem Ding ...

 

[gmipf]

Bezüglich des SAS 4i Konnektors, ist dies das richtige Kabel dafür? https://item.taobao.com/item.htm?id=688706976512&skuId=4905150072563

Und würden folgende Adapter funktionieren mit SSDs?

Für U.2 SSDs: https://detail.tmall.com/item.htm?id=524568694847&skuId=5676655546437

Für M.2 SSDs (dieser scheint mir zu groß, eventuell kompaktere Alternative?): https://www.amazon.de/gp/product/B09FJYTSBK/?th=1

 

[Shihatsu]

Ich hab den hier:

https://www.amazon.de/dp/B08W3GQ2MS?ref=ppx_yo2ov_dt_b_fed_asin_title

Ich beiß echt noch in meinen Tisch. Adapter da, läuft, erst mal fliegend getestet. So weit so gut, also ran an den Einbau...

Spoiler: Warning: Profany, Swearing, Full Tilt

MEIN VERFICKTES NETZTEIL HAT NUR DURCHGEHENDE ODER ZUR FALSCHEN SEITE ABGEWINKELTE SATA STROMSTECKER FFFFFFFFFFFFFFFFFFFSSSSSSSSSSSS FICK DICH DU FICKENDER FICK FICK WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Sorry, das musste jetzt einfach raus. Ich schau dann mal nach ner 20cm Sata Strom Verlängerung...

 

[besterino]

Haste etwa kein Material zum selber Crimpen da oder wat? Wenne so unprofessionell in der Weltgeschichte rumgammelst, darfste Dich aber echt nicht uffrege…

 

[Shihatsu]

Ogott Sata hab ich das letzte mal vor ~8 Jahren gecrimpt, und mein ganzes Crimpzeug ist zusammen mit dem Wakü-Zeugs in den Keller verbannt - dafür ist mir meine Freizeit mittlerweile zu schade. Verlängerung ist schon bestellt.

 

[besterino]

Na bitte. Also hasse NOCH weniger Grund Dich aufzuregen, alles wasse brauchst is im Keller und Du bist nur zu faul, mal die zwei Treppen runterzustiefeln… nähnäh, so jibt dat nix.