Ooh, no, I don’t think so. That’s a good shout! I shall get back to you in a few days…
1 Like
Bluetooth no longer working after powerloss
Yesterday I accidentially pulled the wrong powercable out of the socket and caused a sudden powerloss of my Asus Pro WS WRX80E-SAGE SE WIFI Threadripper Pro workstation.
After powering on again I could no longer connect to any bluetooth devices. ‘bluetoothctl list’ didn’t show any bluetooth adapter. I’ve tried rebooting / reseting / power off / power on the system, disabling / reenabling bluetooth in bios, but bluetooth didn’t came back to life.
While invetigating I found the hciconfig command, I saw that hci0 was in a down state, and hciconfig hci0 up did nothing.
Luckily with command ‘hciconfig hci0 reset’ I finally could reset the bluetooth adapter state, and after a reboot, bluetooth worked again as before the powerloss.
4 Likes
ouch…
Phew! you fixed it!
Glad you mentioned this, and also the fix!
So many unfixed problems, and unanswered questions, Real nice to see a whole story in one post!
1 Like
Excellent report!
Glad you were able to fix your own issue!
1 Like
I am on Debian 11 and when I run sudo apt-get upgrade it tells me two packages have been held back.
The following packages have been kept back:
linux-headers-amd64 linux-image-amd64
Where as just running the same command with apt gets ready to install them. I have always been using apt-get and I am wondering the reason apt-get is hesitant to install the above updates are because they appear to be kernel related and maybe have a chance of breaking the system?
Just wanted to know whether I should run the apt command and not worry about this. I have Nvidia drivers that installed kernel modules so bit worried the two updates above have the potential to mess with that.
This means that there is potentially something system breaking or requires packages to be uninstalled.
apt is the human friendly front end to apt-get. Unless you are scripting something, you should be using apt instead of apt-get. It will not hurt anything but there is less logic going on and apt-get assumes that you know what you are doing.
Remember that an upgrade will only add and update software, it will never uninstall anything.
A dist-upgrade or full-upgrade will update software to the latest and greatest while removing old, deprecated, or unsupported software along the way. Also, if you are using the named generic repositories (oldstable, stable, testing, unstable, experiemental) instead of the Named (Toy Story) branches, either of those commands will get you to the current version of that release. This is good to do after major releases.
2 Likes
Hi All I’ve not been around for ages. I’m still a noob but manage to fix
things mostly myself. I just don’t know where to look.
Here is my ‘little’ problem.
I had a working 20.04.4 Ubuntu with NVIDIA 2 gpu 1x for vfio-pci and
pass through the other was using the NVIDIA driver. All worked well
However, now the proprietary NVIDIA driver is’nt loading correctly, so
I’m using the nouveau.
Here are the symptoms
When I boot the system it was booting to a blank screen. I could SSH on.
I tried again today and it boots slowly, eventually getting to a point I
can log in with SSH but still waiting on a start job which looks like
“detect system changes” but its missing part of the message, the
resolution is still low and that was left for 20 minutes without finishing.
It then would not reboot getting stuck after target reboot waiting on
modprobe
Here is what I’ve tried.
- I reverted to the previous kernel I had and reinstalled the older
driver again: same blank screen, I did that from SSH
From SSH I tried
sudo lspci | grep ‘VGA’ | cut -d" " -f 1 | xargs -i lspci -v -s {}
which showed one GPU ( the right one) using the NVIDIA driver
- I noticed that I could use the console by dropping the run level to 3
but the problem persisted if i reverted to 5. I also tried to replace my
xorg.conf or something with a blank one and iirc tried something like
dkms reconfigure xorg kind of was wondering if it had set screen
res/refresh wrong but its a 165Hz screen
-
I removed the nouveau completely: same issue
-
I removed apt remove nvidia* and installed nouveau but left my
black-listing intact: it booted to a low res desktop, so I’m resonably
confident that the blacklist was right
- I removed the blacklist and some NVIDIA things from my
/etc/default/grub and /etc/modules-load.d/modules.conf and used the
desktop normally: to prove that things were functioning.
So I need to look at logs when its in a broken state I would think to
figure this out, but which logs?
Also Not sure if some of the lines in my configs are right?
Would some one tell me if I’ve gone nuts as I’ve followed every guide I
can find 
so some of the files I’ve created may be superfluous
I’ve commented out sections of config files and currently booted with
the nouveau
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="vfio_pci.ids=10de:1b06,10de:10ef,1b21:1242
iommu=1 amd_iommu=on pcie_aspm=off
vfio_iommu_type1.allow_unsafe_interrupts=1"
#nouveau.modeset=0 modprobe.blacklist=nouveau"
So I’m booting the un-commented line and I’ve tried with combinations of
the # comments
sudo cat /etc/modules-load.d/modules.conf
#/etc/modules: kernel modules to load at boot time.
#This file contains the names of kernel modules that should be loaded
#at boot time, one per line. Lines beginning with “#” are ignored.
#blacklist nouveau
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
vfio_pci ids=1b21:1242,10de:1b06,10de:10ef
it87
i2c-viapro
#options nvidia-drm modeset=1
I tried it twice out of desperation… And here is where I’ve followed
every differing guide. I suspect that I only need to do this once…
cat /etc/modprobe.d/blacklist-nvidia-nouveau.conf
#blacklist nouveau
#options nouveau modeset=0
cat /etc/modprobe.d/blacklist-nouveau.conf
#blacklist nouveau
#options nouveau modeset=0
cat /etc/modprobe.d/nouveau-kms.conf
#options nouveau modeset=0
cat /etc/modprobe.d/nvidia.conf
softdep nvidia pre: vfio-pci
options nvidia-drm modeset=1
I use one GPU which is a 1080ti for VMs
cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1b06,10de:10ef,1b21:1242 disable_vga=1
cat /etc/modprobe.d/vfio_pci.conf
options vfio_pci ids=10de:1b06,10de:10ef,1b21:1242
I noticed this in dmesg on the last attempt in dmesg
181.353422] [drm:__nv_drm_connector_detect_internal [nvidia_drm]]
ERROR [nvidia-drm] [GPU ID 0x00000900] Failed to detect display state
Hope this is a little enough for this thread Thanks
Are you sure your Novideo Nvidia card is new enough to be supported by the latest drivers? Nvidia axed support for the GTX 600 and GTX 700 series recently with their 490 drivers IIRC.
2 Likes
Wait, the GTX 710 and 730 and such? Dang, I had hoped to grab one as a cheaper backup before GPU-ocalypse
Got RX580 and I5-12400F with B660 mobo.
I have set everything to enable “resizeable bar”.
Might be i need to do something in the os still.
Just wondering where to check that it’s on or working?
oh. might not work after all. RX5000 series was first amd gpu’s with pcie4…
So theoretically then apt should call apt-get when running upgrade option and still hold back these two packages? Even though apt prompts me to install them unlike apt-get upgrade
Correct. The upgrade should be non-system breaking as defined by APT. That does not mean it cannot happen (during branch transition if anything) but 99.999% of the time, the upgrade is harmless in regards to system health. If there are major configuration file changes by the upstream maintainer, apt obviously cannot do anything about that. Usually the current config would remain in place and the new config gets the suffix .new, but sometimes a major software upgrade will kill off deprecated options and choke on an old configuration file. This is very rare though and has only happened to me 3 times in the 20+ years that I have been using Debian.
Apt will prompt you to install new stuff. apt-get will not always prompt you and will just install items with their dependencies. apt-get does not generally hold your hand, apt will
**Edit
I run Debian Unstable as my main, everyday system and my upgrade process is as follows:
apt upgrade && apt dist-upgrade && apt --purge autoremoveThat is how much confidence I have in apt. I still review what it is doing and cancel out if I see any direct conflicts or breakage, but I would never do this with apt-get.
**Edit
I messed up the previous command, long day at work.
apt update && apt dist-upgrade && apt --purge autoremove
1 Like
Surely that should be apt update? If you’re not running apt update you are relying on some system job doing it.
(And apt full-upgrade is less confusing for new users of apt).
1 Like
I always looked at it as one would update (the list of available packages), before upgrade (currently installed packages), and also before dist-upgrade (newer distro version)
but presumably only one update should be required per session.
1 Like
Looking to set up a Linux imaging server.
Does anyone have recommendations? A guy on ASCII suggested the fog project.
Does anyone have any experience with fog or I think clonezilla might have one?
Any recommendations or first hand experience would be greatly appreciated.
1 Like
Depends on what you are trying to do. If you’re cloning dozens of PCs simultaneously, Clonezilla Server Edition is probably a better way to go, as it uses udpcast to clone an unlimited number of systems as fast a just two using conventional unicast methods.
If your needs are more modest, https://netboot.xyz/ might be quicker/easier. Clonezilla will save/restore images to any ssh server for example, so you may not need any extra services or setup to get started.
1 Like
BIOS updated and it’s been running eight and a half days without issue so far. That’s not definitive as it’s been known to run 30 days before a crash. But it regularly crashes after 5. So I’m pretty optimistic!
Thanks for the simple suggestion.
2 Likes
You are correct. It was a long day at work with little sleep.
I actually turn off the cron jobs that do this in the background. I found that everytime my system awakes from sleep or suspend, it runs the apt update command, which I think is just wasteful for power users.
You are right. I come from the days before apt, when we only had apt-get. dist-upgrade is not documented in the apt man pages but is documented in the apt-get man pages. old habits die hard.
1 Like
You are correct. I included a typo. How ever, in the Debian world (we do not have the Ubuntu do-upgrade), if you are using the major release named branches, then you would want to do an update, upgrade, and then a full-upgrade to ensure that you get the pieces in place correctly. Particularly if you are skipping a release version as sometimes the full-upgrade remove something critical but there is not upgrade candidate due to incompatibilities, like going from python 2.7 to python 3.x.
1 Like