Khắc phục độ trễ đăng nhập 2–3 phút trên Ubuntu với NVIDIA (lỗi Xorg + nvidia-drm)

Tôi gõ mật khẩu, nhấn enter, và rồi... không có gì. À, không hẳn là không có gì. Màn hình vẫn đen. Con trỏ chuột ở đó, như đang chế nhạo tôi. Hai phút trôi qua. Rồi ba phút. Cuối cùng, màn hình desktop của tôi hiện ra như chưa từng có chuyện gì xảy ra.

Chuyện này kéo dài hàng tuần. Tôi cứ tự nhủ sẽ sửa sau. Cái "sau" đó đến khi tôi không thể chịu đựng được nữa.

Nếu bạn đang dùng card NVIDIA chạy Xorg trên Ubuntu và việc đăng nhập của bạn cứ như đang chờ kết nối dial-up năm 2003, thì bài viết này là dành cho bạn.

Đuổi Theo Sai Vấn Đề

Giống như hầu hết mọi người, tôi bắt đầu từ nơi tôi vẫn thường làm. Systemd.

Tôi chạy systemd-analyze để kiểm tra thời gian khởi động. Mọi thứ có vẻ bình thường. Sau đó tôi thử systemd-analyze --user blame để xem có dịch vụ người dùng nào bị treo không. Không có gì nổi bật. Tôi đã tắt một vài thứ không cần thiết, hy vọng nó sẽ giúp ích.

Nó không giúp.

Tôi kiểm tra các ứng dụng khởi động của mình. Không. Tôi xem xét các tiện ích mở rộng của GNOME. Vẫn không. Tôi chắc chắn đây là một dịch vụ chậm hoặc một ứng dụng hoạt động sai.

Hóa ra tôi đã hoàn toàn sai.

Điều Gì Đã Thực Sự Xảy Ra

Đây là vấn đề với NVIDIA trên Linux. Nó hoạt động, hầu hết là vậy. Nhưng thỉnh thoảng, nó lại làm điều gì đó kỳ lạ khiến bạn phải đặt câu hỏi về những lựa chọn trong cuộc đời mình.

Vấn đề là một xung đột quyền sở hữu chế độ DRM. Nghe có vẻ kỹ thuật, nhưng ý tưởng thì đơn giản.

Tại sao điều này lại xảy ra? Bạn đoán cũng đúng như tôi. Một số phiên bản kernel xử lý việc chuyển giao chế độ khác nhau. Một bản cập nhật hệ thống có lẽ đã thay đổi điều gì đó. Tất cả những gì tôi biết là nvidia-drm và Xorg cuối cùng đã tranh giành cùng một tài nguyên, và không ai muốn nhượng bộ.

Cách Khắc Phục (Tiết lộ: Chỉ Một Dòng)

Sau tất cả những lần gỡ lỗi đó, giải pháp gần như đơn giản đến nực cười.

sudo nano /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=0"

sudo update-grub
sudo reboot

Chỉ vậy thôi. Một tham số kernel duy nhất. nvidia-drm.modeset=0.

Sau khi khởi động lại, tôi đăng nhập, nín thở, và... màn hình desktop của tôi hiện ra ngay lập tức. Như thể nó phải như vậy ngay từ đầu. Tôi thực sự ngồi đó một giây, bối rối vì không phải chờ đợi.

Nhưng Khoan Đã, Có Nhược Điểm Nào Không?

Câu hỏi hay. Vô hiệu hóa chế độ DRM có nghĩa là bạn đang từ bỏ một số chức năng.

Nếu bạn đang sử dụng Wayland thay vì Xorg, cách khắc phục này sẽ làm hỏng mọi thứ. Wayland cần chế độ DRM để hoạt động đúng cách. Tương tự nếu bạn dựa vào PRIME Sync hoặc các tính năng firmware GSP.

Nhưng nếu bạn giống tôi, chạy Xorg thuần túy trên máy tính để bàn với một màn hình, bạn sẽ không nhận thấy điều gì cả. Mọi thứ hiển thị giống nhau. Trò chơi vẫn hoạt động. Phát video vẫn ổn. Sự khác biệt duy nhất là máy tính của bạn thực sự phản hồi khi bạn đăng nhập.

Những Gì Tôi Đã Học Được

Tôi đã dành hàng giờ để tìm kiếm các vấn đề hiệu suất không tồn tại. Nhật ký Systemd, tinh chỉnh GNOME, tham số kernel, bạn cứ kể tên. Suốt thời gian đó, câu trả lời đang ẩn trong đầu ra dmesg mà tôi cứ bỏ qua.

Lần tới khi có điều gì đó kỳ lạ xảy ra với hệ thống của tôi, dmesg sẽ là nơi đầu tiên tôi kiểm tra, chứ không phải cuối cùng. Kernel thường biết chính xác điều gì sai. Bạn chỉ cần hỏi.

Và thành thật mà nói? Đôi khi những cách sửa lỗi ngớ ngẩn nhất lại là những cách đúng đắn. Một tham số khởi động duy nhất chỉ mất mười giây để gõ đã giúp tôi tiết kiệm 2-3 phút chờ đợi mỗi ngày. Hãy tính toán điều đó trong vài tháng và đó là hàng trăm phút tôi không phải nhìn chằm chằm vào màn hình đen.

Màn hình desktop của tôi hiện ra khi tôi đăng nhập bây giờ. Không ồn ào. Không chờ đợi. Đúng như nó phải thế.

Bạn cũng có thể thích

• Cách thêm thư mục vào PATH trong Linux (Khắc phục vĩnh viễn)
• FastAPI Docker Multistage Builds: Giảm 70% kích thước ảnh
• Astral uv trong Docker: Build đa giai đoạn, BuildKit Caching & CI nhanh
• Tối ưu hóa Docker BuildKit với Cache Mount & Multi-Stage (Hướng dẫn 2026)

Kiểm tra kiến thức