Page 1 of 1
Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 6:52 am
by tone2
Hi,
so I finally got an NVMe drive to boot from, expecting to see a really fast boot, but there have been some issues...
I'm using amd 5700g with Asus b550 tuf.
I made an image of my old MX 19.4 system, then wrote it to USB using the MX tool, then installed it on the nvme drive. I had issues with the default option of ESP, it would display an mdadm message and go Gray when id press enter. So I installed again as MBR. I don't know what PBR or ESP are, but MBR seems familiar and worked.
The 'mdadm no array found in config file...' messaged persisted and I tried half a dozen things before realising it was for RAID, so I just purged mdadm. However, the first line during boot 'Searching for physical devices. This may take some time'
still hangs on the screen for the same amount of time as the mdadm messages, if not longer!
So my questions are:
What's the right way to install the OS, MBR okay? What are the other methods?
How can I speed up my boot time, so it's not hanging looking for devices or drives if the system hasn't changed since it was powered down? I would love to see the nvme optimum boot time.
Thanks,
Rob
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 8:33 am
by Huckleberry Finn
In all cases change sata mode to Ahci (in Bios settings).
If it's set to Uefi mode, ESP (Efi System Partition) will be used, if set to Legacy (or a classic non-uefi Bios) then MBR.
And, as always:
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 10:02 am
by siamhie
Did you create a boot partition on the new drive? Here you can see I created a boot partition formatted to FAT32 with the boot and esp flags enabled.
boot.jpg
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 11:30 am
by j2mcgreg
Let's also rule out some possible incompatibilities:
-- your motherboard will only accept M.2 Socket 3 with M Key NVMEs. is this the type you bought?
-- Did you configure MX Live USB Maker to use a specific type of partitioning when it wrote the ISO to the USB drive? The installer defaults to PBT as the
Grub location when the USB install drive is set up to use the opposite partition type of what the bios is set for.
-- did you run a checksum to verify the integrity of the MX ISO before you wrote it to the USB drive?
-- do you have another USB drive that you can write the ISO to?
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 3:55 pm
by tone2
Hi all,
@Huckleberry Finn, @saimhie @j2mcgreg
Thanks for the replies.
When I get home I'll change to AHCI in the BIOS.
I can reinstall it, is there a preference for if it should be ESP and UEFI.
Yeah the drive is 970 pro nvme, the motherboard is compatible.
I didn't set up a boot petition, just full format the full drive.
The Live USB maker wrote it as MBR, the default was ESP, but something was wrong when I tried that. What is the difference between PBT?
I didn't do a checksum and I don't have a spare USB, but it's pretty unused.
Thanks
P.S @Huckleberry Finn what's the quick system info thing in your signature about?
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 4:32 pm
by j2mcgreg
From here:
https://www.intel.com/content/dam/suppo ... -Guide.pdf
NVME drives require UEFI so you must rewrite your snapshot to your USB drive and this time configure MX Live USB maker to use GPT partitioning. I also suggest that when you install MX 21, you select the "Automatic install using entire disc" option.
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 4:57 pm
by tone2
j2mcgreg wrote: Tue Mar 14, 2023 4:32 pm
From here:
https://www.intel.com/content/dam/suppo ... -Guide.pdf
NVME drives require UEFI so you must rewrite your snapshot to your USB drive and this time configure MX Live USB maker to use GPT partitioning. I also suggest that when you install MX 21, you select the "Automatic install using entire disc" option.
Thanks for the quick reply. Okay, I'm happy to rewrite the image to the USB, but to be clear, it does boot from the NVMe, it's just slower than I'd like. So why would USB partition style (gpt) matter? Unless you mean install From the USB again?
And should I choose MBR, PBR or ESP when I install on the drive?
P.S. from what I read online I can't see the difference between PBr and MBR, so I assume ESP.
Cheers
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 5:36 pm
by Huckleberry Finn
tone2 wrote: Tue Mar 14, 2023 3:55 pmP.S @Huckleberry Finn what's the quick system info thing in your signature about?..
If you were a very new forum member / MX user I wouldn't get surprised. But:
Posts: 118
Joined: Tue Jul 07, 2020
Can you just press q when you open the menu? (aka "Start Menu" in Windows terminology).
https://www.youtube.com/watch?v=C3bewGrU2eg
https://forum.mxlinux.org/viewtopic.php?f=32&t=29041
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 6:51 pm
by j2mcgreg
@tone2 wrote:
Thanks for the quick reply. Okay, I'm happy to rewrite the image to the USB, but to be clear, it does boot from the NVMe, it's just slower than I'd like. So why would USB partition style (gpt) matter? Unless you mean install From the USB again?
And should I choose MBR, PBR or ESP when I install on the drive?
P.S. from what I read online I can't see the difference between PBr and MBR, so I assume ESP.
Because if the system defaults to looking for a UEFI partition at each read and then has to pause while it locates the next data block in an MBR partition, all those pauses will add up and create the delay that you are experiencing.
Yes, I do mean that you should reinstall and by selecting to use GPT when you write the snapshot to the drive, the ESP partition will be automatically selected as the location for Grub (and you won't have to make the choice).
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 9:59 pm
by MXRobo
j2mcgreg wrote: Tue Mar 14, 2023 6:51 pm by selecting to use GPT when you write the snapshot to the drive, the ESP partition will be automatically selected as the location for Grub (and you won't have to make the choice).
I didn't, and good to know; I've posted here some time ago regarding if, which, and when to select the ESP partition when installing in GPT/EFI mode. [I thought that I might be installing it incorrectly because it kept crashing only to find out that I needed an AHS kernel.] I have seen recommendations to configure MX Live USB maker to use GPT partitioning, but didn't know why. Thanks
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 10:43 pm
by tone2
Wow, 3 years goes fast....I don't even think this is my first account either (hence the "2" in my username)
The frequency of those 118 posts was all clustered about 2years ago.
Right, I'm on a phone at the moment, but next time I'm on the desktop I will.
Taa
Re: Changing from SSD to nvme issues
Posted: Tue Mar 14, 2023 11:08 pm
by tone2
j2mcgreg wrote: Tue Mar 14, 2023 6:51 pm
@tone2 wrote:
Thanks for the quick reply. Okay, I'm happy to rewrite the image to the USB, but to be clear, it does boot from the NVMe, it's just slower than I'd like. So why would USB partition style (gpt) matter? Unless you mean install From the USB again?
And should I choose MBR, PBR or ESP when I install on the drive?
P.S. from what I read online I can't see the difference between PBr and MBR, so I assume ESP.
Because if the system defaults to looking for a UEFI partition at each read and then has to pause while it locates the next data block in an MBR partition, all those pauses will add up and create the delay that you are experiencing.
Yes, I do mean that you should reinstall and by selecting to use GPT when you write the snapshot to the drive, the ESP partition will be automatically selected as the location for Grub (and you won't have to make the choice).
Thanks for the explanation, but just to clarify, the drive you're talking about writing image to is the USB drive in the Live USB maker? For the step of specifying GPT. Not writing from USB to NVMe, which is later.
Or, is GPT the same thing as ESP?
Thanks again!
Re: Changing from SSD to nvme issues
Posted: Wed Mar 15, 2023 7:41 am
by j2mcgreg
@tone2 wrote:
Thanks for the explanation, but just to clarify, the drive you're talking about writing image to is the USB drive in the Live USB maker? For the step of specifying GPT. Not writing from USB to NVMe, which is later.
Or, is GPT the same thing as ESP?
Yes. GPT is the partitioning scheme that Grub needs in order to work properly with UEFI --
The What; and ESP is the location on your NVME
where Grub will be copied --
The Where
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 4:40 am
by tone2
j2mcgreg wrote: Wed Mar 15, 2023 7:41 am
@tone2 wrote:
Thanks for the explanation, but just to clarify, the drive you're talking about writing image to is the USB drive in the Live USB maker? For the step of specifying GPT. Not writing from USB to NVMe, which is later.
Or, is GPT the same thing as ESP?
Yes. GPT is the partitioning scheme that Grub needs in order to work properly with UEFI --
The What; and ESP is the location on your NVME
where Grub will be copied --
The Where
I'm sorry mcgreg, I just repeated from snapshot, MX Live USB maker, through installation to ESP, and no where did I see the option for GPT. Even with the bios set to UEFI the delay searching for physical volumes remains
Thanks again
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 7:47 am
by j2mcgreg
You have to configure Live USB Maker to use GPT and you do it this way:
1. Insert USB drive into machine
2. Launch Live USB Maker
3. Select the ISO you want to use
4. Click on Show advanced options and then under the Advanced Options title, select GPT partitioning
5. Make no further changes and click on Next in the bottom right of the window
6. Select Yes in the next box that pops up
7. Wait for the ISO to be written to the USB drive
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 9:35 am
by Huckleberry Finn
Just to make it clear:
tone2 wrote: Thu Mar 16, 2023 4:40 am... the delay searching for physical volumes remains
So, (if I understand correctly) you can see the desktop at the end, despite the long delay, right?
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 2:47 pm
by tone2
j2mcgreg wrote: Thu Mar 16, 2023 7:47 am
You have to configure Live USB Maker to use GPT and you do it this way:
1. Insert USB drive into machine
2. Launch Live USB Maker
3. Select the ISO you want to use
4. Click on Show advanced options and then under the Advanced Options title, select GPT partitioning
5. Make no further changes and click on Next in the bottom right of the window
6. Select Yes in the next box that pops up
7. Wait for the ISO to be written to the USB drive
Thanks.... I'll be embarrassed when I get home tonight, that I didn't see the advanced options, no doubt.
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 2:49 pm
by tone2
Huckleberry Finn wrote: Thu Mar 16, 2023 9:35 am
Just to make it clear:
tone2 wrote: Thu Mar 16, 2023 4:40 am... the delay searching for physical volumes remains
So, (if I understand correctly) you can see the desktop at the end, despite the long delay, right?
Yes....it might sound trivial, but I think it's worth getting optimal in the long run because it's for a few machines.
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 6:08 pm
by Huckleberry Finn
Then try this:
Code: Select all
idle=nomwait nvme_core.default_ps_max_latency_us=5500
If you can type manually (and correctly) press E on grub, type after ... ro quiet ... press F10 to go on boot (that will be temporary, just for that boot)
or just copy-paste with a space before it, into Kernel Parameters box in "MX Boot Options", Apply, reboot.
Re: Changing from SSD to nvme issues
Posted: Thu Mar 16, 2023 6:54 pm
by tone2
Huckleberry Finn wrote: Thu Mar 16, 2023 6:08 pm
Then try this:
Code: Select all
idle=nomwait nvme_core.default_ps_max_latency_us=5500
If you can type manually (and correctly) press E on grub, type after ... ro quiet ... press F10 to go on boot (that will be temporary, just for that boot)
or just copy-paste with a space before it, into Kernel Parameters box in "MX Boot Options", Apply, reboot.
I've never gotten into the grub menu like that on boot, from your description I assume it's similar to getting into the bios menu. So if I put it in kernel parameters it will persist for every boot?
What are the implications of setting the latency like that?
Thanks very much
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 5:45 am
by tone2
Huckleberry Finn wrote: Thu Mar 16, 2023 6:08 pm
Then try this:
Code: Select all
idle=nomwait nvme_core.default_ps_max_latency_us=5500
If you can type manually (and correctly) press E on grub, type after ... ro quiet ... press F10 to go on boot (that will be temporary, just for that boot)
or just copy-paste with a space before it, into Kernel Parameters box in "MX Boot Options", Apply, reboot.
Hi All,
I have an update. I reinstalled using the advanced options for GPT, and pasted in
Code: Select all
idle=nomwait nvme_core.default_ps_max_latency_us=5500
in the Kernel parameters.
However the message about 'Reading all physical volumes' still exists for a minute or so. I did notice that it now says:
"gave up waiting for resumed/suspended device"
Is this relevant? And are there any more ideas to resolve this?
Thanks again!
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 7:25 am
by j2mcgreg
Reboot and remove those kernel parameters. I think that HF meant those as a fix for your previous install. If you followed my instructions on creating your USB drive, you shouldn't need them this time round.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 8:46 am
by Huckleberry Finn
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 6:09 pm
by tone2
When I enter that I get a huge amount of like search results, it greps into vim docs and heaps of things.
So just the lsblk results:
Code: Select all
Rob@Rob:~
$ lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
nvme0n1
├─nvme0n1p1 vfat EFI System A042-FA4D 251.8M 0% /boot/efi
├─nvme0n1p2 ext4 rootMX19 eeb68368-40fb-4cc7-8dff-ea85235b59dd 418.7G 4% /
└─nvme0n1p3 swap swapMX fe797927-c0e9-400d-905e-be7fb41ae116 [SWAP]
Is that information about the swap of any importance?
@j2mcgreg Unfortunately, I did follow the instructions, and I think it took longer to write to the USB drive, than last time. However, the long boot time remains :-(
P.S. I removed that addition to the kernel parameters from MX boot options.
Thanks everyone.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 6:18 pm
by Huckleberry Finn
Code: Select all
echo RESUME=UUID=fe797927-c0e9-400d-905e-be7fb41ae116 | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
Reboot.
_________________________________________
Normally it should grep just this:
└─nvme0n1p3 swap swapMX fe797927-c0e9-400d-905e-be7fb41ae116 [SWAP]
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 6:46 pm
by tone2
Huckleberry Finn wrote: Fri Mar 17, 2023 6:18 pm
Code: Select all
echo RESUME=UUID=fe797927-c0e9-400d-905e-be7fb41ae116 | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
Reboot.
_________________________________________
Normally it should grep just this:
└─nvme0n1p3 swap swapMX fe797927-c0e9-400d-905e-be7fb41ae116 [SWAP]
Hi H. Finn, I ran the command, but on reboot I see it didn't update anything:
Code: Select all
Rob@Rob:~
$ lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
nvme0n1
├─nvme0n1p1 vfat EFI System A042-FA4D 251.8M 0% /boot/efi
├─nvme0n1p2 ext4 rootMX19 eeb68368-40fb-4cc7-8dff-ea85235b59dd 418.6G 4% /
└─nvme0n1p3 swap swapMX fe797927-c0e9-400d-905e-be7fb41ae116 [SWAP]
So what's the issue, tabs instead of spaces?
For what it's worth, here is the contents of the fstab file:
Code: Select all
# Pluggable devices are handled by uDev, they are not in fstab
UUID=eeb68368-40fb-4cc7-8dff-ea85235b59dd / ext4 noatime 1 1
UUID=fe797927-c0e9-400d-905e-be7fb41ae116 swap swap defaults 0 0
UUID=A042-FA4D /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0
Thanks very much
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 6:49 pm
by Huckleberry Finn
Just run the commands as a whole: click the SELECT ALL , then copy-paste press Enter.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 7:13 pm
by j2mcgreg
All this time you have been trying to install an image of your old system, right? I think that you need to eliminate it as the point of failure by trying to install the default XFCE version of MX 21. If this default version of MX 21 installs without a hitch, then you will know that the problem lies with your snapshot and if it encounters the same problem, I think that you should be looking at hardware failure You can prove hardware failure by installing your snapshot on the old SSD.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 7:58 pm
by tone2
Huckleberry Finn wrote: Fri Mar 17, 2023 6:49 pm
Just run the commands as a whole: click the SELECT ALL , then copy-paste press Enter.
That is exactly what I did....
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 8:07 pm
by tone2
j2mcgreg wrote: Fri Mar 17, 2023 7:13 pm
All this time you have been trying to install an image of your old system, right? I think that you need to eliminate it as the point of failure by trying to install the default XFCE version of MX 21. If this default version of MX 21 installs without a hitch, then you will know that the problem lies with your snapshot and if it encounters the same problem, I think that you should be looking at hardware failure You can prove hardware failure by installing your snapshot on the old SSD.
I still have the old SSD with the OS on it, because I was going to put it in another PC. I'll plug it in and compare, and get back to you.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 8:43 pm
by tone2
j2mcgreg wrote: Fri Mar 17, 2023 7:13 pm
All this time you have been trying to install an image of your old system, right? I think that you need to eliminate it as the point of failure by trying to install the default XFCE version of MX 21. If this default version of MX 21 installs without a hitch, then you will know that the problem lies with your snapshot and if it encounters the same problem, I think that you should be looking at hardware failure You can prove hardware failure by installing your snapshot on the old SSD.
Hi again, as a follow up, I'm on the old SSD now, it boots up much faster.
the log says:
Code: Select all
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Reading all physical volumes. This may take a while...
done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1
rootMX19: clean, 603283/31129600 files, 9377819/124494336 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
INIT: version 2.93 booting
[info] Using makefile-style concurrent boot in runlevel S.
[ ok ] Starting hotplug events dispatcher: systemd-udevd.
[ ok ] Synthesizing the initial hotplug events (subsystems)...done.
[ ok ] Synthesizing the initial hotplug events (devices)...done.
[ ok ] Waiting for /dev to be fully populated...done.
[ ok ] Setting up keyboard layout...done.
any thoughts?
Cheers
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 9:18 pm
by j2mcgreg
Two thoughts come to mind:
1) thoroughly check your bios if either the SSD or the NVME can be toggled off. Your long boot time could be accounted for if the bios was looking for, but not locating the SSD (which you had removed).
2) you NVME is faulty.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 9:37 pm
by tone2
j2mcgreg wrote: Fri Mar 17, 2023 9:18 pm
Two thoughts come to mind:
1) thoroughly check your bios if either the SSD or the NVME can be toggled off. Your long boot time could be accounted for if the bios was looking for, but not locating the SSD (which you had removed).
2) you NVME is faulty.
Thanks anyway, but the nvme is brand new, health is good.
I've tried everything in the BIOS. I'm confident it's a Linux issue. I don't have a good understanding of the Linux boot process.
Best regards,. Rob
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 9:59 pm
by j2mcgreg
tone2 wrote:
but the nvme is brand new
With NVMEs that is no guarantee of health. It could have a manufacturing or handling defect before you purchased or been damaged during shipping. As mass storage devices go, they are the least robust of the lot.
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 10:06 pm
by Buck Fankers
j2mcgreg wrote: Thu Mar 16, 2023 7:47 am
You have to configure Live USB Maker to use GPT and you do it this way:
4. Click on Show advanced options and then under the Advanced Options title, select GPT partitioning
Wau, I installed MX countless times, always using GPT/EFI and I had no clue about this option in Live USB Maker. I always set partition table and partitions manually with gparted. Cool, that MX tool can do this for you. Thank you for the info!
Re: Changing from SSD to nvme issues
Posted: Fri Mar 17, 2023 10:15 pm
by tone2
j2mcgreg wrote: Fri Mar 17, 2023 9:59 pm
tone2 wrote:
but the nvme is brand new
With NVMEs that is no guarantee of health. It could have a manufacturing or handling defect before you purchased or been damaged during shipping. As mass storage devices go, they are the least robust of the lot.
Especially now that they've stopped manufacturing MLC. So useless for cold storage over a couple years too.
Btw when I disabled SATA it wouldn't boot at all.
Re: Changing from SSD to nvme issues
Posted: Sat Mar 18, 2023 6:37 am
by tone2
Does anyone have any experience with efibootmgr?
I was wondering if this could help
Re: Changing from SSD to nvme issues
Posted: Sat Mar 18, 2023 7:05 am
by j2mcgreg
tone2 wrote:
Btw when I disabled SATA it wouldn't boot at all.
That's not what I said to do. What you want to do is prevent the bios from trying to boot from a non-existent or non-operational device. It can be as simple as adjusting the boot order so that the NVMe is given first priority and the SSD last priority. On some bioses you have to set all four boot device slots to the same device because if you don't, the bios will bypass your choice and use its own default hard coded boot order. Consider the scenario where you are trying to install MX on a new computer, but the target computer repeatedly ignores the USB drive and boots straight into Windows. It does this because you have left open options in the bios instead of forcing it to use your choice.
When you initially installed your NVMe, if you didn't prioritize it in the boot order and effectively delist the SSD and the other boot devices as well, the bios is going to try to boot from the SSD first and then all the other devices until it gets to the NVMe. This easily could account for your boot delay.
Re: Changing from SSD to nvme issues
Posted: Sat Mar 18, 2023 8:18 am
by tone2
j2mcgreg wrote: Sat Mar 18, 2023 7:05 am
tone2 wrote:
Btw when I disabled SATA it wouldn't boot at all.
That's not what I said to do. What you want to do is prevent the bios from trying to boot from a non-existent or non-operational device. It can be as simple as adjusting the boot order so that the NVMe is given first priority and the SSD last priority. On some bioses you have to set all four boot device slots to the same device because if you don't, the bios will bypass your choice and use its own default hard coded boot order. Consider the scenario where you are trying to install MX on a new computer, but the target computer repeatedly ignores the USB drive and boots straight into Windows. It does this because you have left open options in the bios instead of forcing it to use your choice.
When you initially installed your NVMe, if you didn't prioritize it in the boot order and effectively delist the SSD and the other boot devices as well, the bios is going to try to boot from the SSD first and then all the other devices until it gets to the NVMe. This easily could account for your boot delay.
I wish it were the case. Changing the boot order was the first thing I tried
Re: Changing from SSD to nvme issues
Posted: Sat Mar 18, 2023 9:19 am
by Huckleberry Finn
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
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.
Re: Changing from SSD to nvme issues
Posted: Mon Mar 20, 2023 5:06 am
by tone2
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.
Hey Finn,
Thanks again for your continued time/attention.
I re-ran
Code: Select all
echo RESUME=UUID=fe797927-c0e9-400d-905e-be7fb41ae116 | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
I think this is the alternative to MX Boot Options.
Then I booted with systemd and ran:
Code: Select all
sudo systemctl edit apt-daily.timer
pasted:
Code: Select all
[Timer]
OnBootSec=10min
OnUnitActiveSec=1d
AccuracySec=1h
RandomizedDelaySec=15min
Re-booted with systemd and there was no difference.
I am concerned, that if this worked, would I always have to boot with systemd?
Thanks,
Rob
P.S. In case it is of any interest, it still hung on 'reading physical volumes. this may take a while', however the output has changed:
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 @3.010s
└─multi-user.target @3.009s
└─vboxballoonctrl-service.service @3.005s +3ms
└─basic.target @1.547s
└─sockets.target @1.547s
└─avahi-daemon.socket @1.547s
└─sysinit.target @1.546s
└─systemd-update-utmp.service @1.540s +5ms
└─systemd-tmpfiles-setup.service @1.529s +7ms
└─local-fs.target @1.528s
└─zfs-mount.service @1.521s +6ms
└─zfs-import.target @1.520s
1.441s vboxdrv.service
1.180s systemd-udev-settle.service
1.048s nfs-server.service
307ms systemd-modules-load.service
268ms tlp.service
182ms systemd-logind.service
164ms cpufrequtils.service
117ms dev-nvme0n1p2.device
116ms zfs-load-module.service
81ms upower.service
62ms user@1000.service
61ms netfilter-persistent.service
61ms loadcpufreq.service
60ms systemd-udev-trigger.service
58ms udisks2.service
56ms systemd-journald.service
53ms lightdm.service
51ms lvm2-monitor.service
42ms ModemManager.service
32ms proc-fs-nfsd.mount
30ms accounts-daemon.service
30ms networking.service
29ms boot-efi.mount
26ms dev-disk-by\x2duuid-fe797927\x2dc0e9\x2d400d\x2d905e\x2dbe7fb41ae116.swap
21ms lm-sensors.service
21ms run-rpc_pipefs.mount
19ms NetworkManager.service
Re: Changing from SSD to nvme issues
Posted: Mon Mar 20, 2023 8:31 am
by Huckleberry Finn
tone2 wrote: Mon Mar 20, 2023 5:06 am... re-ran
Code: Select all
echo RESUME=UUID=fe797927-c0e9-400d-905e-be7fb41ae116 | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
I think this is the alternative to MX Boot Options...
Nope, that's the alternative (and the corrected) to
resume_offset=5997854720 which you should've removed in MX Boot Options (together with the other unnecessary/excessive parameters while you're at it).
tone2 wrote: Mon Mar 20, 2023 5:06 am... Re-booted with systemd and there was no difference.
I am concerned, that if this worked, would I always have to boot with systemd?..
No, we're using systemd just for it has such a feature to show what might be the culprit. Also we do that just to make both of them better (SysV and systemd booting) while we're at it. So, in all cases you need to get rid of that wrong parameter via MXBO. (Cause no matter what init system you boot with, it's looking for an inexisting swap file (that also has the wrong number even if it existed) ).
And, you might've noticed nothing but they both worked, you got rid of the 2:
Before and After:
graphical.target @
7.975s
graphical.target @
3.010s
Before:
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
...
After:
1.441s vboxdrv.service
1.180s systemd-udev-settle.service
1.048s nfs-server.service
...
Re: Changing from SSD to nvme issues
Posted: Mon Mar 20, 2023 8:45 am
by Huckleberry Finn
In fact, I would just boot with MX 21.3 AHS and install that (straightforward, with no unnecessary parameters), then copy required files/folders from the old one (old home).
Re: Changing from SSD to nvme issues
Posted: Tue Mar 21, 2023 5:51 am
by tone2
Huckleberry Finn wrote: Mon Mar 20, 2023 8:31 am
tone2 wrote: Mon Mar 20, 2023 5:06 am... re-ran
Code: Select all
echo RESUME=UUID=fe797927-c0e9-400d-905e-be7fb41ae116 | sudo tee /etc/initramfs-tools/conf.d/resume ; sudo update-initramfs -uk all
I think this is the alternative to MX Boot Options...
Nope, that's the alternative (and the corrected) to
resume_offset=5997854720 which you should've removed in MX Boot Options (together with the other unnecessary/excessive parameters while you're at it).
tone2 wrote: Mon Mar 20, 2023 5:06 am... Re-booted with systemd and there was no difference.
I am concerned, that if this worked, would I always have to boot with systemd?..
No, we're using systemd just for it has such a feature to show what might be the culprit. Also we do that just to make both of them better (SysV and systemd booting) while we're at it. So, in all cases you need to get rid of that wrong parameter via MXBO. (Cause no matter what init system you boot with, it's looking for an inexisting swap file (that also has the wrong number even if it existed) ).
And, you might've noticed nothing but they both worked, you got rid of the 2:
Before and After:
graphical.target @
7.975s
graphical.target @
3.010s
Before:
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
...
After:
1.441s vboxdrv.service
1.180s systemd-udev-settle.service
1.048s nfs-server.service
...
Holy crap, it is so fast now.
I deleted:
Code: Select all
quiet radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1
from MX Boot Options, and there is no longer a delay. The screen does flash up with a bunch of USB checks or something, but it's pretty quick. Did I need any of that rubbish which I deleted from the MX boot options? Any idea how it got in there? I don't remember typing it.
FYI:
Code: Select all
Rob@Rob:~
$ 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 @3.203s
└─multi-user.target @3.202s
└─vboxballoonctrl-service.service @3.199s +2ms
└─basic.target @1.712s
└─sockets.target @1.710s
└─avahi-daemon.socket @1.708s
└─sysinit.target @1.685s
└─sys-fs-fuse-connections.mount @3.607s +2ms
└─systemd-modules-load.service @202ms +263ms
└─systemd-journald.socket @192ms
└─-.mount @175ms
└─systemd-journald.socket @192ms
└─...
7.911s apt-daily.service
1.470s vboxdrv.service
1.194s systemd-udev-settle.service
1.057s nfs-server.service
770ms apt-daily-upgrade.service
483ms man-db.service
270ms tlp.service
268ms lvm2-monitor.service
263ms systemd-modules-load.service
210ms dev-nvme0n1p2.device
187ms cpufrequtils.service
159ms systemd-logind.service
153ms logrotate.service
120ms zfs-load-module.service
114ms netfilter-persistent.service
111ms ModemManager.service
97ms udisks2.service
80ms upower.service
75ms rpcbind.service
70ms loadcpufreq.service
70ms avahi-daemon.service
70ms systemd-journald.service
69ms proc-fs-nfsd.mount
68ms dev-hugepages.mount
65ms run-rpc_pipefs.mount
65ms wpa_supplicant.service
65ms kmod-static-nodes.service
Thanks so much!!!!!!!
P.S. I have an Odd update. My above questions still stand, however...
Curiosity got the better of me and I pasted it back in the MX boot option parameters piece-by-piece and it still booted up fast each time. Then finally I pasted the whole line back in and it was still pretty fast, maybe a touch slower than if blank. So I assume it wasn't the fact that I'd removed the line which did it, I assume it's that when I did so, grub updated in a way which it hadn't before, which resolved the issue? Should I still leave it empty anyway?
Re: Changing from SSD to nvme issues [Solved]
Posted: Tue Mar 21, 2023 8:26 am
by Huckleberry Finn
tone2 wrote: Tue Mar 21, 2023 5:51 am... with a bunch of USB checks or something, ...
Cause you deleted the
quiet , too.
Shortly: "Keep it simple".
Either just:
quiet splash
or
quiet nosplash (if you like/prefer the flowing text)
While we're at it, nothing to lose, (again when booted with sytemd):
Code: Select all
sudo systemctl stop apt-daily.service ; sudo systemctl disable apt-daily.service ; sudo systemctl mask apt-daily.service
Code: Select all
sudo systemctl disable apt-daily.timer ; sudo systemctl disable apt-daily-upgrade.timer ; sudo systemctl disable apt-daily-upgrade.service
Then (in general) go on booting with whichever you like: default (SysV) or systemd ...
Any time you feel it's ok, please mark the thread with 1 click like this:
