Điểm:0

Tôi đã ngắt kết nối ext4 (Hệ điều hành Ubuntu) với gparted. Bây giờ nó không được phân bổ. Điều gì đang xảy ra?

lá cờ br
nfs

Tóm tắt nhanh:
Tôi có ổ SSD 500 GB. Chỉ có Ubuntu 20.04 được cài đặt trong đó. Tôi đã viết tệp win10.iso bên trong Phân vùng hệ thống EFI của nó bằng lệnh dd. Sau đó tôi không thể khởi động. Sau đó, tôi khởi động Ubuntu từ usb. boot-repair bảo tôi mở dung lượng 1mb (hoặc đại loại như thế). Tôi đã làm theo một số hướng dẫn nhưng tôi đã thất bại. Tôi muốn lưu ít nhất thư mục nhà. Một nửa ổ SSD đã được sử dụng. Phần EFI đã được ghi đè nhưng phần ext4 nơi cài đặt Ubuntu không bị ghi đè.

Hình ảnh (gparted): Tình huống ban đầu. Trước khi thực hiện bất kỳ quy trình gparted nào.
Hình ảnh (gparted): Thông tin về Phân vùng hệ thống EFI /dev/sda1
Hình ảnh (gparted): Sau khi xóa EFI và Unmounting ext4

Đây là những gì tôi đã làm:

  • Tôi đã mở gparted.
  • tôi xóa Phân vùng hệ thống EFI (/dev/sda1)
    (Trong một giây, tôi nghĩ tốt hơn hết là ngắt kết nối ext4 để tránh mắc một số lỗi. Lúc đó đã là đêm khuya.)
  • Tôi đã ngắt kết nối ext4 trên gparted (/dev/sda2)

Ngay sau khi tôi ngắt kết nối phân vùng dev/sda2 ->/dev/sda1,/dev/sda2, chưa phân bổ (1.02MiB), được thu gọn thành 1 chưa phân bổ hệ thống tập tin.

Tôi đã không viết bất cứ điều gì trên ssd (theo như tôi biết) sau khi điều này xảy ra.

tôi chỉ sử dụng fdisk -l, lsblk -s, df, gắn kết/số lượng mệnh lệnh.

Đầu ra thiết bị đầu cuối (ubuntu-usb): fdisk -l đầu ra -> sdb. , Tên hệ thống tệp đã được đổi thành sdb sau khi khởi động từ usb (ubuntu)
Đầu ra thiết bị đầu cuối (ubuntu-usb): fsck - N /dev/sdb đầu ra
Đầu ra thiết bị đầu cuối (ubuntu-usb): Thông số đĩa /dev/sdb, fdisk -l đầu ra


Sau khi đọc rất nhiều lo lắng, tôi có một số ý kiến, câu hỏi ...
Đây là những gì tôi rút ra:

  • Tôi có thể đã xóa thứ gọi là bảng phân vùng.
  • Mọi người cung cấp bằng cách sử dụng đĩa kiểm tra. Nhưng trước testdisk -> Tôi nên hay không nên sử dụng đ hoặc giải cứu hoặc dd_rescue để sao chép đĩa. Một số người đề nghị lấy bản sao của SSD. Sau đó lấy bản sao của bản sao đó và làm việc trên đó.

Tôi tìm kiếm sự giúp đỡ của bạn và kinh nghiệm của bạn để hiểu những gì đã xảy ra.
Làm thế nào tôi có thể chọn một cách tiếp cận an toàn.
Cảm ơn bạn,



CẬP NHẬT:

  • Tôi có thể xem các tập tin của mình với đĩa kiểm tra.
  • đầu ra gdisk cho thấy rằng MBR: bảo vệ, GPT: hiện tại
  • Chỉ có 1 phân vùng. đầu ra testdisk là:
    Khởi động Linux(65 101 37) kết thúc(60801 47 46) size_in_sector(975720448)
  • Trước khi làm bất cứ điều gì, bạn có thể sao chép chính xác đĩa của mình bằng giải cứu. Vui lòng đọc phần về ddrescue trong tài liệu testdisk.
  • Sau khi sao chép đĩa của bạn, một cách làm hữu ích là lấy bản sao của bản sao đó và làm việc trên bản sao sau.
  • Tôi chạy testdisk trên bản sao mới nhất và thực hiện nhiều thử nghiệm trên đó.
  • Bằng cách làm theo tài liệu testdisk, tôi đã lưu dữ liệu của mình.


Đầu ra lệnh:

Sudo gdisk -l /dev/sda:

GPT fdisk (gdisk) phiên bản 1.0.5  

Quét bảng phân vùng:  
  MBR: bảo vệ  
  BSD: không có  
  APM: không có  
  GPT: hiện tại  

Đã tìm thấy GPT hợp lệ với MBR bảo vệ; sử dụng GPT.  
Đĩa /dev/sda: 976773168 cung, 465,8 GiB  
Mô hình: Samsung SSD 860   
Kích thước cung (logic/vật lý): 512/512 byte  
Mã định danh đĩa (GUID): xxxxx   
Bảng phân vùng chứa tới 128 mục  
Bảng phân vùng chính bắt đầu ở khu vực 2 và kết thúc ở khu vực 33  
Khu vực có thể sử dụng đầu tiên là 34, khu vực có thể sử dụng cuối cùng là 976773134  
Các phân vùng sẽ được căn chỉnh trên ranh giới 2048 ngành  
Tổng dung lượng trống là 976773101 sector (465,8 GiB)  

Số Bắt đầu (ngành) Kết thúc (ngành) Kích thước Mã Tên  


đĩa kiểm tra Đầu ra:

Image (testdisk): Đầu ra phân vùng

T3 ngày 12 tháng 10 14:21:50 2021
Dòng lệnh: TestDisk/gỡ lỗi

