Điểm:0

Ubuntu 20.04 LTS NetworkManager.service không khởi động được

lá cờ za

tôi bắt đầu có vấn đề với NetworkManager.service và không có bất kỳ kết nối internet nào vài tháng trước. Tôi sẽ nhận được các cửa sổ bật lên lỗi Ubuntu cho dịch vụ này không khởi động được, nhưng khởi động lại máy tính sẽ giúp nó khởi động lại bình thường và nó không xảy ra quá thường xuyên. Sau đó, nó bắt đầu xảy ra thường xuyên hơn và việc khởi động lại ngừng hoạt động mỗi lần, dẫn đến nhiều nỗ lực để khởi động đúng cách. Tôi tìm thấy một người nói rằng lệnh Sudo systemctl khởi động lại NetworkManager.service sẽ bắt đầu lại và trong một thời gian, điều này đã thực hiện được mẹo (mặc dù tôi phải chạy nó hầu như mỗi khi tôi khởi động lại máy tính).

Tuy nhiên, mới hôm nay, lệnh này không còn hoạt động nữa, đã tạo ra lỗi và bây giờ tôi không thể kết nối với internet từ Ubuntu ngay cả sau khi một số máy tính khởi động lại và tắt máy:

~$ sudo systemctl khởi động lại NetworkManager.service
Công việc cho NetworkManager.service không thành công vì một tín hiệu gây tử vong đã được gửi khiến quá trình điều khiển kết xuất lõi.
Xem "trạng thái systemctl NetworkManager.service" và "journalctl -xe" để biết chi tiết.

Kiểm tra trạng thái systemctl của nó, tôi nhận được điều này:

~$ systemctl status NetworkManager.service
â NetworkManager.service - Trình quản lý mạng
     Đã tải: đã tải (/lib/systemd/system/NetworkManager.service; đã bật; giá trị đặt trước của nhà cung cấp: đã bật)
     Hoạt động: không thành công (Kết quả: core-dump) kể từ Chủ Nhật 2021-06-27 14:40:30 EDT; 2 phút 9 giây trước
       Tài liệu: man:NetworkManager(8)
    Quá trình: 3222 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=dumped, signal=BUS)
   PID chính: 3222 (mã = kết xuất, tín hiệu = BUS)

Ngày 27 tháng 6 14:40:30 người dùng systemd[1]: NetworkManager.service: Công việc khởi động lại theo lịch trình, bộ đếm khởi động lại ở mức 5.
Ngày 27 tháng 6 14:40:30 người dùng systemd[1]: Đã dừng Trình quản lý mạng.
Ngày 27 tháng 6 14:40:30 người dùng systemd[1]: NetworkManager.service: Bắt đầu yêu cầu lặp lại quá nhanh.
Ngày 27 tháng 6 14:40:30 user systemd[1]: NetworkManager.service: Không thành công với kết quả 'core-dump'.
Ngày 27 tháng 6 14:40:30 người dùng systemd[1]: Không thể khởi động Trình quản lý mạng.

Đối với tạp chí -xe đầu ra, tôi đã đặt tất cả nhật ký đã cung cấp cho tôi tại liên kết pastebin này: https://Pastebin.com/gTJMktN5 Có rất nhiều lỗi tương tự như trên nói rằng nó không thành công với kết xuất lõi, nhưng đây chỉ là một trong những khối có thể liên quan:

-- Một công việc bắt đầu cho đơn vị NetworkManager.service đã bắt đầu thực thi.
-- 
-- Định danh công việc là 1897.
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: ngoại lệ Emask 0x0 SAct 0x200000 SErr 0x0 hành động 0x0
Ngày 27 tháng 6 14:40:28 hạt nhân người dùng: ata4.00: irq_stat 0x40000008
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: lệnh không thành công: READ FPDMA QUEUED
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: cmd 60/08:a8:70:9a:41/00:00:5a:00:00/40 thẻ 21 ncq dma 4096 trong
                                      độ phân giải 41/40:00:74:9a:41/00:00:5a:00:00/00 Emask 0x409 (lỗi phương tiện) <F>
Ngày 27 tháng 6 14:40:28 kernel người dùng: ata4.00: status: { DRDY ERR }
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: error: { UNC }
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: được định cấu hình cho UDMA/133
Ngày 27 tháng 6 14:40:28 nhân người dùng: sd 3:0:0:0: [sdb] tag#21 FAILED Kết quả: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
Ngày 27 tháng 6 14:40:28 nhân người dùng: sd 3:0:0:0: [sdb] tag#21 Khóa Sense: Lỗi trung bình [hiện tại] 
Ngày 27 tháng 6 14:40:28 user kernel: sd 3:0:0:0: [sdb] tag#21 Add.Cảm giác: Lỗi đọc chưa được khôi phục - tự động phân bổ lại không thành công
Ngày 27 tháng 6 14:40:28 user kernel: sd 3:0:0:0: [sdb] tag#21 CDB: Read(10) 28 00 5a 41 9a 70 00 00 08 00
Ngày 27 tháng 6 14:40:28 nhân người dùng: blk_update_request: Lỗi I/O, dev sdb, sector 1514248820 op 0x0:(READ) flags 0x0 phys_seg 1 lớp trước 0
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4: EH hoàn tất
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: ngoại lệ Emask 0x0 SAct 0x4000000 SErr 0x0 hành động 0x0
Ngày 27 tháng 6 14:40:28 hạt nhân người dùng: ata4.00: irq_stat 0x40000008
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: lệnh không thành công: READ FPDMA QUEUED
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: cmd 60/08:d0:70:9a:41/00:00:5a:00:00/40 thẻ 26 ncq dma 4096 trong
                                      độ phân giải 41/40:00:74:9a:41/00:00:5a:00:00/00 Emask 0x409 (lỗi phương tiện) <F>
Ngày 27 tháng 6 14:40:28 kernel người dùng: ata4.00: status: { DRDY ERR }
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: error: { UNC }
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: được định cấu hình cho UDMA/133
Ngày 27 tháng 6 14:40:28 nhân người dùng: sd 3:0:0:0: [sdb] tag#26 FAILED Kết quả: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
Ngày 27 tháng 6 14:40:28 nhân người dùng: sd 3:0:0:0: [sdb] tag#26 Khóa Sense: Lỗi trung bình [hiện tại] 
Ngày 27 tháng 6 14:40:28 user kernel: sd 3:0:0:0: [sdb] tag#26 Add. Cảm giác: Lỗi đọc chưa được khôi phục - tự động phân bổ lại không thành công
Ngày 27 tháng 6 14:40:28 user kernel: sd 3:0:0:0: [sdb] tag#26 CDB: Read(10) 28 00 5a 41 9a 70 00 00 08 00
Ngày 27 tháng 6 14:40:28 nhân người dùng: blk_update_request: Lỗi I/O, dev sdb, sector 1514248820 op 0x0:(READ) flags 0x0 phys_seg 1 lớp trước 0
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4: EH hoàn tất
Ngày 27 tháng 6 14:40:28 người dùng systemd[1]: NetworkManager.service: Quá trình chính đã thoát, mã=kết xuất, trạng thái=7/BUS
-- Chủ đề: Quá trình đơn vị đã thoát
-- Xác định bởi: systemd
-- Hỗ trợ: http://www.ubuntu.com/support
-- 
-- Một quy trình ExecStart= thuộc đơn vị NetworkManager.service đã thoát.

Tôi đã thấy các bài đăng tương tự như thế này có câu trả lời nói rằng hãy cập nhật phiên bản kernel và những thứ khác, nhưng tôi hiện đang chạy phiên bản mới nhất trên phiên bản 20.04 LTS và tôi không nghĩ rằng mình sẽ phải thay đổi nhiều từ nó.

tôi đang chạy Ubuntu 20.04.2 LTS x86_64 với hạt nhân:

~$ uname -a
Người dùng Linux 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thứ năm, ngày 17 tháng 6 11:14:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Tôi cũng bắt đầu gặp lỗi thường xuyên bật lên đối với các dịch vụ chưa bao giờ bị lỗi trước đây trong khi tôi đang thu thập các nhật ký này. Chúng dành cho các dịch vụ sau:

/usr/libexec/colord
/usr/libexec/tracker-extract
/usr/libexec/tracker-miner-fs
/usr/lib/góikit/góikitd

Tôi không biết liệu chúng có liên quan hay không, nhưng xem xét chúng bắt đầu cùng lúc với lệnh khởi động lại mà tôi đang sử dụng đã ngừng hoạt động, có vẻ như có vấn đề lớn hơn. Trên hết, việc khởi động lại và tắt máy tính tạo ra các trang lỗi cuộn quá nhanh khiến tôi không thể đọc chúng trong trình tự tắt máy.

Bất kỳ trợ giúp nào đối với việc gỡ lỗi hoặc tìm giải pháp thay thế sẽ được đánh giá cao.

Chỉnh sửa:

Đây là đầu ra của grep -i FPDMA /var/log/syslog*: https://Pastebin.com/tazDug7H

Đây là đầu ra của dmesg. Có một vài lỗi I/O trong lỗi này. Đối với hồ sơ, ổ đĩa cài đặt là /dev/sdb: https://pastebin.com/ctefUjUA

đầu ra của fsck trên ổ đĩa cài đặt:

~$ sudo fsck -f /dev/sdb2
fsck từ util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Vượt qua 1: Kiểm tra nút, khối và kích thước
Pass 2: Kiểm tra cấu trúc thư mục
Pass 3: Kiểm tra kết nối thư mục
Vượt qua 4: Kiểm tra số lượng tham chiếu
Pass 5: Kiểm tra thông tin tóm tắt nhóm
/dev/sdb2: 635347/61022208 tệp (1,4% không liền kề), 29081215/244059648 khối

ảnh chụp màn hình kiểm tra SMART

Điểm:0
lá cờ ru

NCQ

Bạn đang gặp lỗi đĩa NCQ...

Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: lệnh không thành công: READ FPDMA QUEUED
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: cmd 60/08:a8:70:9a:41/00:00:5a:00:00/40 thẻ 21 ncq dma 4096 trong
                                      độ phân giải 41/40:00:74:9a:41/00:00:5a:00:00/00 Emask 0x409 (lỗi phương tiện) <F>
Ngày 27 tháng 6 14:40:28 kernel người dùng: ata4.00: status: { DRDY ERR }
Ngày 27 tháng 6 14:40:28 nhân người dùng: ata4.00: error: { UNC }

Hàng đợi lệnh gốc (NCQ) là một phần mở rộng của giao thức Serial ATA cho phép các ổ đĩa cứng tối ưu hóa bên trong thứ tự thực hiện các lệnh đọc và ghi nhận được.

Chỉnh sửa sudo -H gedit /etc/default/grub và thay đổi dòng sau để bao gồm tham số bổ sung này. sau đó làm cập nhật sudo-grub để ghi các thay đổi vào đĩa. Khởi động lại. Màn hình bị treo/v.v., và xem grep -i FPDMA /var/log/syslog* hoặc dmesg cho các thông báo lỗi tiếp tục.

GRUB_CMDLINE_LINUX_DEFAULT="giật gân libata.force=noncq"

fsck

  • khởi động vào Ubuntu Live DVD/USB ở chế độ Dùng thử Ubuntuâ
  • mở một phần cuối cửa sổ bằng cách nhấn Điều khiển+thay thế+t
  • loại Sudo fdisk -l
  • xác định tên thiết bị /dev/sdXX cho "Hệ thống tệp Linux" của bạn
  • loại Sudo fsck -f /dev/sdXX, thay thế sdXX với số bạn đã tìm thấy trước đó
  • lặp lại fsck lệnh nếu có lỗi
  • loại khởi động lại

