Linux Mint Forums
Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.
Can’t launch Linux Mint, «Read Error»
Post by sashkello » Wed Jan 20, 2016 1:32 am
Sorry for unloading this personal problem in here, but I’m getting a bit desperate with this.
I’ve got an Acer Aspire S3 laptop and have just replaced the hard drive (upgrading it from 250 to 500 Gb, it was failing and old as well).
After this, I, as usual, made a bootable USB with Linux Mint (17.3 this time), and proceeded to install it with no troubles whatsoever. However, after installation went through, and I rebooted, it didn’t even start booting any OS, all I see is a black screen with «Read Error». Sometimes (seems random), it shows
Now, a few things which I have checked:
1. I tried to reinstall Linux Mint several times, trying to make manual partitions, to no noticeable effect.
2. I can see the new hard drive in BIOS.
3. When I boot from USB, I can see my partitions in GParted as well as the standard linux file structure. So, it looks like Mint IS there on the drive.
4. I have tried Boot Repair, both Recommended Repair and a few other options in Advanced, to no success.
5. I have tried reinstalling GRUB2 as described here, again, without any result.
UPDATE:
6. Tried to go through grub-rescue as described here, but get the same error («attempt to read or write outside of disk») on insmod command.
7. Tried to install some other distros, Linux Lite didn’t do anything new, but with Fedora I managed to get to the boot menu (somehow it works 50/50), and a couple of times it even went through to load OS itself, although most times it shows me «failure reading sector . from hd0», if it gets to boot menu at all («Read Error» is what I usually see).
8. Run
sudo badblocks -wsvf /dev/sdaWhat could be going on, how do I diagnose my problem further?
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 5 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Ubuntu после смены железа не загружается без USB-флешки
ssd-диск (установлена Ubuntu 14.04) нормально работал на ноутбуке. Я переставил его в десктопный компьютер, при загрузке получаю ошибк Loading operating Read Error и все.
После танцев с бубнами, boot-repair, grub-update и прочих рецептов (из-за моей глупости чуть не убивших загрузку совсем) случайно увидел, что если в USB воткнуть флешку (не обязательно загрузочную, а, например, с музыкой), то система стартует ок.
Что это, и как бы обойтись без флешки?
p.s. судя по BIOS, ssd воткнут в SCSI-0, пробовал втыкать в другие sata-разъемы, не помогло.
$ sudo dd bs=512 count=1 if=/dev/sda 2>/dev/null | strings ZRr= `|f \|f1 GRUB Geom Hard Disk Read Error 
Нет, попробуй просто выполнить команду выше, просто хотя бы чтобы проверить
думаю что это просто баг биоса.
Я должен это выполнить на уже загруженной с ssd системе или с загрузочной USB-флешки? Возможно, вопрос тупой, но не хочется снова убить загрузку, ибо не очень понимаю ее процесса.
Процесс такой: биос выбирает диск, который указан в сетапе, как загрузочный, читает с него первый сектор и выполняет. В первом секторе находится загрузчик GRUB, который читает с того же диска ядро GRUB и запускает его. Ядро GRUB считывает свой конфиг, подгружает нужные модули (которые не вкомпилены в ядро) и рисует менюшку с выбором системы, которую нужно загружать.
Можно предположить, что в твоем случае загрузчик GRUB пытается считывать ядро с неправильного диска (например, он может пытаться читать со второго диска, которого без флешки просто нет, а с флешкой им может оказаться как раз твой SSD). Но это, конечно, спекуляция, потому что нифига не понятно, что у тебя там происходит.
grub-install /dev/sdX (где sdX — это твой SSD диск, может оказаться на другой букве) записывает на диск загрузчик GRUB в первый сектор и ядро GRUB в свободное место перед первым разделом. В процессе может правильно настроить загрузчик, чтобы он читал ядро GRUB c правильного диска. Проще всего делать это из живой системы, подняв ее с флешкой.
из живой системы, подняв ее с флешкой
Уточню: нужно поднять систему с SSD, предварительно воткнув какую-нибудь флешку, и выполнять команду из нее.
Если не поможет, нужно больше инфы: в каком режиме у тебя загружается система (Legacy MBR или UEFI), как разбит диск и что рассказывает консолька GRUB по команде ls.
Что-то строка ″Loading operating Read Error″ не гуглится. Она пишется до загрузки grub’а или после?
Может на диске нет активного раздела, некоторым bios это не нравится.
mky ★★★★★ ( 11.10.16 20:07:21 MSK )
Последнее исправление: mky 11.10.16 20:07:45 MSK (всего исправлений: 1)
Мой ssd на sda, проверил в gparted. Сделал:
$ sudo grub-install /dev/sda Installing for i386-pc platform. Installation finished. No error reported. $ uname -a Linux ryasale-laptop 3.19.0-58-generic #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux 1. Тем не менее, перезагрузился. Результат: без флешки по-прежнему не загружается.
2. Снова пробую без флешки, держу Shift для перехода в Grub. Ошибка стала подробнее:
Loading Operating System . GRUB loadingRead Error. 3. Вставляю флешку, все ок, запускаю Grub-консоль
grub> ls (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1)
в каком режиме у тебя загружается система (Legacy MBR или UEFI)
Где бы это посмотреть? В биосе есть какой-то флажок EFI, переключал во все режимы, не влияет.
Бут-меню есть (F8, F11 или F12 обычно)?
Если в бут-меню уефи версия загрузки с харда?
Бут-меню есть, но в нем ничего похожего на uefi.
По ссылке на спецификацию http://www.gigabyte.com/products/product-page.aspx?pid=3947#bios увидел, что есть UEFI для моей мамки. А у меня обычный биос, версии F6.
Вопросы:
поставлю UEFI, поможет загружаться без флешки?
что он еще даст? Вкратце глянул что есть UEFI, вроде ничего интересного. Обновлять биос ради избавления от флешки — слишком геморно 🙂 Еще чего сломается.
Бывало у меня что-то подобное Посмотри, совпадают ли данные диска с данными фстаб’а и нет ли там чего лишнего.
Судя по мануалу, похоже, что мамка вообще не поддерживает UEFI. Так что тут все нормально.
Я глянул в код граба, если я правильно понимаю ситуацию, то сообщение «GRUB loadingRead Error» выводится, если первый кусок удалось прочитать, а второй — нет. При этом разница в чтении первого и второго куска в том, что если детектится поддержка LBA в биосе, то пробуется этот режим, но при ошибке при первом чтении происходит откат на CHS, а во втором не происходит. То есть выглядит так, что без флешки биос обещает поддержку LBA, но не дает ее, а с флешкой либо не обещает, либо обещает и таки дает. В общем, похоже на глюкодром в биосе.
Попробуй в биосе отключить EFI CD/DVD Boot Option, Second Boot Device и Third Boot Device и посмотри, как это повлияет на загрузку с флешкой/без флешки.
Если ничего не поможет, то можно попробовать пропатчить граб или обновить биос. Или воткнуть навсегда какую-нибудь старую флешку и смириться.
sudo parted -l cat /proc/self/mounts
$ sudo parted -l Model: ATA Samsung SSD 840 (scsi) Disk /dev/sda: 250GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 241GB 241GB primary ext4 boot 2 241GB 250GB 8938MB primary linux-swap(v1) Model: silicon-power (scsi) Disk /dev/sdb: 2005MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32,3kB 2005MB 2005MB primary fat32 boot $ cat /proc/self/mounts sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=8067360k,nr_inodes=2016840,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=1615608k,mode=755 0 0 /dev/sda1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0 none /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/kernel/security securityfs rw,relatime 0 0 none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0 none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0 none /sys/fs/pstore pstore rw,relatime 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpu 0 0 cgroup /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,relatime,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,blkio 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/net_prio cgroup rw,relatime,net_prio 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,relatime,hugetlb 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0 systemd /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,name=systemd 0 0 /dev/sda1 /var/lib/docker/aufs ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
Кстати, а конфиг grub со времени переезда с ноута не менялся?
Если посмотреть в cat /boot/grub/grub.cfg | grep «set root» , то совпадает ли диск и раздел с текущим системным (тем, что выдаётся по команде ls в консоле grub?
$ cat /boot/grub/grub.cfg | grep "set root" set root='hd0,msdos1' set root='hd0,msdos1' set root='hd0,msdos1' set root='hd0,msdos1' set root='hd0,msdos1' set root='hd0,msdos1'
Все это проверили же уже. Граб успешно считывает второй загрузчик (т.е. проблема не в конфигурации загрузчика), но потом фейлится считать ядро (т.е. проблема не дальше загрузчика граба и к grub.cfg отношения не имеет). Судя по всему, глюкодром в биосе, в котором в зависимости от присутствия или отсутствия USB устройства по разному себя ведет int 13h (Ubuntu после смены железа не загружается без USB-флешки (комментарий)).
Следующий логический шаг — добавить в бутлоадер ГРАБа чуть больше логов и попытаться понять, что там происходит. Или можно на удачу в grub-core/boot/i386/pc/diskboot.S исправить
movb $0x42, %ah int $0x13 jc LOCAL(read_error) movb $0x42, %ah int $0x13 jc LOCAL(chs_mode) Вполне может быть, что это решит проблему. В любом случае, сейчас это место в коде выглядит как баг (если сравнивать с boot.S).
Попробуй в биосе отключить EFI CD/DVD Boot Option, Second Boot Device и Third Boot Device и посмотри, как это повлияет на загрузку с флешкой/без флешки.
Рискнул пойти на кардианальное решение — прошил биос на UEFI, теперь и без флешки загружается.
Спасибо большое всем за советы, а ddos3 еще большее спасибо за разъяснения!
How to Fix the Read-Error on Swap-Device Failure in Ubuntu Linux
The Read-error on Swap-device error occurs when your Ubuntu system is low on swap memory. Here’s how you can fix the issue.
Readers like you help support MUO. When you make a purchase using links on our site, we may earn an affiliate commission. Read More.
The Linux operating system is one of the most stable and secure desktop and server operating systems, no wonder that it is the go-to operating system for most servers.
System administrators and engineers love Linux for its stability and performance, but occasionally Linux too experiences performance hiccups.
The «read-error on swap-device» is a relatively common failure on Linux that can cause your system to crash or be non-responsive rendering it unusable. This guide will show you how to fix the read-error on swap-device failure on Ubuntu Linux.
Why Use a Swap File?
A swap file can be a physical storage medium such as a USB drive, a file on a hard drive, or a dedicated partition on a storage medium.
Swap files play an important role because they act as a supplementary medium to the physical RAM on your PC. When you are running memory-intensive processes and your RAM runs out of storage, Linux will use the swap file to run the other applications or store variable data.
Starting with Ubuntu Linux 18.04, the swap area is by default a swap file, prior to that the swap area used to be a dedicated swap partition.
Common Causes of the Read-Error on Swap-Device Failure
Some of the most common causes of failures on swap devices or files include the following:
- Very low RAM on your PC: When you have very low memory left on your system, then most applications will forcibly store variable data in a swap file. Unfortunately reading data from a swap file is much slower than reading from RAM.
- Low swap device storage: Problems will occur if you have a very small swap file with a lot of data stored as variable data, which in turn will lead to low performance of the system.