Содержание
- Arch Linux
- #1 2014-06-04 01:10:11
- EXT4-fs error on boot? [resolved, I hope]
- Стали появляться проблемы с диском.
- Ext4 fs error device sda3
Arch Linux
You are not logged in.
#1 2014-06-04 01:10:11
EXT4-fs error on boot? [resolved, I hope]
On boot, after everything is done except the login prompt I get:
Welcome to emergency mode! After logging in, type «journalctl -xb» to view system logs, «systemctl reboot» to reboot, «systemctl default» to try again to boot into default mode.
Give root password for maintenance
(or type Control-D to continue)
If I «Crontol-D» and login, then «journalctl -xb» at the end is:
EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2947, 29365 clusters in bitmap, 29809 in gd; block bitmap corrupt.
Jun 03 19:30:01 Dell15z kernel: JBD2: Spotted dirty metadata buffer (dev = sda3, blocknr = 0). There’s a risk of filesystem corruption in case of system crash.
Jun 03 19:30:01 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2944, 23842 clusters in bitmap, 23846 in gd; block bitmap corrupt.
Jun 03 19:30:02 Dell15z kernel: JBD2: Spotted dirty metadata buffer (dev = sda3, blocknr = 0). There’s a risk of filesystem corruption in case of system crash.
Jun 03 19:30:26 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 3089, 16946 clusters in bitmap, 16951 in gd; block bitmap corrupt.
Jun 03 19:30:43 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2984, 22332 clusters in bitmap, 25470 in gd; block bitmap corrupt.
Jun 03 19:30:44 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2985, 24156 clusters in bitmap, 27958 in gd; block bitmap corrupt.
Jun 03 19:30:45 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2986, 29338 clusters in bitmap, 31572 in gd; block bitmap corrupt.
Jun 03 19:30:46 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2987, 18034 clusters in bitmap, 32744 in gd; block bitmap corrupt.
Jun 03 19:30:46 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2988, 24812 clusters in bitmap, 32715 in gd; block bitmap corrupt.
Jun 03 19:30:47 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2989, 17353 clusters in bitmap, 32767 in gd; block bitmap corrupt.
Jun 03 19:30:48 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2990, 31758 clusters in bitmap, 32528 in gd; block bitmap corrupt.
Jun 03 19:30:49 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2991, 32493 clusters in bitmap, 32749 in gd; block bitmap corrupt.
Does this mean my hard drive is FUBAR?
Is there something I should run to fix this?
The only things I can find that relate to this are bugs and patches to the kernel.
Last edited by jfb3 (2014-06-05 01:36:49)
Источник
Стали появляться проблемы с диском.
Уже второй раз (первый был несколько дней назад) возникают ошибки ФС и диск перемонтируется в ро:
Сам я в этом смарте ничерта не понимаю:
После перезагрузки система не грузится и просит fsck. После проверки начинает работать нормально.
UPD: Проблема проявляется на всех ядрах от 4.15 до 4.19 включительно.
Пока всегда только с диском /dev/sda2 (но он и используется интенсивнее). На данный момент диски смонтированы так:
Сервис Lenovo с помощью встроенного тестировния выявил неисправность планки RAM, которую надо сказать к чести Lenovo заменили в течении недели у меня на дому и мне даже не пришлось никуда ехать.
Тест железа встроенный прогнал 4 раза — никаких ошибок ниразу не вылезло. Следующим этапом по совету сервисника обновил BIOS (была и правда очень старая версия). Потом скачал SanDisk Dashboard и проверил диск им (пришлось венду на флэшку ради этого вкорячить), в том числе расширенное тестирование SMART. Прошивка диска последняя.
UPD:
С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее — источником проблем стала оперативная память, что привело к повреждению данных записываемых на диск, а это в свою очередь повлекло все остальные последствия. Считаю что сервис Lenovo отработал оперативно — от момента обращение в чат, на сайте производителя, до замены планки памяти прошло 6 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать — специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.
Источник
Ext4 fs error device sda3
Does anyone know what this means?
| Код: |
| [ 305.274910] EXT4-fs (sda3): error count: 1 [ 305.274916] EXT4-fs (sda3): initial error at 1300215660: htree_dirblock_to_tree:586: inode 5382874: block 21504551 [ 305.274924] EXT4-fs (sda3): last error at 1300215660: htree_dirblock_to_tree:586: inode 5382874: block 21504551 |
fsck reports no problems and the system runs fine, but this shows up in dmesg after every first emerge action performed since boot (though that may be a coincidence).
The disk is brand new (
4 months old), but I have had some issues with it in the past (which my IT guy assures me were all my own fault and not a hardware problem).
Thanks for any insights Вернуться к началу
Bones McCracker
Veteran
Зарегистрирован: 14 мар 2006
Сообщений: 1611
Откуда: U.S.A.
| Добавлено: вс мар 20, 2011 10:36 am Заголовок сообщения: | ||||
| I would assume it is some kind of filesystem corruption.
Disclaimer: this may be wrong, or even stupid, but it’s probably the next thing I’d do. 1. Figure out what file it is. You can use ‘find -inum’ to get the filename of whatever is using inode 5382874 First, cd to the filesystem root of the ext4 filesystem in question (i.e., the filesystem’s mount point)
That should tell you the filename of whatever is using the offending inode. 2. Figure out what the file is. You can check to see what package (if any) owns it by doing: (qfile is part of portage-utils) 2. Figure out how to get rid of the corrupt inode. Probably just delete the file. 3. Check the filesystem for bad blocks: 4. Restore the file if possible (e.g., if it was part of a package, re-emerge the package).
|
Вернуться к началу
Aquous
l33t
Зарегистрирован: 08 янв 2011
Сообщений: 700
| Добавлено: вс мар 20, 2011 10:57 am Заголовок сообщения: | ||||
How very interesting.
It’s very interesting because quite a while ago my system was shutdown uncleanly (through a fault of my own) and after that fsck reported two lost files; one of which had the very contents of an OpenGL header file. There’s also this:
So basically my filesystem is slightly messed up in a way fsck can’t detect. I did rm -rf /usr/lib64/python2.6/site-packages/pygame/tests /usr/lib64/opengl/global/include and am now re-emerging pygame and eselect-opengl. Should I reformat/reinstall (it’s not that big of a hassle to me) just to be safe? Edit2: scratch the above, e2fsck found & repaired the deleted inodes and pygame managed to re-emerge cleanly. So my problems appear to have been solved. Thanks BoneKracker! |
Вернуться к началу
Bones McCracker
Veteran
Зарегистрирован: 14 мар 2006
Сообщений: 1611
Откуда: U.S.A.
| Добавлено: пн мар 21, 2011 12:29 am Заголовок сообщения: | ||
| Glad it worked. _________________
|
Вернуться к началу
Aquous
l33t
Зарегистрирован: 08 янв 2011
Сообщений: 700
| Добавлено: пн мар 21, 2011 7:52 am Заголовок сообщения: | ||
It looks like I spoke too soon
Inode 5382874 is nowhere to be found, inode 5509391 belongs to /usr/lib64/python2.6/site-packages/pygame/tests 993867 inodes used (15.17%) 938809 regular files (got the log by mounting a ramdisk, init 1, e2fsck -vfp | tee /mnt(ramdisk is here)/log, init 3, copy over log)) Time to reinstall? |
Вернуться к началу
Bones McCracker
Veteran
Зарегистрирован: 14 мар 2006
Сообщений: 1611
Откуда: U.S.A.
| Добавлено: пн мар 21, 2011 12:59 pm Заголовок сообщения: | ||
| That sucks. If it were me, yeah, that’s probably what I’d do.
Also before installing, I would do some low-level disk maintenance.
|
Вернуться к началу
Aquous
l33t
Зарегистрирован: 08 янв 2011
Сообщений: 700
| Добавлено: пн мар 21, 2011 2:46 pm Заголовок сообщения: | ||
| Yep, it’s a shame. I’m building a stage4 from the (awesome) Gentoo live dvd as we speak though
What do you mean by low-level disk maintenance? Just this?:
Or do you mean to reinitialize the partition table? (as my IT guy told me to when I experienced random «disk errors» after I had switched from 32 bit Windows 7 to 64 bit) Note: after my IT guy told me to wipe the partition table I did a low level format using the official tool from my drive manufacturer, and it reported no errors (which backed up my IT guy’s story about my drive being «confused» by the switch from 32 bit to 64 bit). So I should not have any bad blocks. Right? (I know you’re (probably) not a HDD guru, but you seem to know your stuff, so I figured I might as well ask) |
Вернуться к началу
Aquous
l33t
Зарегистрирован: 08 янв 2011
Сообщений: 700
| Добавлено: пн мар 21, 2011 6:06 pm Заголовок сообщения: | |
| Well, it looks like my system will live to see another day.
I managed to successfully do the stage4 backup & restore and all seems well (though I did have some random consolekit+dbus failure, which I fixed by re-emerging both those packages). Thanks, BoneKracker, for your guidance, you’ve taught me a lot over these two days |
Вернуться к началу
Bones McCracker
Veteran
Зарегистрирован: 14 мар 2006
Сообщений: 1611
Откуда: U.S.A.
| Добавлено: пн мар 21, 2011 10:01 pm Заголовок сообщения: | ||||||
Yes, I meant checking the disk with tools from the manufacturer, reinitializing the partition table, repartitioning, creating new filesystems, and so on. If the tools from the drive manufacturer are saying the drive is in pristine condition, I would not worry about bad blocks. You may never know what caused it. Maybe it was a solar flare or a manifestation of the coming Galactic Alignment of 2012. You might want to make a point of backing up important data if you were not already doing so.
|
Вернуться к началу
The Doctor
Moderator
Зарегистрирован: 27 июл 2010
Сообщений: 2677
| Добавлено: пн мар 21, 2011 10:14 pm Заголовок сообщения: | |
| When creating a new file system, I like to use the mkfs.ext4 -c -c option. This takes a while, but at least the disk gets checked for bad sectors. THIS WILL OVERWRITE ALL DATA WITH TEST PATTERS, SO USE WITH APPROPRIATE CARE _________________ First things first, but not necessarily in that order. Apologies if I take a while to respond. I’m currently working on the dematerialization circuit for my blue box. |
Вернуться к началу
Bones McCracker
Veteran
Зарегистрирован: 14 мар 2006
Сообщений: 1611
Откуда: U.S.A.
| Добавлено: пн мар 21, 2011 10:27 pm Заголовок сообщения: | ||
| Normally I would say, «Don’t listen to penguin swordmaster», but there’s probably no harm in doing this, even though it will take a long time. _________________
|
Вернуться к началу
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Copyright 2001-2023 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy
Источник
Adblock
detector
#1 2014-06-04 01:10:11
- jfb3
- Member
- Registered: 2011-08-20
- Posts: 68
EXT4-fs error on boot? [resolved, I hope]
On boot, after everything is done except the login prompt I get:
Welcome to emergency mode! After logging in, type «journalctl -xb» to view system logs, «systemctl reboot» to reboot, «systemctl default» to try again to boot into default mode.
Give root password for maintenance
(or type Control-D to continue)
If I «Crontol-D» and login, then «journalctl -xb» at the end is:
EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2947, 29365 clusters in bitmap, 29809 in gd; block bitmap corrupt.
Jun 03 19:30:01 Dell15z kernel: JBD2: Spotted dirty metadata buffer (dev = sda3, blocknr = 0). There’s a risk of filesystem corruption in case of system crash.
Jun 03 19:30:01 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2944, 23842 clusters in bitmap, 23846 in gd; block bitmap corrupt.
Jun 03 19:30:02 Dell15z kernel: JBD2: Spotted dirty metadata buffer (dev = sda3, blocknr = 0). There’s a risk of filesystem corruption in case of system crash.
Jun 03 19:30:26 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 3089, 16946 clusters in bitmap, 16951 in gd; block bitmap corrupt.
Jun 03 19:30:43 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2984, 22332 clusters in bitmap, 25470 in gd; block bitmap corrupt.
Jun 03 19:30:44 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2985, 24156 clusters in bitmap, 27958 in gd; block bitmap corrupt.
Jun 03 19:30:45 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2986, 29338 clusters in bitmap, 31572 in gd; block bitmap corrupt.
Jun 03 19:30:46 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2987, 18034 clusters in bitmap, 32744 in gd; block bitmap corrupt.
Jun 03 19:30:46 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2988, 24812 clusters in bitmap, 32715 in gd; block bitmap corrupt.
Jun 03 19:30:47 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2989, 17353 clusters in bitmap, 32767 in gd; block bitmap corrupt.
Jun 03 19:30:48 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2990, 31758 clusters in bitmap, 32528 in gd; block bitmap corrupt.
Jun 03 19:30:49 Dell15z kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:756: group 2991, 32493 clusters in bitmap, 32749 in gd; block bitmap corrupt.
Does this mean my hard drive is FUBAR?
Is there something I should run to fix this?
The only things I can find that relate to this are bugs and patches to the kernel…
Last edited by jfb3 (2014-06-05 01:36:49)
#2 2014-06-04 01:37:01
- ooo
- Member
- Registered: 2013-04-10
- Posts: 1,637
Re: EXT4-fs error on boot? [resolved, I hope]
did you try fsck.ext4?
#3 2014-06-04 03:09:50
- Pse
- Member
- Registered: 2008-03-15
- Posts: 413
Re: EXT4-fs error on boot? [resolved, I hope]
If this happened after no crash or warning, I’d be taking out that drive and imaging it as soon as possible. Once you have an image in a safe place, I’d format it and run some tests on it (beginning with SMART self tests).
#4 2014-06-04 09:50:07
- sekret
- Member
- Registered: 2013-07-22
- Posts: 258
Re: EXT4-fs error on boot? [resolved, I hope]
After the kernel update to 3.14.5 I couldn’t boot, because my boot device — formatted with ext2, but run by the ext4 driver — couldn’t be mounted. I then used my second kernel (realtime- and obviously my backup-kernel) which went fine. The next time I tried to use the default Arch kernel the boot went smoothly as always.
So this COULD be temporary. I don’t know what happened here this one time, but it’s possible that it was the same you experienced.
#5 2014-06-05 01:35:58
- jfb3
- Member
- Registered: 2011-08-20
- Posts: 68
Re: EXT4-fs error on boot? [resolved, I hope]
I went ahead and fsck’d /dev/sda3 and let it do whatever it wanted. It comes up clean and there is no «lost+found» so I guess it’s ok. I’m going to assume it got confused when it ran out of battery when suspended. (I had the flu and didn’t use my laptop for a few days.)
I’m always leery of letting fsck «fix» things because it doesn’t tell you what it’s fixing. Oh, it mentions node numbers and block numbers and such but it sure would help if it associated those to file/directory names.
#6 2014-06-05 01:43:46
- WonderWoofy
- Member
- From: Los Gatos, CA
- Registered: 2012-05-19
- Posts: 8,414
Re: EXT4-fs error on boot? [resolved, I hope]
It would probably be a good idea to use the fsck hook in your initramfs. Either that or remove the ‘rw’ from the kernel command line. That way you’ll at least get consistency checks during boot.
Уже второй раз (первый был несколько дней назад) возникают ошибки ФС и диск перемонтируется в ро:
[ 6974.205725] EXT4-fs error (device sda2): ext4_iget:4761: inode #7699735: comm TaskSchedulerFo: bad extra_isize 65535 (inode size 256)
[ 6974.210925] Aborting journal on device sda2-8.
[ 6974.213421] EXT4-fs (sda2): Remounting filesystem read-only
[ 6974.214980] EXT4-fs error (device sda2): ext4_journal_check_start:61: Detected aborted journal
[ 6995.041017] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041254] systemd-journald[281]: Failed to write entry (26 items, 835 bytes), ignoring: Read-only file system
[ 6995.041313] systemd-journald[281]: Failed to write entry (26 items, 1059 bytes), ignoring: Read-only file system
[ 6995.041364] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041599] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041652] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041715] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file systemДиск:
> sudo hdparm -i /dev/sda
[sudo] пароль для alex:
/dev/sda:
Model=SanDisk SD8TB8U256G1001, FwRev=X4120101, SerialNo=170617804405
Config={ }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=off
(maybe): CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=500118192
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
* signifies the current active modeСам я в этом смарте ничерта не понимаю:
> sudo smartctl -A /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-39-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 4
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0032 100 100 --- Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 --- Old_age Always - 4435
12 Power_Cycle_Count 0x0032 100 100 --- Old_age Always - 460
170 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 0
171 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 0
172 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 0
173 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 7
174 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 96
178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 --- Old_age Always - 0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0033 100 100 010 Pre-fail Always - 100
184 End-to-End_Error 0x0033 100 100 097 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 --- Old_age Always - 0
194 Temperature_Celsius 0x0022 067 048 --- Old_age Always - 33 (Min/Max 13/48)
199 UDMA_CRC_Error_Count 0x0032 100 100 --- Old_age Always - 0
233 Media_Wearout_Indicator 0x0033 098 100 001 Pre-fail Always - 16278028
234 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 4297
241 Total_LBAs_Written 0x0030 253 253 --- Old_age Offline - 3367
242 Total_LBAs_Read 0x0030 253 253 --- Old_age Offline - 5468
249 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 1973
Вот что это за End-to-End_Error? 97 это плохо да? Это может быть следствием проблем со шлейфом или это однозначно сам диск?
После перезагрузки система не грузится и просит fsck. После проверки начинает работать нормально.
UPD:
Проблема проявляется на всех ядрах от 4.15 до 4.19 включительно.
Пока всегда только с диском /dev/sda2 (но он и используется интенсивнее). На данный момент диски смонтированы так:
UUID=27652258-937c-4be5-b12b-83ade6d5ff80 / ext4 errors=remount-ro,discard,commit=60 0 1
UUID=f1e0b59c-9f19-427c-acb2-f3f45d2eca55 /home/alex/misc ext4 errors=remount-ro,noatime,discard 0 1
UUID=5667-4C56 /boot/efi vfat umask=0077 0 1
/home/alex/misc/swapfile none swap sw 0 0
tmpfs /tmp tmpfs rw,noatime,nosuid,mode=01777,size=2g 0 0
tmpfs /var/tmp tmpfs rw,size=1g 0 0
tmpfs /var/cache/apt/archives tmpfs rw,noatime,nosuid,size=1g 0 0
commit на /dev/sda2 и перенос swapfile на /dev/sda3 сделал недавно с целью увеличить интенсивность его использования и попробовадь получить ошибку на нем, чтобы убедится, что проблема свойственно железу или непосредственно дику, а не конкретному разделу.
Сервис Lenovo с помощью встроенного тестировния выявил неисправность планки RAM, которую надо сказать к чести Lenovo заменили в течении недели у меня на дому и мне даже не пришлось никуда ехать.
Тест железа встроенный прогнал 4 раза — никаких ошибок ниразу не вылезло. Следующим этапом по совету сервисника обновил BIOS (была и правда очень старая версия). Потом скачал SanDisk Dashboard и проверил диск им (пришлось венду на флэшку ради этого вкорячить), в том числе расширенное тестирование SMART. Прошивка диска последняя.
Проблема сохраняется.
UPD:
С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее — источником проблем стала оперативная память, что привело к повреждению данных записываемых на диск, а это в свою очередь повлекло все остальные последствия. Считаю что сервис Lenovo отработал оперативно — от момента обращение в чат, на сайте производителя, до замены планки памяти прошло 6 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать — специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.
| View previous topic :: View next topic | |||||||||
| Author | Message | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Nicias Guru 
Joined: 06 Dec 2005 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
| Jaglover Watchman  
Joined: 29 May 2005 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
| Nicias Guru
Joined: 06 Dec 2005 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
| Jaglover Watchman
Joined: 29 May 2005 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
| Nicias Guru
Joined: 06 Dec 2005 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
| Hu Moderator
Joined: 06 Mar 2007 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
| Nicias Guru
Joined: 06 Dec 2005 |
|
||||||||
| Back to top |
|
||||||||
|
|||||||||
|
|
You cannot post new topics in this forum |
- Печать
Страницы: [1] Вниз
Тема: ext4-fs error device sda1 (Прочитано 6868 раз)
0 Пользователей и 1 Гость просматривают эту тему.
CRY_WOLF
делал постоянно полные обновление системы раз в неделю….
В прошлый понедельник обновил сам дистрибутив с 10.04 до 10.10 с этого момента и пошли глюки… То система начинала жутка тормозить, и помогал только рестарт. То апплет уведомлений вылетает. То евалушен отказывается запускаться и прочие подобные пакости. В четверг прошлый ушёл после работы домой запустил трасмишен и всё. Были помимо него запущен аська клиент скайп эвалушен опера и фазила… Сегодня утром комп стоит завишый мышка вообще не двигается…. начел делать рестарт вроде комп загрузился но после ввода пароля нечего не происходила только мышка и фон с логин скрина. Сделал ещё рестарт та же беда после чего попытался сделать репаир системы через груб и стал хард выкидывать
ext4-fs error device sda1 и ещё что то… полазив по просторам нета… нашёл у себя хард с кубунтой 8,04 запустился и с GParted сделал чек диск вот что он написал в отчёте (в приложении)
И за чего вся эта хрень случилась… А да с четверга 17 часов вечера до понедельника 09 комп вообще не трогал… GParted Не помог ((( Так и не грузится каие идеи есть как поднять систему??? Сделал лайв сд убунты там была в грубе опция проверить диск на наличие и исправление ошибок выбрал минут 30 крутил вертел диск в итоге написал
Check fineshed: no errors found
Press any key to reboo t your system
И теперь при загрузки выкидывается
BusyBox v1.13.3 (Ubuntu1:1.13.3-1ubuntu11) built in shell (ash)
Сейчас буду пробывать систему поверх установить чтоб оставшиеся данные забрать…
В разметки обнаружил очень интересное явление
диск 320гигов и по идеи должна быть только система 10.10 но у меня видна следующее
1) 277.4 — убунту 10.10
2) 40.4 — убунту 10.4
3) 2.3 — свап
Про 1 и 3 раздел всё понятно, Но от кудова взялся 2 раздел????
« Последнее редактирование: 17 Января 2011, 13:56:53 от CRY_WOLF »
Нам не нравятся те, кому не нравимся мы….
Рубит компы не линукс. Рубит компы винда…
Raven
1. Я бы исключил глюки железа:
а) оперативная память memtest (более на всякий случай)
б) не перегревается ли что-либо (то же на всякий пожарный)
в) жесткий диск на ошибки (mhdd) 1. без ремапа, 2. пройтись по адресам ошибок повторяются или нет. 3. если да проремапить
г) кабель sata к жесткому диску
По программной части: рекомендовал бы сохранить файлы загрузившись c Live-CD и переустановить 10.10 с чистого,
P.S. Сам использую 10.10 Ubuntu/Kubuntu все работает норм.
« Последнее редактирование: 17 Января 2011, 13:56:17 от Raven »
CRY_WOLF
1. Я бы исключил глюки железа:
а) оперативная память memtest (более на всякий случай)
б) не перегревается ли что-либо (то же на всякий пожарный)
в) жесткий диск на ошибки (mhdd) 1. без ремапа, 2. пройтись по адресам ошибок повторяются или нет. 3. если да проремапить
г) кабель sata к жесткому дискуПо программной части: рекомендовал бы сохранить файлы загрузившись c Live-CD и переустановить 10.10 с чистого,
P.S. Сам использую 10.10 Ubuntu/Kubuntu все работает норм.
б) не перегревается ли что-либо (то же на всякий пожарный)
Это мало веротно когда вскрыл корпус совсем не тепло было…. стоит дополнительный кулер…
а) оперативная память memtest (более на всякий случай)
Идеи такие были. Но тогда не понтен покрайне мере мне один момент если чиста логически рассуждать и предполагать что глючить память то как тогда могла загрузится без глюклв запустится Kubuntu с домашнего компа + потенуть все дрова…
в) жесткий диск на ошибки (mhdd) 1. без ремапа,
2. пройтись по адресам ошибок повторяются или нет. 3. если да проремапить (где пройтись и что сделать?)
г) кабель sata к жесткому диску (Ставил запосной и от сидюка всё бестолку…)
Нам не нравятся те, кому не нравимся мы….
Рубит компы не линукс. Рубит компы винда…
Raven
У меня была машина с битой на 30% памятью. Ubuntu при этом работала, но глючила и при копировании изменялся checksum файлов 
.
Проверку поверхности можно осуществить с помощью MHDD, который есть в сосотаве многих восстановительных дисков. Например System Rescue, Parted Magic, Ultimate Boot CD и т.д. Подойдет и Victoria, которую кладут на установочные диски с виндой, аля ZverCD.
Как использовать можно прочитать в Google 
« Последнее редактирование: 17 Января 2011, 14:18:04 от Raven »
CRY_WOLF
У меня была машина с битой на 30% памятью. Ubuntu при этом работала, но глючила и при копировании изменялся checksum файлов
Проверку поверхности можно осуществить с помощью MHDD, который есть в сосотаве многих восстановительных дисков. Например System Rescue, Parted Magic, Ultimate Boot CD и т.д. Подойдет и Victoria, которую кладут на установочные диски с виндой, аля ZverCD.
Как использовать можно прочитать в Google
ОК наночь погоню мемтест… А вот глюк этот с этим связон не может быть
Суть в следующем если тот же торент поставить на ночь качаться то на утра очень сильна глючить система порой проста только рестарт надо делать… А порой выйдешь из трансмишена и чере пару часов опять всё норм работает… Это на что подозрение? Памяти полюбому хватает там у него 2гига + 2,4гига свапа… на харде 75гигогв миним всегда держу свободное место. А да и до обновление на 10,10 бал только один выше упомянутый глюк с тормозами трасмишенам…
Пользователь решил продолжить мысль 17 Января 2011, 14:47:25:
только что установил на одельный хард систему с полного нуля работает без единой ошибки… запустился буквально за 25 сек…. а после устонвки выдал установлено и требуется рестарт компа нажил перегрузить и выкинул И-О чегота не заметил…. Устанавливал с флешки…..
« Последнее редактирование: 17 Января 2011, 14:47:25 от CRY_WOLF »
Нам не нравятся те, кому не нравимся мы….
Рубит компы не линукс. Рубит компы винда…
Raven
В целом мемтеста достаточно одного пасса.
Если все норм, то остается только установить с нуля и наблюдать.
- Печать
Страницы: [1] Вверх
What’s up with the «structure needs clearing» error message
The error «structure needs clearing» is the error which file systems (in particular ext4 and xfs) return when they have detected a file system corruption problem. Unfortunately, the only safe thing to do to repair the corruption is to unmount the disk and run e2fsck on the file system. (Technically, you won’t need the the -f option because the file system has already detected problems and has marked the file system as being in trouble. So when you run e2fsck it will do a full scan to fix those issues and you don’t need the -f option to force a check.)
Reports of file system corruption
You should also be able to see the reports of file system corruption by looking at the kernel logs. (e.g., by running dmesg, or looking at /var/log/kern.log or wherever your syslog or journald has been configured to log kernel messages. You should see messages that begin EXT4-fs error (device sdXX). For example:
EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136
You can also see indications of errors by looking at dumpe2fs -h on the file system. Fields of interest:
FS Error count: 25
This means that kernel has found file system inconsistencies 25 times.
First error time: Thu Jan 1 12:19:59 2015
First error function: ext4_ext_find_extent
First error line #: 400
First error inode #: 95223833
First error block #: 0
The first error was found on January 1, 2015, at the specified time. The error function and line # allows you to identify exactly which part of the kernel code found the problem. The inode # tells you which inode was involved with the file system inconsistency.
Last error time: Wed Feb 4 11:57:05 2015
Last error function: ext4_ext_find_extent
Last error line #: 400
Last error inode #: 95223833
Last error block #: 0
This tells you the most recent time the kernel found a file system inconsistency. The large deltas between the two times means that someone hasn’t been scanning their kernel messages. That’s because every 24 hours, ext4 will log warning messages that there is a file system with corruptions, and those kernel messages will look like this:
EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550
Note: the time is in the kernel messages are number of seconds since January 1, 1970 midnight UTC. You can convert this to a more human readable time using the date command, for example:
% date -d @1441536566
Sun Sep 6 06:49:26 EDT 2015
What to do when you become aware your file system is corrupt
You really don’t want to run with file system inconsistencies, since that can lead to more data loss. It’s really a good idea to jump on these reports, schedule downtime if necessary, and fix them ASAP.
Why did e2fsck complain the device was in use after I unmounted it?
Finally, in answer to your question: «I ran fsck after unmounting and I get the following error: /dev/sdb1 is in use. Any ideas?» That’s probably be cause you have one or more processes in an alternate mount namespace, and those processes still have /dev/sdb1 mounted in that mount name space. You might want to try:
grep /dev/sdb1 /proc/*/mounts
If you find processes running in an alternate mount namespace, the simplest thing to do is to kill and restart those processes. (They are probably daemon processes.) When the last process using a mount namespace exits, the mount name space goes away. And once there are no more mount namespaces that have /dev/sdb1 mounted, it will really be unmounted for real.
The way to think about this is that umount acts like unlink. If you have a file with multiple hardlinks, the space is only released when the last hard link is deleted. If you have multiple namespaces active, each namespace effectively acts as a «hard link» to the mount in question. So merely unmounting the file system in the default mount namespace won’t help if some process has forked the default mount namespace and is running itself and possibly some child processes in that copy-on-write copy of its parent mount namespace.
Here I am again. After I spent two days setting the CM board work, I found a fatal problem that I cannot solve it. After I setting the CM board up, flashing the OS in, every time I try to write something to the file system, such as sudo apt-get install something, it shows the EXT4-fs error. Just like the image below shows.
Code: Select all
EXT4-fs error (device mmcblk0p2) in ext4_reserve_inode_write:4862: Journal has aborted
E: Read error - read (5: Input/output/ error)
journal commit I/O error
EXT4-fs error (device mmcblk0p2) in ext4_dirty_inode:4981: Journal has aborted
EXT4-fs error (device mmcblk0p2) : ext4_journal_check_start:56: Detected aborted journal
EXT4-fs (mmcblk0p2): Remounting filesystem read-onlyAnd sometimes, when it boots up, the same problem comes up.
I have tried a few solutions I found in Google.
1. Flash other OS version into the CM board. Yes, I have flashed three image I download from http://downloads.raspberrypi.org/raspbian/images/ but each of them has the EXT4-fs error when I try to sudo apt-get install.
2. When the EXT4-fs error came up, I connect it to other pi and tried to fix it by fsck.
Code: Select all
pi@raspberrypi ~/tools/usbboot $ sudo fsck /dev/sda1
fsck from util-linux 2.20.1
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving file system unchanged.
/dev/sda1: 20 files, 1248/7161 clustersIt says that it found a dirty bit in sda1. Then I type
and it seems to had removed the dirty bit. Then I powered up the CM board and try install something, the same problem happened again.
3. Change the SD card. This is the most common solution I found on the forum. But obviously, I cannot change the eMMC on the CM board.
I really don’t know how to fix it. Could anyone help me?
Thanks to the help from ShiftPlusOne and rpdom!!! It is all about the power supply. I was going to connect the CM board to another pi for flashing the image, but I connect the line to power slug by error. And I thought, why not try to boot and install something? Then I try apt-get install, everything goes well!!! No more EXT4-fs error!!!!
Damed official power connector!!