Changing from SSD to nvme issues [Solved]

[tone2]

• Here's one of the reasons why we insist on QSI:
  
  Did you use this consciously? (Do you have a swap file?)
  

  Code: Select all

  resume_offset=5997854720

  (... 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

  paste this:
  

  Code: Select all

  [Timer]
  OnBootSec=10min
  OnUnitActiveSec=1d
  AccuracySec=1h
  RandomizedDelaySec=15min

  Will change it to run at a random time between minutes 10 - 25 after boot (also once a "day" only), rather than when booting (and every boot). (... After pasting, Ctrl X to exit and hit Enter to save.)

• 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

[Huckleberry Finn]

... 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).

... 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
...

[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).

[tone2]

... 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).

... 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?

[Huckleberry Finn]

... 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: