Bài đăng này là để chỉ ra cách "sửa chữa" hầu hết các vấn đề của khởi động với lỗi Arch Linux. Một cái gì đó giống như hình ảnh sau đây:
Có thể thấy, chúng ta thấy rằng đây là một trong rất nhiều "tổ hợp" lỗi xuất hiện ngẫu nhiên khi khởi động hệ điều hành gặp sự cố này. Như nó nói trong lỗi đó, nó chỉ ra rằng có thể có vấn đề trong "Phần cứng", tuy nhiên, như chúng ta đều biết trong hệ điều hành này, ngay cả những thủ thuật xấu của những gì không thuộc về hệ điều hành cũng có thể được giải quyết.
Vì vậy, tôi sẽ mô tả kinh nghiệm của tôi về vấn đề này. Từ những gì tôi có thể trải nghiệm, vấn đề chỉ là với Arch Linux hoặc một bản phân phối khác mà tôi đã thử nghiệm bên ngoài, vì với bất kỳ ubuntu nào mà tôi đã cài đặt hoặc thử nghiệm, nó bắt đầu mà không có vấn đề gì. Nhưng nếu anh ta cố gắng tách Arch Linux đã cài vào ổ cứng, nó gặp sự cố phải khởi động lại khoảng 50 lần để HĐH khởi động bình thường và sử dụng được.
Điều này đã xảy ra với tôi vì tôi chỉ có thể sử dụng ubuntu mà tôi đã cài đặt để kiểm tra nó và tôi thậm chí không thể thực hiện được một nửa số việc tôi có thể làm Arch Linux. Vì vậy, tôi quyết định giải quyết vấn đề này và bắt đầu điều tra, tìm kiếm các chủ đề trên diễn đàn có cùng vấn đề, họ cũng đề cập rằng đó là lỗi phần cứng và chính xác là do CPU, vì vậy tôi bắt đầu lo lắng, vì vậy tôi đã mở PC và xác minh điều gì đang xảy ra, tuy nhiên, nó không giúp được gì.
Nhưng một điều đã cho tôi thấy rằng tôi không nên từ bỏ là nếu Ubuntu Tôi có thể vì Arch Linux không (có lẽ Ubuntu tốt hơn Arch…?). Vì vậy, tôi bắt đầu viết các tham số khởi động vào hạt nhân của Arch Linux, những thứ như: lapic, nomce, intel_idle.max_cstate = 0, disable_cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufreq, intel_pstate = disable, i8042.noacpi = 1, apm = copyds, acpi = 0, apdtpi = XNUMX apm = copyds, acdtpi = XNUMX, apm = copyds pci = nocrs, rhgb, acpi = force, pnpacpi = XNUMXff và những người khác… Tất cả điều này đã được đề xuất trong các diễn đàn mà tôi đã đọc.
Cho đến khi tôi phải nhập tài liệu về các tham số hạt nhân, mà tôi đề xuất bằng cách: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Và tôi đã tìm thấy một thông số khá thú vị mà tại thời điểm này tôi đã khởi động được Arch Linux Không vấn đề gì:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Như đã chỉ ra ở đó, những gì tham số này làm là giới hạn việc sử dụng cho một cpu mà không kích hoạt chế độ xử lý đối xứng. Lúc đầu, nó hoạt động khá tốt cho đến khi tôi sử dụng lệnh pacman-Syyu; ném cho tôi một lõi bị đổ o lỗi phân đoạn.
Vì vậy, tôi tự động nhận thấy rằng có điều gì đó kỳ lạ đang xảy ra, vì vậy tôi bắt đầu chạy các quy trình khác cho đến khi đột nhiên hệ thống đóng băng hoàn toàn và không hoạt động nữa, cho đến khi tôi khởi động lại nó. Vì vậy, tôi đã thực hiện thao tác tương tự, nhưng lần này tôi quản lý để thực hiện htop và nó cho tôi thấy những điều sau:
Đúng như dự đoán, nó chỉ hiển thị một CPU, vì CPU kia đã vô hiệu hóa nó, tuy nhiên, tôi thấy rất lạ tại sao các chương trình lại ném phân biệt, và thậm chí không thể khởi động môi trường đồ họa; vì vậy nó là thứ ít nhất đã cho tôi thêm hy vọng rằng nếu tôi đặt các tham số hạt nhân theo một cách nào đó, nó sẽ khởi động Arch Linux như thường lệ.
Vì vậy, tôi tiếp tục thử các thông số khác mà tôi đã viết trong danh sách cho đến khi tôi bắt gặp thông số này, đó là giải pháp tốt nhất vào lúc này:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce cô lập = 1
Tham số này thực hiện một việc đơn giản như cô lập (không hủy kích hoạt) lõi thứ hai của CPU trong xử lý đối xứng, nghĩa là, tải xử lý được trao cho một lõi trong khi lõi kia chỉ bổ sung. Điều này, mặc dù có vẻ mâu thuẫn, nhưng không ảnh hưởng quá nhiều đến hiệu suất, vì hệ điều hành tuyệt vời này đã có thể chạy các ứng dụng theo cách này:
Vì vậy, với điều này, vấn đề duy nhất mà tôi quan sát thấy xảy ra tại thời điểm khởi động, là một hoặc hai hạt nhân hoảng loạn hoặc lỗi; nhưng so với 50 lần tôi phải khởi động lại trước đây, tôi có thể coi đó là một "cách giải quyết". Đối với phần còn lại, cho đến nay nó đã cho phép tôi sử dụng Hệ điều hành và viết bài đăng này mà bạn đang đọc ngay bây giờ :-).
Tôi hy vọng họ sẽ giúp bạn và không thoát ra khỏi GNU / Linux, đó là hệ điều hành tốt nhất mà họ từng phát minh ra. Tôi nói điều đó chắc chắn.
Thông tin rất thú vị. Tôi chưa bao giờ gặp những hoảng loạn hạt nhân đó trong ArchLinux trong những năm tôi sử dụng nó, nhưng thật tốt để biết phải làm gì nếu sự cố xảy ra tại bất kỳ thời điểm nào. Cảm ơn bạn!
Dù sao, tôi đã sử dụng Arch trong một thời gian dài (tôi đã giống như 1 năm không có Arch) và không có sự hoảng sợ về nhân.
Cảm ơn vì tiền hỗ trợ.
Nhiều khả năng, như tôi đã đề cập trong bài đăng, vấn đề xảy ra do phần cứng, bởi vì trong những gì tôi sử dụng vòm, nó cũng không mang lại cho tôi bất kỳ vấn đề nào thuộc loại này.
Một người khác có kết quả xuất sắc trong Arch. Tôi chưa bao giờ có Kernel Panic
Hơn 2 năm với GNU / Linux ... 2 năm đã có với ArchLinux, chưa bao giờ sợ hạt nhân .. 😉
Tôi nghĩ rằng sự hoảng loạn trong hạt nhân là do phần cứng nhiều hơn là do bản thân bản phân phối. Tôi chưa bao giờ thấy một hạt nhân hoảng sợ trên máy tính xách tay mà tôi sử dụng bây giờ ngoại trừ một lần tôi đặt một Ubuntu alpha vào nó (và Arch Linux cũng đã ở đây trong hai năm). Mặt khác, trong một máy tính xách tay khác mà tôi có, bất kỳ bản phân phối nào mà tôi đặt luôn khiến hạt nhân bị hoảng loạn và nhiều lỗi cho mọi sở thích.
Với kernel 3.14 trên Debian, tôi đã gặp phải vấn đề về sự hoảng loạn của kernel, ngoài ra bất cứ khi nào tôi bật PC lên, tôi nhận được thông báo "kết nối / ngắt kết nối hết thời gian" (và cả khi tôi tắt nó).
Điều đó đã xảy ra với tôi rất nhiều trong Fedora cũng như trong Arch, nhưng tôi không biết tại sao và làm thế nào tôi không thấy sự khác biệt vì tôi đã không dành thời gian điều tra hoặc giải quyết vấn đề đó (nếu đó là một vấn đề).
Tôi nghĩ lý do là chúng được biên dịch với gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Cảm ơn bạn rất nhiều cho các thông tin. Một số trong nhiều thứ mà chúng ta có thể tự hào về loại diễn đàn này
Tại sao điều này lại xảy ra với Arch Linux? Có lẽ như vậy là chưa đủ với các vấn đề thường xuyên xuất hiện với sự chậm chạp hoặc treo của hệ thống đến mức ném hệ thống sang phím đàn.
Chào? Bạn đang nói về cái gì o_O
Arch là một bản phân phối KISS có thể định cấu hình từ nền tảng của chính hệ điều hành, nói một cách ngắn gọn, nếu hệ thống nặng thì đó là do bạn đã xây dựng nó theo cách đó, nếu hệ thống có lỗi là do bạn tạo ra hoặc do bạn không Cấu hình một cái gì đó một cách chính xác. Arch wiki khá hoàn chỉnh, một vài năm trước đây không có nhiều chủ đề quan trọng bằng tiếng Tây Ban Nha, điều đó và quá trình cài đặt khó hơn nhiều và hơi khó khăn, bây giờ mọi thứ tự động hơn một chút.
Đổ lỗi cho bản phân phối vì lỗi người dùng là… Windows (?).
Việc đổ lỗi cho bản phân phối về lỗi là nhất quán, đơn giản vì nó là sự thật. Sau khi gặp sự cố tương tự với Manjaro, tôi đã thử Arch, Antergos và một bản phân phối không xác định khác (tôi không thể nhớ tên bây giờ, xin lỗi) mà ai đó đã giới thiệu với tôi để đảm bảo với tôi rằng nó không gây ra vấn đề, nhưng không có gì; họ đều cho nó. Trong OpenSuse, Fedora, Mint, Mageia và tất cả những thứ mà tôi đã thử sau đó đều không vượt qua được. Theo như tôi liên quan, tôi không còn lựa chọn nào khác ngoài việc nghĩ rằng đó là lỗi của bản phân phối. Nhưng, này, tôi không yêu nó hay bất cứ thứ gì, hơn nữa, nó làm phiền tôi khi không thể sử dụng bất cứ thứ gì dựa trên Arch, bởi vì tôi thích nó rất nhiều, nhưng vấn đề chết tiệt đó đã ngăn cản tôi. Tôi cũng không nghĩ rằng đó là về phần cứng, bởi vì nhiều người trong số chúng tôi điều đó xảy ra với chúng tôi đã không xảy ra trước khi sử dụng cùng một cái chết tiệt. Vâng, thực ra nó phải là một cái gì đó liên quan đến phần cứng, nhưng, quay trở lại vấn đề tương tự, nếu tôi không thực hiện bất kỳ thay đổi nào và tôi gặp vấn đề với cùng một thiết bị mà tôi không có trước đó, rõ ràng là nó sẽ đến hạn. đối với một sự thay đổi được thực hiện bởi Arch, người đã khiến tôi khó hiểu.
"Đổ lỗi cho bản phân phối cho lỗi người dùng là như vậy ... Windows (?)."
Tôi muốn nói với bạn rằng việc đổ lỗi cho người dùng về lỗi sản phẩm là do Apple. Thành thật mà nói, tôi đã nghĩ về nó cả nghìn lần, nhưng tôi không thấy lợi ích của việc sử dụng thứ gì đó mà người bảo trì về cơ bản rửa tay cho bất kỳ mục đích nghiêm túc nào. Và tôi nói rằng xem xét rằng phần mềm GPL không có bảo hành.
Bạn có thể nói như bạn muốn nhưng nếu nó là trường hợp tương tự của các báo cáo về việc iPhone bị thiếu tín hiệu và phản hồi của Apple "rằng bạn đang làm sai" từ vài năm trước. Nếu bạn tạo một bản phân phối, bạn thường muốn cung cấp một số chất lượng và hỗ trợ tối thiểu, và sự thật là Arch về cơ bản là một hệ thống theo sở thích, nơi bạn thấy rằng các nhà phát triển của nó có những thứ thú vị khi đóng gói những thứ mới, nhưng ít quan tâm đến việc cung cấp hỗ trợ thực . Mỗi khi tôi nhìn thấy loại bài đăng này, tôi đánh giá cao hơn công việc đằng sau bản phân phối mà tôi sử dụng.
Và có, đó là sự cố phần mềm nếu nó không hoạt động, nếu nó ngừng hoạt động trong một bản cập nhật hoặc nếu một cái gì đó của phần cứng bị hỏng. Đó là một bản phân phối hoảng sợ của nhân trong khi một bản phân phối khác thì không ... tốt, vâng, rõ ràng là có một bản phân phối đang làm những điều đúng và sai khác. Bây giờ, nếu bạn thấy vui khi sử dụng Linux theo phong cách của những năm 90, nơi chúng tôi phải biên dịch lại hạt nhân mỗi khi cắm vào một máy in mới… đó bạn.
Kernel có được biên dịch bởi các nhà phát triển không? hay của riêng bạn?
Các chu kỳ nhân được tạo ra khi một số thành phần nhất định chưa được chọn (AND) khi biên dịch, hoặc một số mô-đun chưa được kích hoạt để hỗ trợ một số phần cứng nhất định. Với việc thực hành và hiểu biết về phần cứng của bạn (bạn phải mở máy tính và xem nó có nhãn hiệu chip nào), bạn có thể xây dựng một nhân tùy chỉnh (bằng cách chạy chrooting). Nếu ubuntu và đĩa CD cài đặt Arch có trên máy tính của bạn, thì có điều gì đó trong quá trình biên dịch chưa được kích hoạt.
Đó là hạt nhân cổ phiếu từ chính Archlinux, từ các kho lưu trữ.
Kernel mà bạn đang sử dụng, có điều gì đó còn sót lại mà phần cứng của bạn không thích, bạn phải có một phiên bản chip hiếm trên bo mạch chủ của mình hoặc thậm chí là một lỗi trong chip (nó thường xảy ra).
Đó có thể là một bảng bị hỏng từ bios acpi của bạn, điều bình thường là người Trung Quốc làm nhiệm vụ thậm chí còn không tính toán tốt tổng tổng của từng bảng, những thông báo này thường xuất hiện với $ dmesg -human ở đầu khởi động.
Bạn cũng nên thử một nguồn điện khác, khi bộ lọc không thành công, gợn sóng có xu hướng tạo ra những lỗi như vậy.
Đầu tiên, hãy thử thay đổi nguồn và xem điều gì xảy ra, nếu nó vẫn như cũ, hãy thử cấu hình hạt nhân cho phù hợp với phần cứng của bạn, bằng cách này bạn sẽ hiểu rõ hơn về máy tính của mình trong quá trình này.
Cảm ơn vì những lời khuyên. Nhân tiện nó là một máy tính xách tay, tôi nghĩ rằng tôi nên thay đổi pin. Nhưng tôi thấy những gì bạn đã nói với tôi có thể giúp tôi.
Sự hoảng loạn một nhân vẫn khiến tôi phát điên một phần là do lỗi của những người chơi nouveau và chiếc card tích hợp nVidia 6150 SE cũ, lỗi thời và rất bụi bặm của tôi (ý tôi là một phần vì họ đã làm rất tốt việc hỗ trợ một loạt chip đồ họa giống như những thứ mà nVidia có, và tất cả những điều này, chỉ sử dụng kỹ thuật đảo ngược, cộng với sự cố chỉ xảy ra đối với một số thẻ có chipset NV4E).
Chỉ cần khởi động Openbox + Firefox và thảm họa xảy ra (không gì đẹp hơn là nhìn thấy một bức tranh khảm đen trắng hoàn toàn ngẫu nhiên trên màn hình của bạn). Và tôi đã hát nó kể từ kernel 3.6 trong Debian, Fedora, Archlinux, Slackware và bây giờ đã được xác minh lại trong Gentoo (vừa được cài đặt với kernel 3.12), tôi không còn bận tâm đến việc ghi nhật ký, vào kernel hoặc cho nó thời gian. viết một cái gì đó không phải là một ký tự vô nghĩa khổng lồ.
Tôi cung cấp cho bạn giải pháp, một máy tính mà tôi có với gentoo và video nvidia tích hợp giống với trình điều khiển nouveau, vì vậy tôi không có lựa chọn nào khác ngoài việc sử dụng trình điều khiển nvidia đã đóng, chip của tôi phải sử dụng trình điều khiển 304.123
Bộ điều khiển tương thích VGA 00: 0d.0 [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA controller])
Bạn phải vá một tệp hạt nhân trước khi biên dịch nó, nếu không được vá, chế độ đồ họa sẽ từ chối khởi động.
Các bước là:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Tìm kiếm bằng ctrl + w trong nano văn bản này, acpi_os_wait_events_complete và nano sẽ đưa bạn đến phần này:
void acpi_os_wait_events_complete (void)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Bản vá bạn phải thêm là dòng cuối cùng này bắt đầu bằng EXPORT, ctrl + hoặc ctrl + x
Sau đó, bạn biên dịch hạt nhân, cài đặt các mô-đun, cài đặt hạt nhân, tạo initramfs nếu bạn cần, thêm splash vào initramfs nếu bạn sử dụng splash, tạo lại các mục cho grub và cuối cùng và rất quan trọng, bạn phải xây dựng lại các mô-đun không phải từ hạt nhân hoặc mô-đun nvidia độc quyền, nếu không thực hiện điều này, chế độ đồ họa sẽ không hoạt động.
# eselect danh sách hạt nhân
# eselect bộ hạt nhân x
# cd / usr / src / linux
# làm
# make module_install
# mount / boot
# thực hiện cài đặt
# dracut –hostonly »3.15.7-gentoo –force
# splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img suggest-world
# Grub-mkconfig -o /boot/grub/grub.cfg
# nổi lên @ mô-đun-xây dựng lại
# umount / boot
# tắt máy -r ngay
Nếu bạn sử dụng genkernel, bạn chỉ cần vá tệp đó và tôi hiểu rằng genkernel tự sửa.
Ngoài ra, bạn phải xóa hỗ trợ drm và trình điều khiển nvidia cũng như các chip video khác khỏi nhân để chúng không va chạm với trình điều khiển nvidia đã đóng được cài đặt dưới dạng mô-đun nvidia.
Trong trường hợp sử dụng bootsplash, bạn phải bao gồm trình điều khiển uvesa trong nhân để nó hỗ trợ độ phân giải màn hình cao vì trình điều khiển nvidia đã đóng (nếu tôi nhớ không nhầm) không hỗ trợ hơn 800 × 600 trong đầu cuối tty1 «F1» của chiếc ủng.
Tôi không biết về các bản phân phối khác, nhưng tôi cho rằng nó sẽ hoạt động trên bất kỳ bản phân phối nào nếu các bước này được thực hiện, tiết kiệm thay đổi xuất hiện cho bất cứ điều gì.
Đây là những nguyên tắc bạn phải tuân theo, đối với nvidia và uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Cảm ơn vì thông tin, nhưng tôi đã giải quyết vấn đề một cách chính xác bằng cách thay đổi thông tin độc quyền. Tôi nhớ rằng trình điều khiển nVidia trước đó (304.121) cũng phải được vá khi chuyển sang phiên bản 3.13 vì nó có vấn đề trong quá trình biên dịch mô-đun (không có lỗi, nhưng mô-đun từ chối hoạt động) và mọi thứ cũng do ACPI xử lý sự kiện. Trong Debian, tôi gặp sự cố và cũng tìm ra giải pháp.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Tôi đã sử dụng Manjaro làm ví dụ, nhưng tôi đã đề cập trước đây rằng điều tương tự cũng xảy ra với tôi với Arch và các dẫn xuất khác. Vì vậy, tôi tin rằng vấn đề là của họ nhiều hơn là những vấn đề bị ảnh hưởng.
Pd: Tôi không thể trả lời trực tiếp tin nhắn liên quan vì tùy chọn trả lời không xuất hiện ...
Tôi vừa chuyển từ Manjaro sang Linux Mint vì nó sẽ bị đóng băng khi khởi động sau khi cập nhật lên phiên bản sau 0.8.9 (tôi không nhớ là phiên bản nào). Theo những gì tôi đọc, điều này thường xảy ra trên máy tính xách tay. Vấn đề của tôi được đề cập không giống với vấn đề trong bài đăng này, tôi nghĩ rằng tôi đã đi đến kết luận rằng nó có thể liên quan đến quản lý năng lượng. Có những người không bị đóng băng nếu họ khởi động máy tính xách tay trong khi rút phích cắm. Ngay bây giờ tôi không nhớ liệu điều đó có cho phép tôi luôn bắt đầu mà không gặp vấn đề gì hay không, nhưng tất nhiên tôi đã có thể làm điều đó nhiều lần hơn với cái giá là mất nhiều thời gian hơn để làm điều đó.
Dù sao thì cuối cùng tôi cũng từ bỏ và chuyển sang dùng Fedora và Linux Mint.
Thật trùng hợp, hôm qua tôi đã cố gắng treo nó mà không có bộ sạc và khi tiếp tục lại nó bị treo và tôi phải khởi động lại.
Khá là buồn cười, tôi đã chơi với Arch được vài tháng và tôi chưa có một Kernel Panic nào! Điều đó đã xảy ra với tôi với Antergos (Arch với một kho lưu trữ bổ sung) từ môi trường trực tiếp, nhưng tôi cho rằng nó dễ hiểu hơn ở đó. Nó có thể là vấn đề với bo mạch chủ hoặc mô-đun RAM bị lỗi? Tôi nhớ khoảng 2 năm trước, một mô-đun RAM đã gây ra cho tôi một số màn hình xanh trong Windows và một số Kernel Panics! trên Mandriva. Tôi đã phải kiểm tra từng bộ nhớ tại một thời điểm giữa khởi động lại và khởi động lại.
Nó là một vấn đề Arch (mang tất cả các dẫn xuất của nó), bởi vì trong các bản phân phối khác không có vấn đề như vậy. Điều tôi thấy xấu hổ là đến thời điểm này họ vẫn chưa giải quyết được. Nó chỉ là họ trong nhiều năm! Tôi đã đọc các vấn đề tương tự từ năm 2011. Tôi rõ ràng rằng đó là một cái gì đó đến và đi khi họ cập nhật, bởi vì sử dụng các phiên bản 0.8.7, 0.8.8 và 0.8.9 mà không cập nhật chúng, không có gì xảy ra. Từ đó trở đi mọi thứ trở nên tồi tệ, và chắc chắn ở các phiên bản cũ điều đó cũng đã xảy ra. Tại sao nó chỉ xảy ra với một vài người trong chúng ta? Tôi không biết, nhưng tôi không nghĩ đó là vấn đề của chúng tôi, nhưng Arch, bởi vì, như đã nói, các bản phân phối khác diễn ra hoàn hảo. Tôi đã bẻ gãy sừng của mình trong ngày của anh ấy để tìm giải pháp, nhưng tôi cảm thấy mệt mỏi. Vì vậy, tôi rất tiếc, tôi sẽ không sử dụng Arch.
Vòm 0.8.7, 0.8.8 và 0.8.9? Tôi phát hiện ra rằng Arch sử dụng danh pháp phiên bản đó.
Có thể là bạn đang sử dụng Manjaro?
Ok, tôi tự trả lời bằng cách đọc bình luận trước của bạn, và một thứ là Manjaro và một thứ nữa là Arch.
Việc đổ lỗi cho một bản phân phối cho một vấn đề nào đó cũng không nhất quán (không thực sự nhất quán), ít nhất là trong trường hợp của tôi, tôi không thể đổ lỗi cho bao nhiêu bản phân phối mà tôi đã thử cho sự cố với nouveau và thẻ nVidia 6150SE của tôi, bởi vì vấn đề là MMIO xử lý trình điều khiển và thẻ (nVidia sẽ biết những gì cần sửa chữa và những thứ điên rồ mà họ sẽ phải sửa chi tiết đó). Phần cứng cũng có thể là vấn đề và bạn có thể thấy rằng trong bất kỳ hệ điều hành nào bạn sử dụng (Windows, Linux, BSD) và theo kinh nghiệm sửa chữa máy tính của tôi, tôi đã thấy các vấn đề phần cứng rất lạ (chẳng hạn như PC từ chối khởi động trừ khi bạn thay đổi vị trí bộ nhớ và khi tắt bạn phải lặp lại quy trình) và tôi không thể đổ lỗi cho Windows và Debian về điều đó.
Tôi đã gặp sự cố hạt nhân với ubuntu 12.04 trực tiếp
Tôi rất thích chiếc máy tính xách tay Secure HP pavilion dm4 của mình, RAM 8 GB, ổ cứng 500, nó đã sử dụng được hơn 5 năm. Tôi không nhớ tốc độ của bộ vi xử lý, Intel core i5, tôi nghĩ là hơn 2 mhz.
Tôi không thể viết bất cứ điều gì trên màn hình thiết bị đầu cuối. Tôi sẽ tiếp tục tìm kiếm thêm thông tin, để giải quyết vấn đề này.