Forced FSCK[solved]

fsck failed. Please repair manually and reboot. Please note that the root file system is currently mounted read-only.
To remount it read-write:
# mount -n -o remount,rw /
CONTROL-D will exit from this shell and REBOOT the system.
Getting the above error when booting into my new arch system, with ext3.

Read-only is normal for the boot sequence.
Fsck must complete its function of system check efore the boot will finish.
If you get a statement after fsck has completed its check, hit control d and let it reboot again.

Similar Messages

Force fsck on boot and timeout waiting for device issues [SOLVED]

Archlinux starts checking fs on every boot since linux and systemd packages were updated last night.
systemd --->213-5
linux ---->3.14.5-1
Another issue appears with last update
Timed out waiting for device dev-disk-by\x2duuid-9f780ada\x2d0671\
Dependency failed for /dev/disk/by-uuid/9f780ada-0671-43d8-b036-f9
Dependency failed for Swap.
I have this issue on my laptop which was updated yesterday.I have also desktop running archlinux again I've just checked out the systemd and linux versions.The systemd package is not the latest one it's 212-3.I havent any problem on that machine.I guess systemd is responsible of this cause.
I've just reboot and realized that systemd-fsck says Super block last write is in the future.Date and time is correct in BIOS same as on linux
Last edited by gecici90 (2014-06-05 21:10:52)

I had the same problem, I get in the recovery But downgrading systemd and systemd-sysvcompat The sorted list of the upgraded packages:
[2014-06-05 21:11] [PACMAN] installed libx264 [2014-06-05 21:11] [PACMAN] upgraded btrfs-progs [2014-06-05 21:11] [PACMAN] upgraded cifs-utils [2014-06-05 21:11] [PACMAN] upgraded imagemagick [2014-06-05 21:11] [PACMAN] upgraded filesystem [2014-06-05 21:11] [PACMAN] upgraded lib32-libdbus [2014-06-05 21:11] [PACMAN] upgraded libproxy [2014-06-05 21:11] [PACMAN] upgraded libpurple [2014-06-05 21:11] [PACMAN] upgraded libsystemd [2014-06-05 21:11] [PACMAN] upgraded libwbclient [2014-06-05 21:11] [PACMAN] upgraded openssl [2014-06-05 21:11] [PACMAN] upgraded perl [2014-06-05 21:11] [PACMAN] upgraded perl-xml-parser [2014-06-05 21:11] [PACMAN] upgraded perl-yaml-syck [2014-06-05 21:11] [PACMAN] upgraded pidgin [2014-06-05 21:11] [PACMAN] upgraded postgresql-libs [2014-06-05 21:11] [PACMAN] upgraded python2 [2014-06-05 21:11] [PACMAN] upgraded smbclient [2014-06-05 21:11] [PACMAN] upgraded subversion [2014-06-05 21:11] [PACMAN] upgraded systemd [2014-06-05 21:11] [PACMAN] upgraded [2014-06-05 21:11] [PACMAN] upgraded x264 [2014-06-05 21:11] [PACMAN] upgraded xchat [2014-06-05 21:11] [PACMAN] upgraded xfconf Downgrading systemd and systemd-sysvcompat [2014-06-05 21:43] [PACMAN] Running 'pacman [2014-06-05 21:43] [PACMAN] downgraded systemd [2014-06-05 21:43] [PACMAN] downgraded console after forced fsck.
to their previous version made it all work back again.
(1:142.20140311-4)
(3.14.1-1 -> 3.14.2-2)
(6.2-1 -> 6.3-1)
(6.8.9.1-2 -> 6.8.9.1-3)
(2013.05-2 -> 2014.05-2)
(1.8.0-1 -> 1.8.2-1)
(0.4.11-2 -> 0.4.11-3)
(2.10.9-1 -> 2.10.9-2)
(212-3 -> 213-5)
(4.1.7-1 -> 4.1.8-1)
(1.0.1.g-1 -> 1.0.1.h-1)
(5.18.2-2 -> 5.20.0-2)
(2.41-4 -> 2.41-5)
(1.27-1 -> 1.27-2)
(2.10.9-1 -> 2.10.9-2)
(9.3.4-1 -> 9.3.4-2)
(2.7.6-3 -> 2.7.7-1)
(4.1.7-1 -> 4.1.8-1)
(1.8.9-1 -> 1.8.9-2)
(212-3 -> 213-5)
systemd-sysvcompat (212-3 -> 213-5)
(1:142.20140311-1 -> 1:142.20140311-4)
(2.8.8-13 -> 2.8.8-14)
(4.10.0-3 -> 4.10.0-4)
makes my computer boots normally:
-U /var/cache/pacman/pkg/systemd-212-3-x86_64.pkg.tar.xz /var/cache/pacman/pkg/systemd-sysvcompat-212-3-x86_64.pkg.tar.xz'
(213-5 -> 212-3)
systemd-sysvcompat (213-5 -> 212-3)