TestDisk 7.1, Tiện ích khôi phục dữ liệu, tháng 7 năm 2019
Christophe GRENIER <[email protected]>
https://www.cgsecurity.org
Hệ điều hành: Linux, kernel 5.8.0-43-generic (#49~20.04.1-Ubuntu SMP Thứ Sáu ngày 5 tháng 2 09:57:56 UTC 2021) x86_64
Trình biên dịch: GCC 9.2
ext2fs lib: 1.45.5, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, lời nguyền lib: ncurses 6.1
/dev/sda: hỗ trợ LBA, HPA, LBA48, DCO
/dev/sda: kích thước 976773168 cung
/dev/sda: user_max 976773168 cung
/dev/sda: native_max 976773168 cung
Cảnh báo: không thể lấy kích thước cho Đĩa /dev/mapper/control - 0 B - 0 sector, sector size=512
Cảnh báo: không thể lấy kích thước cho Disk /dev/loop6 - 0 B - 0 sector, sector size=512
Cảnh báo: không thể lấy kích thước cho Disk /dev/loop7 - 0 B - 0 sector, sector size=512
Danh sách đĩa cứng
Đĩa /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, kích thước cung = 512 - Samsung SSD 860
Đĩa /dev/sdb - 15 GB / 14 GiB - CHS 14664 64 32, kích thước sector=512 - SanDisk Cruzer Force, FW:1.00
Đĩa /dev/loop0 - 2109 MB/2012 MiB - 4120632 sector (RO), kích thước sector=512
Đĩa /dev/loop1 - 53 MB/51 MiB - 104536 sector (RO), kích thước sector=512
Đĩa /dev/loop2 - 32 MB/31 MiB - 63664 sector (RO), kích thước sector=512
Đĩa /dev/loop3 - 229 MB/218 MiB - 448496 sector (RO), kích thước sector=512
Đĩa /dev/loop4 - 58 MB / 55 MiB - 113592 sector (RO), kích thước sector=512
Đĩa /dev/loop5 - 67 MB/64 MiB - 132648 sector (RO), kích thước sector=512

Loại bảng phân vùng (tự động): Intel
Đĩa /dev/sda - 500 GB / 465 GiB - Samsung SSD 860 EVO 500GB
Loại bảng phân vùng: Intel

Giao diện nâng cao
Hình học từ i386 MBR: head=256 sector=63
check_part_i386 1 loại EE: không kiểm tra
 1 P EFI GPT 0 0 2 60801 80 63 976773167

Phân tích Đĩa /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63
Hình học từ i386 MBR: head=256 sector=63
check_part_i386 1 loại EE: không kiểm tra
Cấu trúc phân vùng hiện tại:
 1 P EFI GPT 0 0 2 60801 80 63 976773167

Cảnh báo: Phần kết thúc dở (CHS và LBA không khớp)
Không có phân vùng nào có khả năng khởi động

search_part()
Đĩa /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63

recovery_EXT2: s_block_group_nr=0/3722, s_mnt_count=206/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recovery_EXT2: s_blocksize=4096
recovery_EXT2: s_blocks_count 121965056
recovery_EXT2: part_size 975720448
Hệ thống tập tin được tạo: CN 21 tháng 6 00:15:40 2020
Thời gian gắn kết lần cuối: Thứ bảy ngày 9 tháng 10 21:29:00 năm 2021
     Linux 65 101 37 60801 47 46 975720448
     ext4 blocksize=4096 Large_file Sparse_SB, 499 GB / 465 GiB

Kết quả
   * Linux 65 101 37 60801 47 46 975720448
     ext4 blocksize=4096 Large_file Sparse_SB, 499 GB / 465 GiB

Gợi ý cho người dùng nâng cao: dmsetup có thể được sử dụng nếu bạn muốn tránh viết lại bảng phân vùng vào lúc này:
tiếng vang "0 975720448 tuyến tính/dev/sda 1050624" | dmsetup tạo test0

giao diện_write()
 1 * Linux 65 101 37 60801 47 46 975720448
mô phỏng viết!

write_mbr_i386: bắt đầu...
write_all_log_i386: bắt đầu...
Không có phân vùng mở rộng

TestDisk đã thoát bình thường.

Organic Marble avatar
lá cờ us
Bạn có bản sao lưu dữ liệu của mình không?
lá cờ br
nfs
@Đá cẩm thạch hữu cơ Thật không may, tôi đã không có.
mook765 avatar
lá cờ cn
Bạn đã ghi đè nội dung của Phân vùng hệ thống EFI (ESP) chứa bộ tải khởi động của bạn, đó là lý do tại sao bạn không thể khởi động sau lệnh `dd` của mình. Bạn sẽ không thể khôi phục nội dung ban đầu của phân vùng này mà phải tạo một phân vùng mới và cài đặt lại bộ tải khởi động ở đó nếu muốn sử dụng lại hệ thống. Phân vùng khác sẽ dễ dàng được phục hồi bằng testdisk. Có thể không phải là một ý tưởng tồi nếu tạo một bản sao của ổ đĩa trước, chỉ trong trường hợp có bất kỳ sự cố nào xảy ra trong quá trình khôi phục của bạn.
lá cờ br
nfs
@mook765 Điều tôi muốn làm là khôi phục dữ liệu trong phần 460gb. Một nửa của nó đã được sử dụng. Tôi không thể hiểu làm thế nào nó có thể bị xóa trong một giây. Ở đó tôi muốn lưu thư mục Home, v.v.
mook765 avatar
lá cờ cn
Tôi đoán bạn đã tự xóa phân vùng này mà không có ý định làm như vậy. Nên dễ dàng phục hồi, hãy thử testdisk ...
lá cờ br
nfs
@ mook765 bạn có gợi ý nào để tạo một bản sao của đĩa không?
Yvain avatar
lá cờ us
Bạn CÓ THỂ chỉ cần tạo lại bảng phân vùng bằng fdisk và các phân vùng sẽ ở đây không bị ảnh hưởng
oldfred avatar
lá cờ cn
Nếu đó là bảng phân vùng gpt, bản sao lưu ở cuối có thể vẫn còn đó. dd của bạn đã ghi đè hoàn toàn phần đầu của ổ đĩa bao gồm bảng phân vùng và tất cả dữ liệu có kích thước bằng ISO. Nếu MBR, không có bảng phân vùng sao lưu. Nếu ISO nhỏ hơn ESP & phân vùng đầu tiên và dữ liệu ở vị trí thứ hai hoặc xa hơn trên ổ đĩa, thì testdisk có thể khôi phục nó. Điều này cho thấy điều gì? `sudo gdisk -l /dev/sda`
lá cờ br
nfs
@oldfred cảm ơn bạn rất nhiều. Tôi đoán tôi bắt đầu hiểu vụ án. Khi tôi sử dụng dd để viết trên Efi, dd đã dừng lại do thiếu dung lượng trong tệp hệ thống EFI. Đó là khoảng 500 MB. Tôi đã thêm đầu ra `Sudo gdisk -l /dev/sda` dưới bài viết, ngay sau phần *Thank you,*.
Soren A avatar
lá cờ mx
Ảnh chụp màn hình trước hiển thị/dev/sda, ảnh sau/dev/sdb là hai đĩa khác nhau ...
oldfred avatar
lá cờ cn
Bạn không thể chạy fsck trên ổ đĩa như sda, chỉ trên phân vùng có định dạng ext4 như sda2. Nhưng bây giờ bạn không hiển thị bất kỳ phân vùng nào, chỉ có ổ đĩa đó là gpt? Không chắc dữ liệu bảng phân vùng sao lưu đã bị xóa là gì, có lẽ bạn đã xóa tất cả các phân vùng trước dd. Lưu ý rằng biệt danh của dd là Kẻ hủy diệt dữ liệu và hiếm khi được sử dụng.
lá cờ br
nfs
@oldfred Trong khi tôi đang sử dụng Ubuntu trên ssd (là sda2), tôi đã viết trên EFI (sda1). Sau đó, tôi tắt máy và tất nhiên Nó không khởi động được. Sau đó, tôi khởi động Ubuntu từ thanh usb. Tôi đã xóa EFI bằng gparted. Sau khi tôi xóa Efi, ext4(sda2) vẫn ở đó (có thể trên ram? Tôi không làm mới). Sau đó, tôi ngắt kết nối ext4(sda2). Sau đó, nó trở thành không được phân bổ. Tôi chỉ sử dụng dd để viết trên EFI (sda1). Ổ đĩa chưa phân bổ (ssd) là gpt. Cảm ơn bạn đã lưu ý :) Tôi thực sự không biết điều đó :(
oldfred avatar
lá cờ cn
Trừ khi efi(sda1) lớn bằng Windows ISO, dd sẽ được ghi vào efi, nhưng không dừng lại cho đến khi sao chép toàn bộ ISO, ghi đè ít nhất là phần đầu của sda2. Nếu không dừng khi sda1 đầy.
lá cờ br
nfs
@oldfred Nó tự động dừng. Nó không viết trên đó. Nếu đây là trường hợp, như bạn đã nói, gpt có bảng phân vùng dự phòng ở cuối Sơ đồ bảng phân vùng GUID. Tôi có thể khôi phục nó bằng bản sao lưu không?
lá cờ br
nfs
@Yvain nên tuân theo các lệnh nào để đạt được quy trình tạo lại?
oldfred avatar
lá cờ cn
Nhưng gdisk vì bất kỳ lý do gì không hiển thị phân vùng. Nó nói gpt. Khi bản chính bị hỏng, nó thông báo rằng nó đang sử dụng bản sao lưu và bạn phải chạy các lệnh sửa chữa gdisk để sửa bảng phân vùng. Nếu bạn biết chính xác bắt đầu và kết thúc phân vùng, bạn có thể xây dựng lại bảng theo cách thủ công, nhưng thường testdisk dễ dàng hơn nhiều. sửa chữa gpt: http://www.rodsbooks.com/gdisk/repairing.html Nếu nó hiển thị các phân vùng: Thông tin sửa chữa khác, hãy sử dụng p, v & w để ghi bảng phân vùng. Nếu không đúng, chỉ cần sử dụng q để thoát. : http://askubuntu.com/questions/386752/fixing-corrupt-backup-gpt-table/386802#386802
Yvain avatar
lá cờ us
@nfs, bạn phải khởi động phương tiện trực tiếp và sử dụng fdisk trên ổ đĩa để khôi phục, thêm bảng phân vùng gpt hoặc mbr (phải giống với bảng bạn đã có trước đó) và giữ chữ ký phân vùng (sẽ có lời nhắc). Sau đó khởi động lại usb trực tiếp nhưng nhấn 'c' trên menu khởi động.
Yvain avatar
lá cờ us
Sử dụng cmdline grub để khởi động hệ thống với efi bị hỏng, sau khi sử dụng 'grub-install --efi-directory /boot/efi. Bạn có thể phải định dạng phân vùng efi trong fat32 trước. Chúc may mắn
lá cờ br
nfs
@Yvain cảm ơn bạn đã hướng dẫn.
lá cờ br
nfs
@oldfred tôi nên tiếp tục với testdisk như thế nào.Trước tiên tôi có nên khôi phục các tệp nếu có thể sau đó lưu bảng phân vùng không? Hoặc có thể khôi phục tệp mà không cần sửa bảng phân vùng không?
oldfred avatar
lá cờ cn
Tôi chưa phải sử dụng testdisk. Nhưng nếu tìm kiếm sâu hơn sẽ thấy các tệp, hãy sao lưu chúng. Một số đã nhìn thấy chúng và sau đó không thể khôi phục và mọi thứ đã biến mất. Nếu cuối cùng bạn phải sử dụng photorec, bạn sẽ không nhận được tên tệp đầy đủ, chỉ có phần mở rộng. Phải mất mãi mãi vì nó chỉ quét toàn bộ ổ đĩa để tìm bất kỳ thứ gì trông giống như một tệp. Việc so sánh & tìm kiếm để xem các tệp có thể mất nhiều ngày để xác định tên tệp. Ảnh có thông tin ngày nội bộ mà bạn có thể sử dụng để đổi tên.
lá cờ br
nfs
@oldfred Tôi vừa thử testdisk. Với tùy chọn "tìm kiếm nhanh", tôi có thể truy cập các tệp của mình. Tôi chưa sao lưu. Tôi đã thêm **log_file** và ```hình ảnh``` vào cuối bài đăng của mình. Có vẻ như tôi có thể đảo ngược tình thế nhưng tôi không thể hiểu được thỏa thuận là gì, thiếu thông tin gì. Bên cạnh vấn đề, còn có một tùy chọn để chụp ảnh đĩa trong testdisk. Tôi có nên sử dụng nó không? Tôi đã kiểm tra tài liệu của nó. Nó sử dụng lệnh dd.
oldfred avatar
lá cờ cn
Bạn đã sao lưu các tập tin trong khi bạn có thể? Hầu hết các đề xuất sao chép hình ảnh của một ổ đĩa luôn là sự lựa chọn an toàn nhất & sau đó chỉ hoạt động trên hình ảnh, vì vậy nếu chọn sai hoặc lỗi, bạn vẫn có bản gốc. Có vẻ như testdisk đang tìm phân vùng bắt đầu từ 0? Và đó sẽ là một sai lầm. Sao lưu tệp trước, nếu có thể như đã đề xuất trước đó.
lá cờ br
nfs
@oldfred Tôi không thể hiểu rõ chủ đề về lỗi và lựa chọn sai. --- Nhưng tôi sẽ cố gắng giải thích. Tôi có một giả thuyết. Khi tôi xóa EFI(sda1) 500 mb đầu tiên của SSD đã bị xóa. Đúng là tôi ghi đè lên phân vùng EFI(sda1). Nhưng lý do tại sao gparted phát hiện chính xác có lẽ là do phân vùng EFI vẫn được gắn cờ là boot và đặc biệt và nó có một bảng phân vùng. Tôi tin rằng nếu tôi tìm kiếm sâu, tôi có thể mang phân vùng EFI trở lại (phiên bản ghi đè).
lá cờ br
nfs
@oldfred Tôi cảm ơn bạn đã đưa ra tình huống dự phòng. Tôi có một mối quan tâm lớn về sao lưu do tôi thiếu kiến ​​thức trong lĩnh vực này.Nếu tôi (chính xác) sao lưu SSD vào ổ đĩa ngoài, liệu có khả năng tôi sẽ không thể tìm lại các tệp trong SSD không? ---
oldfred avatar
lá cờ cn
Tôi nghĩ testdisk đã đưa ra lựa chọn dự phòng. Mặc dù testdisk thường hoạt động, nhưng chúng tôi đã thấy trường hợp người dùng mất tất cả. Sau đó, không chắc chắn nếu lỗi người dùng hoặc dữ liệu không thể phục hồi được. Sao lưu dữ liệu quan trọng và thậm chí ít quan trọng hơn luôn là điều đầu tiên bạn nên làm cho dù sử dụng Linux hay Windows.
lá cờ br
nfs
Xin chào @oldfred, tôi đã quản lý để lưu phân vùng bằng testdisk. trước đó tôi đã lấy một ddimage của đĩa và một bản sao của bản sao. Tôi đã mặc trên bản sao cuối cùng. Cảm ơn bạn rất nhiều vì sự giúp đỡ và giải thích của bạn. - Tôi vẫn chưa lưu ssd hoàn toàn. Tôi đang cố gắng tìm hiểu lý do tại sao một số ngày tạo hệ thống tệp lại sớm hơn ngày chính thức. Tôi đã thêm hình ảnh của nó vào cuối bài đăng nếu bạn muốn kiểm tra nó.
oldfred avatar
lá cờ cn
Các thư mục hệ thống thường có ngày ISO được tạo hoặc phát hành. Tôi sẽ không lo lắng về bất kỳ tệp hoặc thư mục hệ thống nào trừ khi bạn sửa đổi cài đặt hệ thống trong/etc (tôi thay đổi grub nhưng sao chép vào/home để sao lưu thông thường bao gồm điều đó). Tôi sẽ đi sâu vào /home/nfs ? và tìm kiếm bất kỳ tệp nào của bạn, kể cả các tệp ẩn có thể là các cài đặt bạn đã thực hiện và tất cả các tệp dữ liệu của bạn. Bạn có thể không nên sử dụng nfs làm tên người dùng trong hệ thống, nếu bạn đã làm như vậy. Đó cũng là một ứng dụng.
lá cờ br
nfs
@oldfred cảm ơn bạn. Như bạn đã nói, đây có thể là ngày tạo ISO. Cuối cùng tôi đã tìm ra nó với sự giúp đỡ của bạn và khôi phục dữ liệu của tôi. Cảm ơn rất nhiều. Tôi sẽ cập nhật bài viết. -- Bây giờ, tôi đã quay trở lại nơi tôi bắt đầu. Tôi có thể thấy phân vùng ext của mình. nhưng nó hơi khác một chút. trên sda2(ext4) gparted không nói mnt/boot/... và khu vực 2048 đầu tiên được bao gồm trong phần EFI 513 mb. Tôi có nên mở một câu hỏi mới hay tiếp tục từ đây?
oldfred avatar
lá cờ cn
Không chắc liệu bạn có phải cài đặt lại hoàn toàn hay có thể tạo phân vùng hệ thống ESP - efi mới dưới dạng FAT32 và chỉ cần cài đặt lại hoàn toàn grub bằng Boot-Repair hoặc chroot. Nếu cài đặt grub không hoạt động thì bạn cần cài đặt mới. Bạn có thể thực hiện cài đặt "bẩn" khi bạn không định dạng phân vùng. Mọi tệp bạn đã chỉnh sửa trong quá trình cài đặt sẽ bị ghi đè, nhưng nếu không được định dạng, dữ liệu của bạn trên ổ đĩa sẽ vẫn ở đó. Bạn vẫn cần khôi phục /home cho cài đặt của mình. https://help.ubuntu.com/community/Boot-Repair & https://sourceforge.net/p/boot-repair/home/Home/
lá cờ br
nfs
@oldfred cảm ơn vì tất cả sự giúp đỡ của bạn. Nó vô cùng hữu ích.
Điểm:2
lá cờ mx

Tôi đã viết tệp win10.iso bên trong Phân vùng hệ thống EFI của nó bằng lệnh dd.

Bước này làm hỏng dữ liệu trên đĩa. Trong phân vùng có hiệu lực sụp đổ. Bạn có thể thử phần mềm khôi phục như testdisk, nhưng dữ liệu của bạn có thể không khôi phục được.

Để được an toàn, không sử dụng đ.

lá cờ br
nfs
Tôi đã xóa Phân vùng hệ thống EFI nhưng các phân vùng đã bị sập sau khi tôi ngắt kết nối ext4. Trước đây thì không sao và có thể truy cập được. @pasman
pasman pasmański avatar
lá cờ mx
Có thể truy cập phân vùng vì dữ liệu hệ thống chính xác nằm trong bộ nhớ. Trên đĩa nó đã bị hỏng rồi.
lá cờ br
nfs
Tôi đã cố gắng khởi động lại. Không phải vì EFI bị hỏng. Sau đó, tôi đã khởi động từ usb. Tất cả họ đều ở đó. Sau đó, tôi đã xóa EFI và ngắt kết nối ext4 (ubuntu).

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