SSD

Liên quan đến bạn SanDisk SSD PLUS 1TB, hãy kiểm tra bản cập nhật chương trình cơ sở. Truy cập trang web SanDisk và tải xuống bảng điều khiển phần mềm. Windows yêu cầu.

Nhìn thấy https://kb.sandisk.com/app/answers/detail/a_id/15108/~/dashboard-support-information

Cập nhật #1:

Mặc dù SMART nói rằng SSD vẫn ổn, nhưng không phải vậy. Bạn có 6146 lỗi không sửa được21388 lỗi ECC không sửa được! Vì bạn đã thay đổi cáp và cập nhật chương trình cơ sở, nên vấn đề là ở cổng SATA hoặc của bạn SSD là xấu.

Bobchuck avatar
lá cờ za
Cảm ơn bạn đã phản hồi. Tôi sẽ thử phần NCQ ngay bây giờ, nhưng khi bạn nói "KHÔNG chặn SSD xấu", bạn có nói là không chạy các lệnh sau trên SSD không? Trên thực tế, bản cài đặt Ubuntu của tôi nằm trên ổ SSD.
heynnema avatar
lá cờ ru
@Bobchuck Điều gì tạo ra/mô hình SSD? SAMSUNG?
Bobchuck avatar
lá cờ za
đó là SSD SamDisk PLUS 1TB. Ngoài ra, việc chỉnh sửa tệp grub đó và cập nhật grub dường như không thay đổi bất cứ điều gì - Trình quản lý mạng vẫn bị lỗi khi bắt đầu. Tôi sẽ thêm nhật ký từ `syslog` và `dmesg` vào câu hỏi của mình vì có thể có nhiều thứ hơn để xem ở đó ngay bây giờ. Mặc dù thú vị là tôi đã có thể khởi động dịch vụ bằng cách chạy `sudo systemctl start NetworkManager.service` (`restart` không làm gì cả) cả trước và sau khi chỉnh sửa tệp grub, nhưng có lẽ tôi đã gặp may.
heynnema avatar
lá cờ ru
@Bobchuck Sau khi chỉnh sửa tệp GRUB và `sudo update-grub`, bạn đã khởi động lại hệ thống chưa?
Bobchuck avatar
lá cờ za
Có, tôi đã chỉnh sửa tệp grub, chạy lệnh đó rồi khởi động lại máy.
heynnema avatar
lá cờ ru
@Bobchuck Sử dụng `grep -i FPDMA /var/log/syslog*` để xem liệu bạn có nhận được bất kỳ lượt truy cập nào sau lần khởi động lại cuối cùng hay không. Cũng xem bản cập nhật trong câu trả lời của tôi.
heynnema avatar
lá cờ ru
@Bobchuck Đã thêm cập nhật `fsck` vào câu trả lời của tôi.
Bobchuck avatar
lá cờ za
Tôi sẽ chạy các lệnh fsck vào sáng mai vì ở đây cũng đã muộn. Đối với nhật ký hệ thống, tôi đã cập nhật câu hỏi của mình với nhật ký cho câu hỏi đó ở cuối bài đăng.
heynnema avatar
lá cờ ru
@Bobchuck Bạn khởi động lại lúc mấy giờ? Lỗi FPDMA cuối cùng được ghi lại vào ngày 27 tháng 6 19:52:49.
Bobchuck avatar
lá cờ za
hm Chắc là khoảng nửa đêm hoặc quá nửa đêm, tức là khoảng ngày 28 tháng 6 00:00:00
heynnema avatar
lá cờ ru
@Bobchuck Ổ SSD vẫn có vấn đề. Thực hiện `fsck` và kiểm tra phần sụn. Bạn có thể có một ổ SSD hoặc cáp bị hỏng. SSD có phải là ổ đĩa SATA bên trong không? Bạn có bao nhiêu ổ đĩa? Tất cả SATA nội bộ? Hoặc USB bên ngoài?
Bobchuck avatar
lá cờ za
Tôi đã chạy fsck và đưa đầu ra vào bài đăng gốc của mình. Tôi cũng đã kiểm tra trạng thái SMART của ổ đĩa và nó vẫn ổn, vì vậy có vẻ như ổ đĩa vẫn hoạt động bình thường. Bất kể, tôi có 5 ổ đĩa: 3 ổ SSD và 2 ổ cứng, tất cả đều là SATA bên trong. chỉ ổ SSD chứa cài đặt được gắn khi khởi động.
heynnema avatar
lá cờ ru
@Bobchuck Làm tốt lắm! Vui lòng cho tôi xem ảnh chụp màn hình của cửa sổ Dữ liệu SMART. Ngoài ra, hãy kiểm tra phần sụn SSD, sử dụng liên kết trong câu trả lời của tôi. Trên cáp SSD SATA, bạn có cáp dự phòng không? Nếu không, ít nhất bạn có thể đặt lại cáp ở cả hai đầu không? Bạn có bộ nguồn đủ năng lượng để chạy tất cả các SDD/HDD của mình không?
Bobchuck avatar
lá cờ za
Tôi đã thêm ảnh chụp màn hình cửa sổ dữ liệu SMART vào bài đăng của mình.Việc thay đổi cáp SATA cũng như cập nhật chương trình cơ sở của SSD đều không làm được gì. Có, tôi có đủ năng lượng cho các ổ đĩa. Tôi đã có thiết lập hiện tại này được gần 2 năm và tôi đang nhận xét từ ổ đĩa Windows của mình trong cùng một máy ngay bây giờ.
heynnema avatar
lá cờ ru
@Bobchuck Cảm ơn bạn đã cập nhật. Mặc dù SMART nói rằng SSD vẫn ổn, nhưng không phải vậy. Bạn có **6146 lỗi không thể sửa được** và **21388 lỗi ECC không thể sửa được**! Vì bạn đã thay cáp và cập nhật chương trình cơ sở nên vấn đề là ở cổng SATA hoặc **SSD của bạn bị hỏng**.
Bobchuck avatar
lá cờ za
oh cảm ơn bạn đã làm rõ dữ liệu đó cho tôi. Tôi chưa bao giờ sử dụng bài kiểm tra đó trước đây. Thật không may là ổ đĩa chỉ mới 2 tuổi. Tôi sẽ hoán đổi cổng đang bật và chạy lại kiểm tra để xác nhận. Tôi hoàn toàn hiểu được tình hình, nếu sự cố thực sự xảy ra với ổ đĩa, thì giả thuyết hiện tại là ổ đĩa không đọc được dữ liệu đúng cách gây ra những lỗi này và có thể trở nên tồi tệ hơn dẫn đến lỗi thường xuyên hơn?
heynnema avatar
lá cờ ru
@Bobchuck Đúng. Khi đã ở trong khu vực **Kiểm tra & Dữ liệu THÔNG MINH**, bạn cũng có thể chạy các kiểm tra ngắn hạn/dài hạn và quan sát xem số lượng lỗi đó có tiếp tục tăng hay không.
Bobchuck avatar
lá cờ za
Tôi đánh giá cao sự giúp đỡ. Thật không may là nó phải kết thúc như thế này, nhưng may mắn là toàn bộ ổ đĩa vẫn chưa hỏng. Tôi sẽ chơi với một số bài kiểm tra đó và sau đó bắt đầu tìm kiếm một ổ đĩa mới.
heynnema avatar
lá cờ ru
@Bobchuck Bạn có thể muốn kiểm tra bảo hành của SanDisks trên ổ đĩa đó. Có lẽ họ sẽ thay thế nó cho bạn.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.