mastodon.green is one of the many independent Mastodon servers you can use to participate in the fediverse.
Plant trees while you use Mastodon. A server originally for people in the EU, but now open for anyone in the world

Administered by:

Server stats:

1.3K
active users

#supermicro

0 posts0 participants0 posts today

The Super Micro (SuperMicro or SUPERMICRO in some places) saga began one day when I needed a motherboard and they sold cheap PCs and motherboards. It was flaky - I think it kept resetting itself - so I went to their HQ to see if I could get it fixed or replaced.

It was a very small operation. Mom & pop. The engineer there was attentive. I got my problem solved. Somewhere I have that motherboard.

If I hadn't gone there then, where would they be now? Butterfly wings. You may thank me by throwing money.

Today they are an Nvidia AI vendor that dropped from $70,000,000,000 in stock valuation to $20,000,000,000. WHAT???

That tiny operation proves that you should never give up on your dreams!!

And also that you should sell your stock sooner.

mstdn.social/@cnbc_rss/1134030

Mastodon 🐘CNBC RSS Bot (@cnbc_rss@mstdn.social)Super Micro's $50 billion stock collapse underscores risk of AI hype https://www.cnbc.com/2024/10/31/super-micros-50-billion-stock-collapse-underscores-risk-of-ai-hype.html

Q: What do you look forward to on a Sunday morning?
A: Relaxing with calm music, a bowl of strawberries, and some quality time with NVDIMM Persistent Memory modules

03:19.. it's still early, plenty of time to debug IRQs! 😊

also, for whoever needs to know this newfangled manner of kernel command line arguments in Fedora/Redhat distros ... if you're tired of typing out the active kernel string when looking up its params via "grubby", here's a var-subshell substituted whatever call to ease those pains:

---
root@upgrayyed:~# grubby --info=$(grubby --default-kernel)
index=1
kernel="/boot/vmlinuz-6.10.7-200.fc40.x86_64"
args="ro resume=UUID=redacted rd.md.uuid=redacted rd.md.uuid=redacted console_msg_format=syslog loglevel=7 hibernate=no iommu=pt mem_encrypt=off selinux=0 nouveau.blacklist=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau console=tty0 console=ttyS0 console=ttyS1"
root="UUID=redacted"
initrd="/boot/initramfs-6.10.7-200.fc40.x86_64.img $tuned_initrd"
title="Fedora Linux (6.10.7-200.fc40.x86_64) 40 (Server Edition)"
id="e1f345d2eb0a4de3ab64da772c942e05-6.10.7-200.fc40.x86_64"
---

I went down the #ebay #ebitch hole last week, and found a #computer #workstation with a #Supermicro X8DA3 #Motherboard and a #Tableau T3458is #tableau #forensic Bridge

Shipping across the continent though - and how do you think it was packed?

#poorly

The damage to the plastic top of the workstation case, which is now falling off - though still connected by the wires going to the #USB & #firewire ports in the lid. Some loose cables and screws fell out when opening the case.

Reached out to the seller for #return and they offered to send a replacement. Waiting to see what is next...

I can't figure out what's wrong with my EFI boot setup. I have several Dell servers, and they boot fine from a SATA SSD via UEFI.

But my SuperMicro X9SCM-F (latest BIOS) doesn't like it. I can boot via MBR (legacy BIOS) without problems. And UEFI will find, and boot from, a USB CD-ROM (NetBSD iso image), and can also boot into the built-in UEFI console, but doesn't like my SSD.

Is there more to it than having a gpt with a 1MB-aligned FAT-formatted partition of type "efi", which contains "efi/boot/bootx64.efi", the latter being the NetBSD EFI bootloader?

That always seems to be have done the trick on other machines, but not this one. Maybe someone has an idea or can ask the right question.

Thanks.

Please boost.

#EFI #UEFI #boot #BIOS #Supermicro #NetBSD #homelab #server #efiboot #uefiboot #SuperMicroX9SCM