Suggestion: Dragonized Gaming Edition installer shouldn't fall asleep during install

Issues & Assistance KDE
1

Hello. I set up an install of Dragonized Gaming and left it to do it’s thing, and when I came back to look after 20 minutes or so, it had gone to sleep, and the installer doesn’t wake correctly on some laptops (on mine it wakes fine AFTER the install, but the installer doesn’t wake. I hoped it had finished the install before going to sleep, but it apparently hadn’t, because Garuda wouldn’t boot.

Being such a large system, maybe the default power settings of the installers should be adjusted to accommodate the extra time it takes to install. My computer is no slouch, btw, just a bit old. Thank you very much.

NOTE:
This is not a complaint. Just want to help make Garuda better.

╭─garuda@garuda in ~ as 🧙 took 21ms
[🔍] × garuda-inxi
System:
Kernel: 6.8.7-zen1-2-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-x86_64 lang=en_US keytable=us tz=UTC
misobasedir=garuda root=miso:LABEL=GARUDA_DR460NIZEDGAMING_BIRDOFPR quiet
systemd.show_status=1 checksum=y driver=nonfree nouveau.modeset=0
i915.modeset=1 radeon.modeset=1
Desktop: KDE Plasma v: 6.0.4 tk: Qt v: N/A info: frameworks v: 6.1.0
wm: kwin_x11 vt: 2 dm: SDDM Distro: Garuda base: Arch Linux
Machine:
Type: Laptop System: Dell product: Precision 7510 v: N/A
serial: <superuser required> Chassis: type: 9 serial: <superuser required>
Mobo: Dell model: N/A serial: <superuser required> part-nu: 06D9
uuid: <superuser required> UEFI: Dell v: 1.31.3 date: 03/09/2023
Battery:
ID-1: BAT0 charge: 73.5 Wh (100.0%) condition: 73.5/91.0 Wh (80.7%)
volts: 12.9 min: 11.4 model: Samsung SDI DELL TWCPG77 type: Li-ion
serial: <filter> status: full
CPU:
Info: model: Intel Core i7-6820HQ bits: 64 type: MT MCP arch: Skylake-S
gen: core 6 level: v3 note: check built: 2015 process: Intel 14nm family: 6
model-id: 0x5E (94) stepping: 3 microcode: 0xF0
Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB
L3: 8 MiB desc: 1x8 MiB
Speed (MHz): avg: 800 min/max: 800/3600 scaling: driver: intel_pstate
governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800
8: 800 bogomips: 43198
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities: <filter>
Graphics:
Device-1: Intel HD Graphics 530 vendor: Dell driver: i915 v: kernel
arch: Gen-9 process: Intel 14n built: 2015-16 ports: active: eDP-1
empty: DP-1, DP-2, DP-3, HDMI-A-1, HDMI-A-2, HDMI-A-3 bus-ID: 0000:00:02.0
chip-ID: 8086:191b class-ID: 0300
Device-2: NVIDIA GM107GLM [Quadro M2000M] vendor: Dell driver: nvidia
v: 550.76 alternate: nouveau,nvidia_drm non-free: 545.xx+ status: current
(as of 2024-04; EOL~2026-12-xx) arch: Maxwell code: GMxxx
process: TSMC 28nm built: 2014-2019 ports: active: none
empty: DP-4, DP-5, DP-6, VGA-1 bus-ID: 0000:01:00.0 chip-ID: 10de:13b0
class-ID: 0300
Device-3: Realtek Integrated_Webcam_HD driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-11:3 chip-ID: 0bda:5686
class-ID: 0e02 serial: <filter>
Display: x11 server: X.Org v: 21.1.13 with: Xwayland v: 23.2.6
compositor: kwin_x11 driver: X: loaded: modesetting,nvidia unloaded: nouveau
alternate: fbdev,intel,nv,vesa dri: iris gpu: i915 display-ID: :0
screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: eDP-1 model: AU Optronics 0x5799 built: 2021 res: 1920x1080
hz: 60 dpi: 142 gamma: 1.2 size: 344x194mm (13.54x7.64") diag: 395mm (15.5")
ratio: 16:9 modes: 1920x1080
API: EGL v: 1.5 hw: drv: intel iris drv: nvidia platforms: device: 0
drv: nvidia device: 1 drv: iris device: 3 drv: swrast surfaceless:
drv: nvidia x11: drv: iris inactive: gbm,wayland,device-2
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: intel mesa v: 24.0.5-arch1.1
glx-v: 1.4 direct-render: yes renderer: Mesa Intel HD Graphics 530 (SKL GT2)
device-ID: 8086:191b memory: 30.38 GiB unified: yes
API: Vulkan v: 1.3.279 layers: 10 device: 0 type: integrated-gpu
name: Intel HD Graphics 530 (SKL GT2) driver: mesa intel v: 24.0.5-arch1.1
device-ID: 8086:191b surfaces: xcb,xlib device: 1 type: discrete-gpu
name: Quadro M2000M driver: nvidia v: 550.76 device-ID: 10de:13b0
surfaces: xcb,xlib device: 2 type: cpu name: llvmpipe (LLVM 17.0.6 256
bits) driver: mesa llvmpipe v: 24.0.5-arch1.1 (LLVM 17.0.6)
device-ID: 10005:0000 surfaces: xcb,xlib
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: Dell
driver: snd_hda_intel v: kernel alternate: snd_soc_avs bus-ID: 0000:00:1f.3
chip-ID: 8086:a170 class-ID: 0403
Device-2: NVIDIA GM107 High Definition Audio [GeForce 940MX] vendor: Dell
driver: snd_hda_intel v: kernel bus-ID: 0000:01:00.1 chip-ID: 10de:0fbc
class-ID: 0403
API: ALSA v: k6.8.7-zen1-2-zen status: kernel-api with: aoss
type: oss-emulator tools: N/A
Server-1: PipeWire v: 1.0.5 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
Device-1: Intel Ethernet I219-LM vendor: Dell driver: e1000e v: kernel
port: N/A bus-ID: 0000:00:1f.6 chip-ID: 8086:15b7 class-ID: 0200
IF: enp0s31f6 state: down mac: <filter>
Device-2: Intel Wireless 8260 driver: iwlwifi v: kernel
bus-ID: 0000:02:00.0 chip-ID: 8086:24f3 class-ID: 0280
IF: wlp2s0 state: up mac: <filter>
Info: services: NetworkManager, systemd-timesyncd, wpa_supplicant
RAID:
Hardware-1: Intel SATA Controller [RAID mode] driver: intel_nvme_remap
v: N/A port: f060 bus-ID: 0000:00:17.0 chip-ID: 8086:2822 rev: N/A
class-ID: 0104
Drives:
Local Storage: total: 989.28 GiB used: 8.83 GiB (0.9%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Fanxiang model: S690Q 1TB
size: 931.51 GiB block-size: physical: 512 B logical: 512 B tech: SSD
serial: <filter> fw-rev: VF001C30 temp: 33.9 C scheme: GPT
ID-2: /dev/sda maj-min: 8:0 vendor: PNY model: USB 3.2.1 FD
size: 57.77 GiB block-size: physical: 512 B logical: 512 B type: USB
rev: 3.2 spd: 5 Gb/s lanes: 1 mode: 3.2 gen-1x1 tech: N/A serial: <filter>
fw-rev: PMAP scheme: GPT
SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
Message: No partition data found.
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 31.11 GiB used: 2.04 GiB (6.6%)
priority: 100 comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 8
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 57.0 C pch: 50.0 C mobo: 48.0 C
Fan Speeds (rpm): cpu: 2576 fan-2: 2581
Info:
Memory: total: 32 GiB available: 31.11 GiB used: 5.58 GiB (17.9%)
Processes: 322 Power: uptime: 30m states: freeze,mem,disk suspend: deep
avail: s2idle wakeups: 0 hibernate: platform avail: shutdown, reboot,
suspend, test_resume image: 12.41 GiB services: org_kde_powerdevil,
power-profiles-daemon, upowerd Init: systemd v: 255 default: graphical
tool: systemctl
Packages: pm: pacman pkgs: 1872 libs: 543 tools: octopi,paru Compilers:
clang: 17.0.6 gcc: 13.2.1 Shell: garuda-inxi default: fish v: 3.7.1
running-in: konsole inxi: 3.3.34
Garuda (2.6.26-1):
System install date:     2024-09-20
Last full system update: 2024-09-20 ↻
Is partially upgraded:   Yes
Relevant software:       snapper NetworkManager dracut nvidia-dkms
Windows dual boot:       <superuser required>
Failed units:            snapper-cleanup.service
2

Are all the laptops you experience this issue on Nvidia ones? By default the NVIDIA Linux drivers do not save and restore all video memory allocations on system suspend, causing some applications to crash after coming back from power management cycles. The normal fix for this is described here:

https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend

It involves setting up kernel module parameters and starting some Nvidia-specific suspend and resume systemd services. I’m not sure there is a great way to do this for the live environment; maybe a mhwd expert can take a look and see if this can be somehow incorporated for Nvidia systems in a way that won’t break non-Nvidia environments.

3 Likes
3

But, Sir, it’s the installer usb. We shouldn’t have to fix the installer usb before an install and, whether it wakes up or not, it shouldn’t go to sleep before the time it takes to install, in my opinion.

Once I was using the installer to move partitions and it went to sleep during the move of my home partition. It wouldn’t wake and I lost my home partition. I don’t think installer isos should be set to go to sleep at all, but I understand that that is a questionable opinion. That it should be set to stay awake during the time of an install when that’s it’s main job shouldn’t be very questionable, I don’t think.

4

Go into System Settings in the live:
Screen Locking set to Never.
Power Management: Suspend Session set to Do Nothing.

1 Like
5

My message was not intended to say “this is how you can fix it”, bit rather to explain why it may not be simple or even possible to fix.

I see your point, but I think there are legitimate reasons to keep it intact because the live environment is also useful for testing (not just running the installer).

I think it would be handy if Calamares had a way of disabling suspend while it runs, although I’m not sure if that is possible either. If you are willing to test, try masking the systemd targets.

systemctl mask suspend.target sleep.target hibernate.target

Maybe we could cook up some way to run this automatically if Nvidia hardware is detected, or incorporate it into a wrapper for Calamares or something.

5 Likes
6

Perhaps @dalto might be able to answer some of your questions about the Calamares installer as he is very knowledgeable about its inner workings.

2 Likes
7

Thank you guys. I thought it would be an easy impliment, but I also know that I don’t know.

It’s easy enough to deal with in the installer anyway, as long as I can remember. Lol.

8

Maybe if the user picks the nvidia boot driver, though this could only work on kde an maybe gnome. It uses a image where the timers are set to never or a 6-12 hour limit before it sleeps. I’m not sure if this is possible or not as it might have to be the default on Open an nvidia driver.

Or maybe the more simple would be to disable sleep full stop the systemd way and having a prompt inform the user they need to turn it on in Garuda Welcome.

Again I’m not sure on any of that.

9

I forgot about this thread. Reading through it again, I think I feel differently about it than I did in the past.

I think this is right–it would be better if suspend/sleep/hibernate was disabled in the live environment. The least experienced users in this environment will be just trying to run the installer, where suspend will be a hindrance or may cause issues as mentioned in the OP.

A relatively straightforward way to do this would be to symlink the suspend and sleep targets in /etc/systemd/system/ to /dev/null in the live overlay. If the symlinks are just in the live overlay, they will not persist in the installed system.

To briefly respond to my past self:

It is true that the live environment is also useful for testing, but these users are likely to be more experienced and can hopefully figure out what to do if the symlinks need to be removed.

I will bring it up in the team chat to see if there are any objections, and if not I’ll go ahead and set it up and do some testing.

3 Likes
10

I guess it depends on one’s hardware but Garuda ALWAYS installs in less time than the it’s set to go to a black screen for me. As someone said above I can see it for peeps doing testing from the live and not doing an actual install.