'forgot' password ? Couldn't generate salt
I did a sysupgrade to amd64 to _RC5 (from _RC3), but it seems to have reset my passwords. The accounts are there, just the passwords have been changed. Tried logging in single-user as described in https://www.netbsd.org/docs/guide/en/chap-boot.html # passwd root ... Couldn't generate salt. Unable to change auth token: Error in service module # And of course, the password is not changed, and I still can't log in. I'm probably doing something dumb. Thanks for any help/pointers. -Mike
GTX-1660 nVidia and doomlegacy
Has anyone got doomlegacy working -- using 1280x1024, or 1920x1080?? I have also changed from /usr/X11R7 to modular-xorg What about updating modular-xorg ? I am running NetBSD 10.0RC2 Here is dmesg stuff: kern.module.path=/stand/amd64/10.0/modules nouveau0: NVIDIA TU116 (168000a1) nouveau0: bios: version 90.16.25.40.63 nouveau0: interrupting at msi6 vec 0 (nouveau0) nouveau0: fb: 6144 MiB GDDR5 Zone kernel: Available graphics memory: 9007199252283418 KiB Zone dma32: Available graphics memory: 2097152 KiB nouveau0: DRM: VRAM: 6144 MiB nouveau0: DRM: GART: 536870912 MiB nouveau0: DRM: BIT table 'A' not found nouveau0: DRM: BIT table 'L' not found nouveau0: DRM: TMDS table version 2.0 nouveau0: DRM: DCB version 4.1 nouveau0: DRM: DCB outp 00: 02800f66 04600020 nouveau0: DRM: DCB outp 01: 02000f62 04620020 nouveau0: DRM: DCB outp 03: 02011f52 00020010 nouveau0: DRM: DCB outp 04: 01822f36 04600010 nouveau0: DRM: DCB outp 05: 01022f32 04620010 nouveau0: DRM: DCB outp 06: 01833f46 04600020 nouveau0: DRM: DCB outp 07: 01033f42 04620020 nouveau0: DRM: DCB conn 00: 00020046 nouveau0: DRM: What about updating modular-xorg ?DCB conn 01: 00010161 nouveau0: DRM: DCB conn 02: 1246 nouveau0: DRM: DCB conn 03: 2346 nouveau0: DRM: MM: using COPY for buffer copies [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. nouveaufb0 at nouveau0 [drm] Initialized nouveau 1.3.1 20120801 for nouveau0 on minor 0 nouveaufb0: framebuffer at 0x4040, size 1920x1080, depth 32, stride 7680 wsdisplay0 at nouveaufb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
Re: NetBSD and ECC RAM?
kevin.bowl...@kev009.com (Kevin Bowling) writes: >Servers tend to have BMCs, so you can execute 'ipmitool sensors' and >'ipmi sel elist' to get the information out. ECC information is usually not provided by sensors. ECC errors may be listed in the SEL, but even this usually occurs only when some undocumented limit is reached. Often the messages also do not indicate the memory module that produced the error. >Linux has the 'EDAC' subsystem but I don't think it gains you so much >if you have a BMC. It gives you the data from the ECC circuits, immediately. So data is no longer hidden by the BMC, you get precise information and you can apply your own policies for e.g. replacing memory modules or migrating services to other hardware. The OS could be smart, lock out bad memory regions, recover some errors by e.g. paging in text data again or even use mirrored RAM (with motherboard support). >A lot of fragile chipset specific code to get that. Indeed. Greetings,
Re: NetBSD and ECC RAM?
On Mon, Feb 19, 2024 at 12:19 AM Michael van Elst wrote: > > michael.chepo...@gmail.com (Michael Cheponis) writes: > > >I've been running ECC in the Windows box for years, it seems like a 'no > >brainer' for servers. Servers usually run for years, and Stuff Happens over > >the years [1]. > >But I'd prefer a reliable, unhackable, trustable compute fabric. ECC is > >part of the 'reliable' part. > > I agree, but the "box" will run with ECC, even when the OS doesn't > know about it. OS support is needed to get information about errors > and for better fault tolerance. Servers tend to have BMCs, so you can execute 'ipmitool sensors' and 'ipmi sel elist' to get the information out. Linux has the 'EDAC' subsystem but I don't think it gains you so much if you have a BMC. Kernel printfs for some errors and character drivers to do userspace development. And it would support systems without BMCs. A lot of fragile chipset specific code to get that. > > >I would also like to see per /dev entry ACLs. I would like to see better > >security than owner-group-everbody permissions. > > I have rarely seen ACLs being used for "better security". Even when that > was possible, the complexity usually outweighed any gain in control. > > Systems that implied access control through simple rules worked much > better. It's still not a feature that you had to enable or a switch > you toggled, it requires constant effort, in particular on systems > that don't just perform a fixed set of functions. >