Force fsck on reboot?

OK, with Leopard inheriting launchd/launchctl for everything (no more RC scripts!) I'm trying to figure out how to force an fsck of a journalled HFS root partition that I only have remote access to.
i.e. It's in another city.
I can see in the logs:
Feb 12 21:24:29 localhost com.apple.launchctl.System[2]: fsck_hfs: Volume is journaled. No checking performed.
Feb 12 21:24:29 localhost com.apple.launchctl.System[2]: fsck_hfs: Use the -f option to force checking.
But I can't find WHERE that fsck is being called from, so I can't really hack it to do an fsck_hfs -fy
Any suggestions?

OK, this is actually more serious now.
As I understand it, in Tiger, if fsck noticed something (with many UNIX OS's it's like this) the boot would stop, single user mode would start, and an extended fsck would be required.
From Apple's fsck_hfs man page:
[quote]The second form of fsck_hfs preens the specified file systems. It is normally started by fsck(8) run from /etc/rc.boot during automatic reboot, when a HFS file system is detected. When preening file systems, fsck_hfs will fix common inconsistencies for file systems that were not unmounted cleanly. If more serious problems are found, fsck_hfs does not try to fix them, indicates that it was not successful, and exits.[/quote]
Well, I turned off journaling on the partition so that the fsck would be forced. After a MUCH longer boot, I can see this in the system.log:
Feb 12 23:45:47 localhost com.apple.launchctl.System[2]: Invalid directory item count
Feb 12 23:45:47 localhost com.apple.launchctl.System[2]: (It should be 36 instead of 35)
Feb 12 23:45:47 localhost com.apple.launchctl.System[2]: Incorrect folder count in a directory (id = 2)
Feb 12 23:45:47 localhost com.apple.launchctl.System[2]: (It should be 26 instead of 25)
Why is this more serious?
It means that launchd/launchctl, on boot, ran an fsck which produced an error code when checking the boot partition. It then continued booting. In Tiger, /etc/rc.boot would not have continued and would've displayed an appropriate error message, but in Leopard (with launchd/launchctl) this isn't happening!
What if this error resulted in major disk corruption? This sounds very very bad to me!
Any comments/suggestions? I guess what I'm looking for is insight into how the "com.apple.launchctl.System" procedure works and, importantly, how it can be modified.

Syncing forced fsck runs at system boot for all partitions

I know how to change the interval (number of mounts) that fsck uses to force a check. What I'd like to know is how I can get all my partitions to be in sync with each other? In other words, my (/) partition is queued to get checked at the next boot. /home is in queue for 2 boots, /var isn't on the list. I'd like all three of these to be in sync'ed such that all three will get checked together. Ideas?

You could use the -C option in tune2fs to set the mount-count:
tune2fs -C 0 /dev/sda1
Check the result with:
dumpe2fs /dev/sda1 | more
If you set the same mount-count and the same max-mount-counts on all volumes I guess they should be checked at the same time.

Upgrade to util-linux-ng-2.17.1-1 breaks fsck[SOLVED]

After upgrading to lastest util-linux-ng (2.17.1-1) from 2.17.1 "fsck" always hangs at boot. I downgraded to 2.17.1 and it worked again. No error messages are output when it hangs. System is a Dell XPS M1530 laptop.
Thanks.
--mark
kernel26 2.6.32.9-1
Linux laptop-al 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 23 19:43:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz GenuineIntel GNU/Linux
Last edited by markz79 (2010-03-08 13:09:25)

