Page 5 of 6
Re: Changing from SSD to nvme issues
Posted: Sat Mar 18, 2023 10:15 am
by j2mcgreg
Huckleberry Finn wrote:
With this one it's 40 posts and it'll be page 5 with the next post, still we don't have the QSI .
It would be best, I think, if you produced the QSI while the SSD is installed. However a QSI created from a Live session would also work in this situation.
Re: Changing from SSD to nvme issues
Posted: Sat Mar 18, 2023 8:12 pm
by tone2
Huckleberry Finn wrote: Sat Mar 18, 2023 9:19 am
With this one it's 40 posts and it'll be page 5 with the next post, still we don't have the QSI .
If there's an option in Bios like "Intel SpeedStep® Technology" , enable it, save, exit.
If no (or if still the same):
Code: Select all
echo RESUME=none | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
Reboot . (This will overwrite the previous one which was set to swap partition).
If still not: start the pc with systemd (select an entry with systemd on Grub Menu, if you can't see: look under "Advanced Options") and :
Code: Select all
systemd-analyze critical-chain ; systemd-analyze blame
I'm sorry, I've been almost exclusively talking on the forum on my phone, only on the PC for a couple minutes. Here is the QSI:
Code: Select all
Snapshot created on: 20230313_2129
System: Kernel: 5.10.0-15mx-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-15mx-amd64
root=UUID=<filter> ro
resume=UUID=<filter> resume_offset=5997854720 quiet
radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1
Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm 4.14.0 vt: 7
dm: LightDM 1.26.0 Distro: MX-19.4_x64 patito feo March 13 2023
base: Debian GNU/Linux 10 (buster)
Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: <filter>
Mobo: ASUSTeK model: TUF GAMING B550-PLUS (WI-FI) v: Rev X.0x serial: <filter>
UEFI: American Megatrends v: 2423 date: 08/10/2021
CPU: Info: 8-Core model: AMD Ryzen 7 5700G with Radeon Graphics bits: 64 type: MT MCP
arch: Zen 3 family: 19 (25) model-id: 50 (80) stepping: 0 microcode: A50000C cache:
L2: 4 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
bogomips: 121364
Speed: 2395 MHz min/max: 1400/5232 MHz boost: enabled Core speeds (MHz): 1: 2395
2: 2395 3: 2811 4: 2425 5: 2548 6: 3236 7: 2763 8: 3093 9: 2395 10: 2448 11: 2427
12: 2754 13: 2897 14: 3190 15: 2410 16: 2429
Vulnerabilities: Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl and seccomp
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2
mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: always-on, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics: Device-1: AMD Cezanne vendor: ASUSTeK driver: amdgpu v: kernel bus-ID: 07:00.0
chip-ID: 1002:1638 class-ID: 0300
Display: x11 server: X.Org 1.20.4 compositor: xfwm4 v: 4.14.0 driver:
loaded: amdgpu,ati unloaded: fbdev,modesetting,vesa display-ID: :0.0 screens: 1
Screen-1: 0 s-res: 3840x2160 s-dpi: 96 s-size: 1016x572mm (40.0x22.5")
s-diag: 1166mm (45.9")
Monitor-1: HDMI-A-0 res: 3840x2160 hz: 60 dpi: 139 size: 700x390mm (27.6x15.4")
diag: 801mm (31.5")
OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6 compat-v: 3.1
direct render: Yes
Audio: Device-1: AMD Renoir Radeon High Definition Audio vendor: ASUSTeK
driver: snd_hda_intel v: kernel bus-ID: 07:00.1 chip-ID: 1002:1637 class-ID: 0403
Device-2: AMD Family 17h/19h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel
bus-ID: 07:00.6 chip-ID: 1022:15e3 class-ID: 0403
Sound Server-1: ALSA v: k5.10.0-15mx-amd64 running: yes
Sound Server-2: PulseAudio v: 12.2 running: yes
Network: Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel modules: wl bus-ID: 04:00.0
chip-ID: 8086:2723 class-ID: 0280
IF: wlan0 state: down mac: <filter>
Device-2: Realtek RTL8125 2.5GbE vendor: ASUSTeK driver: r8169 v: kernel port: f000
bus-ID: 05:00.0 chip-ID: 10ec:8125 class-ID: 0200
IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives: Local Storage: total: 476.94 GiB used: 18.2 GiB (3.8%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 970 PRO 512GB
size: 476.94 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4
type: SSD serial: <filter> rev: 1B2QEXP7 temp: 23.9 C scheme: GPT
Partition: ID-1: / raw-size: 468.68 GiB size: 460.25 GiB (98.20%) used: 18.2 GiB (4.0%) fs: ext4
dev: /dev/nvme0n1p2 maj-min: 259:2
ID-2: /boot/efi raw-size: 256 MiB size: 252 MiB (98.46%) used: 274 KiB (0.1%)
fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
Swap: Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: partition size: 8 GiB used: 0 KiB (0.0%) priority: -2
dev: /dev/nvme0n1p3 maj-min: 259:3
Sensors: Message: No sensor data found. Is lm-sensors configured?
Repos: Packages: note: see --pkg apt: 2852 lib: 1608 flatpak: 0
Active apt repos in: /etc/apt/sources.list
1: deb [trusted=yes] file:/home/Rob/debArchives/archives/ ./
Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
1: deb http://deb.debian.org/debian buster-updates main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/debian.list
1: deb http://deb.debian.org/debian buster main contrib non-free
2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
3: deb http://deb.debian.org/debian buster-backports main contrib non-free
4: deb-src http://deb.debian.org/debian buster-backports main
5: deb [trusted=yes] file:/home/Rob/debArchives/archives/ ./
Active apt repos in: /etc/apt/sources.list.d/mx.list
1: deb http://mx.debian.nz/mx/repo/ buster main non-free
Active apt repos in: /etc/apt/sources.list.d/mysources.list
1: deb [trusted=yes] file:/home/Rob/debArchives/archives/ ./
Active apt repos in: /etc/apt/sources.list.d/scootersoftware.list
1: deb https://www.scootersoftware.com/ bcompare4 non-free
No active apt repos in: /etc/apt/sources.list.d/various.list
Info: Processes: 371 Uptime: 4m wakeups: 1 Memory: 14.99 GiB used: 2.27 GiB (15.1%)
Init: SysVinit v: 2.93 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: 8.3.0
alt: 10/8 Shell: quick-system-in default: Bash v: 5.0.3 running-in: quick-system-in
inxi: 3.3.06
I just ran the code:
Code: Select all
echo RESUME=none | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
I'll reboot, then try starting with systemd if that doesn't work.
Thanks!
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 7:29 am
by tone2
Huckleberry Finn wrote: Sat Mar 18, 2023 9:19 am
If still not: start the pc with systemd (select an entry with systemd on Grub Menu, if you can't see: look under "Advanced Options") and :
Code: Select all
systemd-analyze critical-chain ; systemd-analyze blame
I tried again and the systemd technique did yield an output:
Code: Select all
$ systemd-analyze critical-chain ; systemd-analyze blame
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @7.975s
└─multi-user.target @7.974s
└─hddtemp.service @7.963s +10ms
└─network-online.target @7.961s
└─NetworkManager-wait-online.service @1.720s +6.239s
└─NetworkManager.service @1.702s +17ms
└─network-pre.target @1.701s
└─netfilter-persistent.service @1.645s +55ms
└─local-fs.target @1.643s
└─run-user-1000-gvfs.mount @3.467s
└─local-fs-pre.target @218ms
└─lvm2-monitor.service @159ms +57ms
└─dm-event.socket @159ms
└─-.mount @150ms
└─systemd-journald.socket @151ms
└─-.mount @150ms
└─...
31.413s apt-daily.service
6.239s NetworkManager-wait-online.service
1.404s vboxdrv.service
1.290s systemd-udev-settle.service
1.054s nfs-server.service
789ms systemd-modules-load.service
291ms dev-nvme0n1p2.device
196ms cpufrequtils.service
145ms systemd-logind.service
123ms zfs-load-module.service
122ms dev-disk-by\x2duuid-fe797927\x2dc0e9\x2d400d\x2d905e\x2dbe7fb41ae116.swap
80ms upower.service
69ms tlp.service
58ms systemd-udev-trigger.service
57ms lvm2-monitor.service
57ms user@1000.service
55ms netfilter-persistent.service
55ms loadcpufreq.service
53ms udisks2.service
51ms ModemManager.service
48ms lightdm.service
42ms systemd-journald.service
41ms boot-efi.mount
40ms proc-fs-nfsd.mount
26ms accounts-daemon.service
26ms rpcbind.service
25ms resolvconf.service
So, is apt-daily.service the culprit after-all?
Thanks!
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 8:12 am
by razor2021
IMO, you seem to be taking a much longer route to run MX correctly especially on NVME.
Personally, I also use NVME as its faster, and I had my older MX OS on a slower HDD. I took out all the HDD with OSes on them, and only had the NVME on the motherboard. I installed MX21.x cleanly, and made sure all was well. Then I installed the other older HDDs back in, and re-ran grub to update the OSes so I could boot. Then I copied the info from older volumes to newer NVME volume. Then reformated the older HDD when not needed.
I am also on Asus motherboard with AMD CPU. However, I am running all the latest BIOSes. I see you have not updated the BIOS on your ASUS motherboard at all. You should consider this after getting all the MX issues sorted on NVME storage. Also run the latest kernel for better performance. I'm using kernel 6.1.0-6 from MX. So far, its great. All the previous kernels were stable as well.
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 9:00 am
by j2mcgreg
I'd add that with that hardware, you should be using the AHS version of MX. I suspect that the problem, all along, has been that the driver being used for your NVMe is inadequate for the hardware it is now tasked with. Two days ago I suggested that you try to install MX 21 on your NVMe and you dodged the issue. No more dodging. While the SSD is still in place, you need to backup your data and you need to download the latest version of MX 21 and write it to a USB drive. Once that's done, remove the SSD for safe keeping and replace it with the NVMe --> install MX 21.
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 9:07 am
by Huckleberry Finn
- Here's one of the reasons why we insist on QSI:
Did you use this consciously? (Do you have a swap file?)
(... If no (I guess so) remove it in "MX Boot Options", Apply. You can re-apply the one in post #25)
When booted with systemd:
Code: Select all
sudo systemctl edit apt-daily.timer
Code: Select all
[Timer]
OnBootSec=10min
OnUnitActiveSec=1d
AccuracySec=1h
RandomizedDelaySec=15min
- Also in a terminal:
Code: Select all
sudo systemctl disable NetworkManager-wait-online.service
Reboot with systemd.
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 10:03 am
by Eadwine Rose
What they said, and because it is in the forum rules that you share your QSI in help requests.
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 11:20 am
by Huckleberry Finn
Though this is not the reason for this issue (just btw) I also wonder if these are consciously, too:
radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1
(Doesn't seem to be an "Islands" card ...)
Still shows: OpenGL: renderer: llvmpipe though the drivers were loaded.
Re: Changing from SSD to nvme issues
Posted: Sun Mar 19, 2023 5:55 pm
by tone2
j2mcgreg wrote: Sun Mar 19, 2023 9:00 am
I'd add that with that hardware, you should be using the AHS version of MX. I suspect that the problem, all along, has been that the driver being used for your NVMe is inadequate for the hardware it is now tasked with. Two days ago I suggested that you try to install MX 21 on your NVMe and you dodged the issue. No more dodging. While the SSD is still in place, you need to backup your data and you need to download the latest version of MX 21 and write it to a USB drive. Once that's done, remove the SSD for safe keeping and replace it with the NVMe --> install MX 21.
Lol, yeah I actually did try to dodge that. My reason being, I really don't want to upgrade to Debian 11 [yet] because I have a single OS over a few PCs and all my programmes work, some of which aren't available on debian 11.....I hate upgrading for a couple reasons.
I did consider installing my USB on a laptop with a SATA M.2 drive, to see if the issue occured there. But I haven't had time.
Huckleberry Finn wrote: Sun Mar 19, 2023 9:07 am
- Here's one of the reasons why we insist on QSI:
Did you use this consciously? (Do you have a swap file?)
(... If no (I guess so) remove it in "MX Boot Options", Apply. You can re-apply the one in post #25)
When booted with systemd:
Code: Select all
sudo systemctl edit apt-daily.timer
Code: Select all
[Timer]
OnBootSec=10min
OnUnitActiveSec=1d
AccuracySec=1h
RandomizedDelaySec=15min
- Also in a terminal:
Code: Select all
sudo systemctl disable NetworkManager-wait-online.service
Reboot with systemd.
I have previously created a swap file, to try to get the system to resume from, because it didn't work by default. From memory it was a bit unreliable, so I didn't use it. For a bit of context, I have two OS', one is like a trial one where I experiment, and the one we've been talking about is what I consider my clean version, which I only install things I know I want and important files. I've been honing this OS for a couple years.
I don't remember playing with swap files that well. Regarding
I did notice this, and I actually set it to zero. But it didn't hav eany effect, so I assume it's like address of memory, rather than a time. In answer to your question, no it's not a conscious choice, maybe it was at one point when I was creating the swap. When I get home this evening I'll remove it and follow the post you linked and edit the apt-daily timer.
Huckleberry Finn wrote: Sun Mar 19, 2023 11:20 am
Though this is not the reason for this issue (just btw) I also wonder if these are consciously, too:
radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1
(Doesn't seem to be an "Islands" card ...)
Still shows: OpenGL: renderer:
llvmpipe though the drivers were loaded.
This is also not conciously set, it might have been because I was trying to get the AMD APU drivers all working because I was running Wine and having issues with graphics.
razor2021 wrote: Sun Mar 19, 2023 8:12 am
IMO, you seem to be taking a much longer route to run MX correctly especially on NVME.
Personally, I also use NVME as its faster, and I had my older MX OS on a slower HDD. I took out all the HDD with OSes on them, and only had the NVME on the motherboard. I installed MX21.x cleanly, and made sure all was well. Then I installed the other older HDDs back in, and re-ran grub to update the OSes so I could boot. Then I copied the info from older volumes to newer NVME volume. Then reformated the older HDD when not needed.
I am also on Asus motherboard with AMD CPU. However, I am running all the latest BIOSes. I see you have not updated the BIOS on your ASUS motherboard at all. You should consider this after getting all the MX issues sorted on NVME storage. Also run the latest kernel for better performance. I'm using kernel 6.1.0-6 from MX. So far, its great. All the previous kernels were stable as well.
When you say re-ran grub, is that
Code: Select all
grub-mkconfig -o /boot/grub/grub.cfg
? I remember reading that, and/or running a similar command. But I also recall when I went into the /etc/grub/.... file it said that MX was looking at somewhere else (I can't check ATM).
Okay, I'll update my bios if you think it's worthwhile. Cheers.
Thank you everyone
Re: Changing from SSD to nvme issues
Posted: Mon Mar 20, 2023 4:42 am
by razor2021
@tone2 When I meant re-run grub command, I meant the update command
sudo update-grub
It should look for all the possible OSes on different disk volumes it can read to add to the grub menu e.g. Windows or older MX OSes etc.