Actually encountered this problem a while ago, but forgot to write it up at the time
We have a Dell PowerEdge R630 that is running Proxmox 9. On update from kernel 6.14 to 6.17 the system started boot looping - the system would start to boot, and then early on when the kernel was booting it would stop and reset the machine. The iDRAC event logs showed that there were “Machine Check errors” occurring. Booting with the previous 6.14 kernel worked as normal.
Read more...
Scenario - ssh into a linux system from Windows using windows terminal/powershell, edit a file in nano and try and paste something.
Sometimes the terminal then freezes, and rings the bell on every keystroke or paste attempt. You can free it up by killing nano from another login session.
The problem is described in this thread:
This problem has been fixed in the latest versions of nano, but it will take a while to get into the distributions. The workaround in the meantime is to use something like PuTTY.
Scenario: Debian installed with nothing selected in the tasksel stage (not even the standard system utilities) - i.e. the most minimal install you can get with the standard installer. Once installed you then install the ssh server
This pulls in a bunch of dependencies, including dbus. You then can ssh into the system as normal. When trying to shutdown or reboot the system you get an error:
Read more...
The situation:
- Main network and private network (physically separate in this case)
- Main network has dhcp server
- Private network has dhcp server (server A, OPNsense in this case), which also acts as a router to main network
- Want to set up a separate system (server B) that we can ssh, rdp etc. into from main network to access private network
- Desire to use dhcp addressing for both interfaces on server B
A problem can arise with this setup if the server B uses server A as its default gateway for whatever reason. The outside network only sees the route to server B via server A, and when you try to remote access server B from the main network (using the appropriate IP address for the main network interface) it fails, as it routes via server A and doesn’t go anywhere.
Read more...
We have a setup where various systems export scratch directories to each other for convenience. An export is set up like:
/etc/exports
/local/scratch -rw,root_squash,no_subtree_check,sync 192.168.2.0/24
Autofs maps come from LDAP - the autofs configuration is:
/etc/autofs.conf
[autofs]
timeout = 300
browse_mode = no
mount_nfs_default_protocol = 4
ldap_uri = ldap:///dc%3Dldap%2Cdc%3Dyour%2Cdc%3Dserver%2Cdc%3Ddns%2Cdc%3Dname
search_base = ou=maps,ou=subsubunit,ou=subunit,o=organisation
map_object_class = nisMap
entry_object_class = nisObject
map_attribute = nisMapName
entry_attribute = cn
value_attribute = nisMapEntry
[ amd ]
dismount_interval = 300
If server A (ip address 192.168.2.101) exports the directory, server B (ip address 192.168.2.102) that also gets the autofs maps automounts this as expected when accessing the desired directory. The findmnt command shows:
Read more...