Try to pass manually fsck and see how respond. (I assume that you don't use any encryption, lvm setup, just the standard)
boot with init=/bin/bash
/bin/mount -n -t tmpfs udev /dev -o mode=0755
/bin/mount -n -t proc none /proc
/bin/mount -n -t sysfs none /sys
/bin/cp -a /lib/udev/devices/* /dev/
echo > /proc/sys/kernel/hotplug
/sbin/udevd --daemon
/sbin/udevadm trigger
/sbin/udevadm settle
skip all above commands if you have devtmpfs (not by default in Arch Linux kernel26) only need this:
mount -n -t devtmpfs none /dev
Now run a fsck -fv on all your partitions.
EDIT: use openvt is you need more consoles, run before fsck
Last edited by djgera (2010-03-08 00:17:58)

Fluxbox, cannot force upgrade [solved]

it just ignores the new package completely, like it's not even there.

stonecrest wrote:The fluxbox package probably hasn't hit your mirror yet.
Oh, okay. All the other times updates were listed, they were available immediately. Now I know, eh, sometimes gotta be patient. LOL. :oops:
Penguin wrote:Why are you trying to force it? pacman -Sy fluxbox doesn't give you anything?
I think you need to have the --force -f option before the package name but thats only if you get files exists in filesystem errors.
pacman -Syf fluxbox.
Cool. I'll keep that in mind.

Btrfs forced readonly [SOLVED]

Last night the root btrfs on my main box became borked. It became read only and on a restart non-existent. after trying to troubleshoot the issue, I ended up paving over and starting fresh.
Now with a fresh install I'm seeing the same type of issues, thought system will boot into gnome, and after a bit it'll be forced to read only.
I ran smartctl on the disk and the root disk passed. (There is one disk that did not though is is just a storage disk)
What are the correct trouble shooting steps?
thank you.
i have the output dmesg
[ 2223.735916] ------------[ cut here ]------------
[ 2223.735956] WARNING: CPU: 11 PID: 5620 at fs/btrfs/extent-tree.c:876 btrfs_lookup_extent_info+0x471/0x4c0 [btrfs]()
[ 2223.735959] Modules linked in: xfs libcrc32c jfs bnep bluetooth crc16 fuse arc4 snd_hda_codec_hdmi ath9k nls_iso8859_1 ath9k_common nls_cp437 vfat ath9k_hw fat ath mousedev coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul mac80211 hid_generic crc32_pclmul ghash_clmulni_intel eeepc_wmi iTCO_wdt asus_wmi snd_usb_audio sparse_keymap iTCO_vendor_support led_class aesni_intel video hwmon evdev aes_x86_64 lrw usbhid mac_hid mxm_wmi snd_usbmidi_lib gf128mul snd_rawmidi glue_helper psmouse ablk_helper hid cryptd sb_edac serio_raw cfg80211 snd_seq_device pcspkr i2c_i801 edac_core rtc_efi nvidia(PO) rfkill r8169 mii lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep drm snd_pcm snd_timer snd tpm_infineon mei_me i2c_core
[ 2223.736008] tpm_tis mei soundcore tpm button processor wmi shpchp nfs lockd sunrpc fscache btrfs xor raid6_pq sd_mod sr_mod crc_t10dif cdrom crct10dif_common atkbd libps2 crc32c_intel ahci libahci libata ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio
[ 2223.736034] CPU: 11 PID: 5620 Comm: snapperd Tainted: P O 3.17.1-1-ARCH #1
[ 2223.736036] Hardware name: System manufacturer System Product Name/P9X79 LE, BIOS 4608 12/24/2013
[ 2223.736039] 0000000000000000 00000000d5e94126 ffff880ec18ab6b0 ffffffff81536850
[ 2223.736042] 0000000000000000 ffff880ec18ab6e8 ffffffff8107054d ffff880f031ad240
[ 2223.736046] ffff8800cdb51000 000000001dd8c000 ffff880f66ceb320 0000000000000000
[ 2223.736049] Call Trace:
[ 2223.736057] [<ffffffff81536850>] dump_stack+0x4d/0x6f
[ 2223.736064] [<ffffffff8107054d>] warn_slowpath_common+0x7d/0xa0
[ 2223.736068] [<ffffffff8107067a>] warn_slowpath_null+0x1a/0x20
[ 2223.736083] [<ffffffffa04bac71>] btrfs_lookup_extent_info+0x471/0x4c0 [btrfs]
[ 2223.736099] [<ffffffffa04c1fd1>] ? btrfs_alloc_free_block+0x3b1/0x480 [btrfs]
[ 2223.736112] [<ffffffffa04ab31c>] update_ref_for_cow+0x18c/0x370 [btrfs]
[ 2223.736131] [<ffffffffa04f9750>] ? copy_extent_buffer+0xb0/0x110 [btrfs]
[ 2223.736144] [<ffffffffa04ab72c>] __btrfs_cow_block+0x22c/0x530 [btrfs]
[ 2223.736157] [<ffffffffa04abbc6>] btrfs_cow_block+0x116/0x1e0 [btrfs]
[ 2223.736170] [<ffffffffa04af9b3>] btrfs_search_slot+0x1e3/0xa70 [btrfs]
[ 2223.736187] [<ffffffffa04dedaf>] btrfs_truncate_inode_items+0x12f/0xa70 [btrfs]
[ 2223.736192] [<ffffffff811c9c38>] ? __sb_start_write+0x58/0x110
[ 2223.736208] [<ffffffffa04e0928>] btrfs_evict_inode+0x3e8/0x560 [btrfs]
[ 2223.736216] [<ffffffff811e24d4>] evict+0xb4/0x1a0
[ 2223.736219] [<ffffffff811e2d65>] iput+0xf5/0x1a0
[ 2223.736233] [<ffffffffa04e1548>] btrfs_orphan_cleanup+0x208/0x440 [btrfs]
[ 2223.736248] [<ffffffffa04e1b80>] btrfs_lookup_dentry+0x400/0x5a0 [btrfs]
[ 2223.736262] [<ffffffffa04e1d32>] btrfs_lookup+0x12/0x40 [btrfs]
[ 2223.736267] [<ffffffff811d0b6d>] lookup_real+0x1d/0x70
[ 2223.736272] [<ffffffff811d1872>] __lookup_hash+0x42/0x60
[ 2223.736275] [<ffffffff811d2333>] lookup_slow+0x43/0xc0
[ 2223.736279] [<ffffffff811d44d3>] path_lookupat+0x723/0x880
[ 2223.736282] [<ffffffff811d268c>] ? getname_flags+0x2c/0x130
[ 2223.736286] [<ffffffff811d4656>] filename_lookup.isra.30+0x26/0x80
[ 2223.736290] [<ffffffff811d7967>] user_path_at_empty+0x67/0xd0
[ 2223.736293] [<ffffffff811d79e1>] user_path_at+0x11/0x20
[ 2223.736297] [<ffffffff811cc34a>] vfs_fstatat+0x6a/0xd0
[ 2223.736301] [<ffffffff811c90aa>] ? __fput+0x13a/0x200
[ 2223.736305] [<ffffffff811cca69>] SyS_newfstatat+0x29/0x60
[ 2223.736310] [<ffffffff8108c684>] ? task_work_run+0xa4/0xe0
[ 2223.736315] [<ffffffff81014d45>] ? do_notify_resume+0x95/0xa0
[ 2223.736320] [<ffffffff8153ca60>] ? int_signal+0x12/0x17
[ 2223.736324] [<ffffffff8153c829>] system_call_fastpath+0x16/0x1b
[ 2223.736327] ---[ end trace b1b5980b59c9b9cb ]---
[ 2223.736331] BTRFS: error (device sda3) in update_ref_for_cow:1018: errno=-30 Readonly filesystem
[ 2223.736334] BTRFS info (device sda3): forced readonly
[ 2223.736336] ------------[ cut here ]------------
[ 2223.736347] WARNING: CPU: 11 PID: 5620 at fs/btrfs/super.c:259 __btrfs_abort_transaction+0x50/0x110 [btrfs]()
[ 2223.736349] BTRFS: Transaction aborted (error -30)
[ 2223.736350] Modules linked in: xfs libcrc32c jfs bnep bluetooth crc16 fuse arc4 snd_hda_codec_hdmi ath9k nls_iso8859_1 ath9k_common nls_cp437 vfat ath9k_hw fat ath mousedev coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul mac80211 hid_generic crc32_pclmul ghash_clmulni_intel eeepc_wmi iTCO_wdt asus_wmi snd_usb_audio sparse_keymap iTCO_vendor_support led_class aesni_intel video hwmon evdev aes_x86_64 lrw usbhid mac_hid mxm_wmi snd_usbmidi_lib gf128mul snd_rawmidi glue_helper psmouse ablk_helper hid cryptd sb_edac serio_raw cfg80211 snd_seq_device pcspkr i2c_i801 edac_core rtc_efi nvidia(PO) rfkill r8169 mii lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep drm snd_pcm snd_timer snd tpm_infineon mei_me i2c_core
[ 2223.736397] tpm_tis mei soundcore tpm button processor wmi shpchp nfs lockd sunrpc fscache btrfs xor raid6_pq sd_mod sr_mod crc_t10dif cdrom crct10dif_common atkbd libps2 crc32c_intel ahci libahci libata ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio
[ 2223.736418] CPU: 11 PID: 5620 Comm: snapperd Tainted: P W O 3.17.1-1-ARCH #1
[ 2223.736420] Hardware name: System manufacturer System Product Name/P9X79 LE, BIOS 4608 12/24/2013
[ 2223.736422] 0000000000000000 00000000d5e94126 ffff880ec18ab730 ffffffff81536850
[ 2223.736425] ffff880ec18ab778 ffff880ec18ab768 ffffffff8107054d 00000000ffffffe2
[ 2223.736428] ffff880f66ceb320 ffff8800cdb51000 ffffffffa0552220 0000000000000488
[ 2223.736432] Call Trace:
[ 2223.736435] [<ffffffff81536850>] dump_stack+0x4d/0x6f
[ 2223.736439] [<ffffffff8107054d>] warn_slowpath_common+0x7d/0xa0
[ 2223.736445] [<ffffffff810705cc>] warn_slowpath_fmt+0x5c/0x80
[ 2223.736459] [<ffffffffa04ab4e1>] ? update_ref_for_cow+0x351/0x370 [btrfs]
[ 2223.736471] [<ffffffffa04a5d10>] __btrfs_abort_transaction+0x50/0x110 [btrfs]
[ 2223.736484] [<ffffffffa04ab91d>] __btrfs_cow_block+0x41d/0x530 [btrfs]
[ 2223.736497] [<ffffffffa04abbc6>] btrfs_cow_block+0x116/0x1e0 [btrfs]
[ 2223.736509] [<ffffffffa04af9b3>] btrfs_search_slot+0x1e3/0xa70 [btrfs]
[ 2223.736524] [<ffffffffa04dedaf>] btrfs_truncate_inode_items+0x12f/0xa70 [btrfs]
[ 2223.736528] [<ffffffff811c9c38>] ? __sb_start_write+0x58/0x110
[ 2223.736542] [<ffffffffa04e0928>] btrfs_evict_inode+0x3e8/0x560 [btrfs]
[ 2223.736549] [<ffffffff811e24d4>] evict+0xb4/0x1a0
[ 2223.736552] [<ffffffff811e2d65>] iput+0xf5/0x1a0
[ 2223.736566] [<ffffffffa04e1548>] btrfs_orphan_cleanup+0x208/0x440 [btrfs]
[ 2223.736579] [<ffffffffa04e1b80>] btrfs_lookup_dentry+0x400/0x5a0 [btrfs]
[ 2223.736593] [<ffffffffa04e1d32>] btrfs_lookup+0x12/0x40 [btrfs]
[ 2223.736598] [<ffffffff811d0b6d>] lookup_real+0x1d/0x70
[ 2223.736602] [<ffffffff811d1872>] __lookup_hash+0x42/0x60
[ 2223.736605] [<ffffffff811d2333>] lookup_slow+0x43/0xc0
[ 2223.736609] [<ffffffff811d44d3>] path_lookupat+0x723/0x880
[ 2223.736612] [<ffffffff811d268c>] ? getname_flags+0x2c/0x130
[ 2223.736615] [<ffffffff811d4656>] filename_lookup.isra.30+0x26/0x80
[ 2223.736619] [<ffffffff811d7967>] user_path_at_empty+0x67/0xd0
[ 2223.736622] [<ffffffff811d79e1>] user_path_at+0x11/0x20
[ 2223.736626] [<ffffffff811cc34a>] vfs_fstatat+0x6a/0xd0
[ 2223.736629] [<ffffffff811c90aa>] ? __fput+0x13a/0x200
[ 2223.736633] [<ffffffff811cca69>] SyS_newfstatat+0x29/0x60
[ 2223.736638] [<ffffffff8108c684>] ? task_work_run+0xa4/0xe0
[ 2223.736642] [<ffffffff81014d45>] ? do_notify_resume+0x95/0xa0
[ 2223.736646] [<ffffffff8153ca60>] ? int_signal+0x12/0x17
[ 2223.736650] [<ffffffff8153c829>] system_call_fastpath+0x16/0x1b
[ 2223.736652] ---[ end trace b1b5980b59c9b9cc ]---
[ 2223.736672] BTRFS error (device sda3): Error removing orphan entry, stopping orphan cleanup
[ 2223.736675] BTRFS critical (device sda3): could not do orphan cleanup -22
[ 2223.736865] systemd-journald[242]: Failed to truncate file to its own size: Read-only file system
[ 2223.736924] systemd-journald[242]: Failed to truncate file to its own size: Read-only file system
[ 2223.738099] systemd-journald[242]: Failed to truncate file to its own size: Read-only file system
[ 2223.738182] systemd-journald[242]: Failed to truncate file to its own size: Read-only file system
...repeated...
Last edited by brentaar (2014-10-25 17:15:57)

I can confirm it works.
I wiped my / (btrfs), reinstalled Arch from scratch on it, then upgraded the linux package, installed btrfs-progs-git and rebooted. After that, I did a btrfsck on my home partition (also btrfs), and the output told me to run it again, this time with the --repair option. After a minute or so, my /home was successfully repaired.
The only downside of this history was that I couldn't recover my root (I wiped it, as I said). Why? I was trying to do the same procedure (compiling btrfs-progs-git and running btrfsck on my root), however, it wasn't sufficient to have the latest version of btrfs-progs; it looks like you also had to be running on a recent Linux kernel (3.16+). A person from #btrfs also confirmed this to me.
Problem was...I couldn't think of any linux distribution who has a live medium of a recent Linux kernel. I used grml (which I've found to be a very nice recover distro), however its linux were 3.12. Okay, of course I also tried with Arch, which were on 3.17.1, however I always got a problem related with BUFFER I/O and ext4 error -- I believe I was stressing my USB Flash Drive way too much by installing several packages on it (required to compile then install the btrfs-progs-git AUR package).
TL;DR: all is well, except that I'm redownloading and reinstalling all of my packages.
Last edited by thiagowfx (2014-11-04 14:41:32)

Startup hangs at systemd-fsck [solved]

Here is a screenshot of where the machine hangs when starting (this is within VirtualBox, Win7 host and an Arch guest)--> http://i.imgur.com/4KPLmY8.png
Not sure how to troubleshoot this, the `Fallback initramfs` has the same issue.
Last edited by raj (2013-03-22 21:21:19)

Sorry, I should have stated this was not a new install. It was due to a vbox guest-utils update I got off -Syu a few days ago. Yesterday's update resolved the issue of Xorg not finding an available screen.
Case closed, thanks for the reply.

Fsck.mode=force stopped working

I'm running linux-3.11.1-1-ARCH x86_64 fully updated. A recent systemd update advised to change the mkinitcpio setup. My hooks now look like this
HOOKS="base systemd autodetect modconf block filesystems keyboard fsck resume"
I've run mkinitcpio.conf and rebooted OK. However, I cannot now force fsck to run using a kernel parameter ie fsck.mode=force doesn't cause fsck to run.
I believe that even the normal fsck checking has stopped as dumpe2fs /dev/sda1 now shows
Mount count: 8
Maximum mount count: 5
How do I get the normal fsck checking to work?

Don't know if it's related but in: https://wiki.archlinux.org/index.php/Su … al_ramdisk
it says clearly that:
# resume must be placed after block and lvm2, but before filesystems
The current "default" configuration I believe is to have rw in the kernel line and the fsck behaviour is defined in /etc/fstab, see the wiki.
About forcing check I can't tell...
Regards

[SOLVED] Plymouth won't work anymore

Hi, I don't know id this is the correct category but well, Here we go:
I'm having an issue with Plymouth since a couple of days: It does not work at all.
It does not show up neither at startup nor at shutdown, the only thing on screen is text detailing the startup or shutdown process. Even when I try to test it doing this:
plymouthd
plymouth --show-splash
Nothing happens.
This started to happen a couple days ago, after I reinstalled my kernel with the Arch iso because of this issue
I don't know how could this affect Plymouth, but now it doesn't work at all.
Heres my /etc/mkinitcpio.conf file
My /etc/default/grub
I obviusly tried to rebuild the initrd using
sudo mkinitcpio -p linux
To see if that could resolve my problem but it didn't.
I even downgraded to the previous kernel to see if it's was some kind of kernel-related issue but that didn't work too so I reinstalled the latest kernel 3.15.2-1-ARCH.
I've even tried reinstalling plymouth just to see it was useless because the issue is still there.
Any light on this will be well appreciated.
Thanks in advance, Shadow_Reaper13
EDIT: Here's my plymouth-debug.log
Last edited by Shadow_Reaper13 (2014-07-07 19:20:16)

Shadow_Reaper13 wrote:
I found something else, in this bug report There's another issue with Plymouth which seems to be caused by a forced fsck which can be done like this:
sudo touch /forcefsck
I did this as you can see on the first link in my first post, so I'm 99% sure this have something to do with the issue I'm having.
While the issue seems to be slightly different, the problem is the same: The splash screen does not show up.
I hope this help out troubleshooting the problem. I will search a bit more to see if there is something else I can try. I will also try again the fsck to see if this solves anything.
Well, doing the fsck again didn't changed anything at all. Anyone out there willing to help please?

[SOLVED] upgrade using Octopi system will not boot into DM

I did a system upgrade using Octopi late last night. I use Enlightenment and Gnome. After the upgrade the desktop froze (E), so I switched to a vt and rebooted. That failed to work, so I forced power off using the power button and went to bed. The next day I started up the laptop (lenovo t430) but the boot never got to gdm login. I stops with the line: "[ OK ] Started Accounts Service". Using htop I see that gdm is running.
Then I opened a vt and tried to do another upgrade (pacman -Syu), but that failed with an error message stating that a libgpgme was too short. I took a look and found that both libgpgme files were empty (0 bytes). I went to my pacman cache and found the packages and use them to copy over the lib files. Pacman then worked. But booting still did not.
All this made me curious, so I checked my /usr/lib dir and found 54 lib files empty. I'm certainly no system expert, but this doesn't seem like a good sign to me. When ldconfig is run a very long list of empty libs is printed to the screen.
At any rate, I'm wonder if anyone else ran into this issue and (of course) if anyone has a solution for this? I really don't want to go through each empty lib and copy the files by hand if I can avoid it.
Any help would be very appreciated.
TIA
Gary
Last edited by henrythemouse (2014-12-31 05:45:05)

jasonwryan wrote:
Please edit your title to reflect the fact that Octopi borked your system.
https://wiki.archlinux.org/index.php/Pa … an_upgrade
Thank you for the link, not to mention the quick reply.
The packages python-packagekit and packagekit had to be removed before I could start the installation as they had a dependency on a older version of pacman. My mirrors file caused a good deal of packages to not be downloaded, so that had to be changed. Afterwards everything went well. This experience has shown me the strength of the Arch package system, it's really an amazing system.
I tried the recommended command from the above link but kept getting numerous error messages stating that such and such file already existed on the filesystem. Which was true enough, so I added the --force parameter and that did the trick.
This is the command I used to get running again:
pacman -S $(pacman -Qnq) --force
Problem solved. Except I have to wonder how it was caused in the first place. If it was caused by using Octopi, I guess I should run that by the author. And I'll have to either go back to using the command line or try another gui.
Last edited by henrythemouse (2014-12-31 05:43:13)

[SOLVED] Unable to boot into fresh install (UEFI, gummiboot)

Hello to you all,
I installed arch linux on my new Lenovo E130 following Beginner's guide. After install, when I rebooted the system I'm dropped into emergency shell. Whole log:
:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
:: performing fsck on '/dev/sda1'
fsck: fsck.vfat: not found
fsck: error 2 while executing fsck.vfat for /dev/sda1
ERROR: fsck failed on '/dev/sda1'
:: mounting '/dev/sda1' on real root
mount: unknown filesystem type 'vfat'
You are now being dropped into an emergency shell.
/dev/sda1 is my UEFI partition in fat32 filesystem, mounted to /boot in fstab. Also it's wierd that fsck is trying to run on this partition as it's entery in fstab is
/dev/sda1 /boot vfat defaults 0 0
so no fsck is expected? Also I tried linux-lts kernel and installing dostools and than mkinitcpio to renew all the hooks, the error is still the same.
Thanks for all your help.
Last edited by kokice12 (2013-12-27 00:54:35)

My root is on ext4 partition, let me just show you my fstab
/dev/sda1 /boot vfat defaults 0 0
/dev/sda2 none swap defaults 0 0
/dev/sda3 / ext4 rw,relatime,data=ordered 0 1
I really don't know why is it forcing fsck on partition with pass=0 in fstab?
And thank you

Reboot failed after smb upgrade(SOLVED)

Forced fsck ran during reboot and reports two files using same inode ...'usr/bin/smbget .../usr/bin/smbtree
What can be done to eliminate this problem?
Last edited by lilsirecho (2009-05-06 06:47:26)

Booted into Faunos Live system.
As root, ran Fsck on the HDD with inode problem. Answered yes to all system repair queries.
Rebooted into archlinux HDD with no problems.

Avoiding lenghty fsck

our DB version: 11.2
our OS: SLES11
our fs: ext3
My question: with the FRA residing on ext3, how can I avoid lengthy fsck runs on server reboots: even with clean shutdowns, Linux will eventually trigger forced fsck runs after a period of time (see also [Why the ext3 fsck’s after X days or Y mounts?|http://prefetch.net/blog/index.php/2010/04/18/why-the-ext3-fscks-after-x-days-or-y-mounts]).
Turning off this mechanism with tune2fs is not recommended.
Novell recommends using xfs instead of ext3. But would that really help (and xfs, although supported is not tested by Oracle according to MOS)?
With the FRA partition of a size of 2.1 TB, fsck can take up to 30 minutes or more, and this is a long time for the db server to come back to operation.
Of course, ASM comes to mind, but that would be just another slab of complexity in an otherwise simple installation.
Thanks for your opinion or sharing your XFS experience,
Thomas

here we have some further insight to share.
We did an extensive test to see which filesystem to choose for
our Samba shares, and took EXT3, BTRFS und XFS in the boat (all
supported by Novell SLES 11).
Novell's statement is that BTRFS is mainly a boot partition
choice, and recommends XFS for large amount of data.
The - only for testing purposes - setup, very shortly:
10 TB striping RAID on NearLine Disks in Fujitus Eternus,
formatted in a VMFS5 Datastore.
A VM (SLES11 SP2) on ESXi 5.1 (2 vCPU, 1 GB RAM) gets the space
as vdisks, and will format 3 * 3 TB file systems.
*1st test: creating the 3 TB file systems*
Btrfs: a few seconds
Ext3: about 30 minutes
XFS: about 9 minutes
as we create filesystems only once, let's not further look at
that.
*2nd test: fio throughput*
Without going into many fio details (we took 8GB samples, using
128 KB blocksize):
1.) linear read/write
KB/s | Btrfs Ext3 XFS
------+-------------------------------
read | 89.045 83.262 91.740
write | 13.722 198.622 208.947
2.) random read/write
KB/s | Btrfs Ext3 XFS
------+-------------------------------
read | 41.702 28.920 17.548
write | 59.792 128.033 74.353
Btrfs shows some linear writing lazyness, because of its
checksumming. XFS dissappoints with its random read throughput.
*3dr test: find performance*
we tested how quickly a file is found using the find command. For
that, we filled the file systems with about 1.2 TB test data from
production systems (typical shared Samba drives, with office
documents and all that stuff). After each test, we did a reboot
to ensure a clean file system cache.
Btrfs: 2 m 53 s
Ext3: 9 m 58 s
Xfs: 1 m 9 s
Similarly, we queried du Info for each and the whole of the three
file systems:
Btrfs: 8 m 4 s
Ext3: 19 m 35 s
Xfs: 4 m 20 s
We see that Ext3 is not very efficient when it comes to
traversing large file systeme metadata.
*4th test: fsck runtime*
We force a file system check.
It's worth considering the CAVEAT from the btrfsck man page:
"btrfsck is part of btrfs-progs. Btrfs is currently under heavy
development, and not suitable for any uses other than benchmarking
and review. Please refer to the btrfs wiki
http://btrfs.wiki.kernel.org for further details."
Btrfs (command was "time btrfsck ..."): 9 m 6 s
Ext3 (command was "time fsck -f ..."): 72 m 35 s
XFS (command was "time xfs_repair -n ..."): 11 m 18 s
Ext3 is far slower when checking that sizy file systems: might
its checks simply be more exhaustive?
Back to initial topic: "avoiding lenghty fsck". It does not
appear irrelevant which cooke file system we choose. XFS appears
to be a far better choice in terms of fsck run time.
According to MOS 414673.1 (SuSE/Novell: Linux, Filesystem & I/O
Type Supportability), XFS is a supported choice, although there
are some important CAVEATS regarding bugs and taking most recent
versions.
Also, we read
Oracle does not run certifications on local
filesystems (i.e. except for OCFS2, NFS etc.) except ext2/ext3 as
it is the common default filesystem for all Linux
distributions. So if a problem happens specific to XFS, the Linux
vendor should be engaged.
This will bring us back to probably take ASM for Oracle data in
future (currently still using EXT3), and choose XFS for all other
user data.
For user data, we would also like to choose BTRFS, as we would
favour the automatic checksumming, but the status of btrfsck (see
above) alone is enough to hdissuade us from that choice for the
time being.
Comments welcome!
Regards, Thomas

[SOLVED] Filesystem check failed

Hi all,
i've just upgraded the system, but when rebooting it gives me that error on sda5 (the linux partition) and suggests me to repair manually and reboot! what should i repair? can you please give me any suggestion?
Thanks in advance
Last edited by virusso80 (2010-01-15 15:48:04)

guisacouto wrote:
it seems like today is broken filesystem day.. LOL
I had this problem too in my laptop and that fsck solved it very well!
unfortunatly I cannot say the same thing about the external hard drive that is connected to the desktop which has a fat32 filesystem corrupted.. I'm trying to find some courage to format it, because testdisk can only recover the files with some default name.. thats not good enough because 320GB of music, movies and documents isnt very usefull without the real names.. x| I guess this is just not my day
regards!
There's a /sbin/fsck.vfat as well.

Forced FSCK[solved]

Similar Messages

Maybe you are looking for