Ubuntu Figuring Out Whether To FSCK Its File-Systems At Boot

[LightBit]

Some file systems don't “need” fsck because they have more appropriate designs for the day and age that can survive cases like when battery runs out. Yes, there's xfs_repair, and whatever btrfs has for itself, but that's for exceptional circumstances.

Long time ago I did experiment and XFS lost far more data than Ext4. Usually fsck only deletes files that where unlinked before power loss.

[sbivol]

I think it's bad to have it on by default on servers because when it reboots it must come up as fast as possible to have the least downtime possible to not lose money.

A server usually takes at least 5 minutes to POST so those 5 seconds you spend on checking a (consistent) filesystem don't mean anything on that scale, so now I suspect you have no idea about how these things work...

But what to expect from Canonical which always think: "The user is too stupid, let's do some guesswork!"

...and now I'm pretty sure you're clueless.

[Sonadow]

My old Xeon workstation would take 45 seconds just to leave the BIOS screen and from there it'd vary by distribution. Xeon systems can be like that...slow to boot with all their checks. Look around in the BIOS and see if there aren't any fast boot settings or unnecessary controllers you can enable or disable.

My current system should boot faster than it does but it actually holds itself on the BIOS screen until the keyboard has initialized+3 seconds. My keyboard does this LED effect on power-on and it doesn't respond to key presses until that effect is done. Some cold boots, like an hour ago, I forget that and I think my system broke . I'm so used to my old system taking so damn long, meaning my keyboard was initialized long before I needed to touch it to access the boot menu or BIOS, that being held up by it initializing trips me up

It's not UEFI. The workstation POSTS in about a minute, then loads grub2, so it's not firmware related.

The hangup occurs after grub2 has closed and the kernel is bringing up the HID interfaces like the mouse and keyboard, and happily stalls there for approximately 10min before performing a fsck which returns nothing, then starts up the TTY or GDM, depending on my boot option in grub2. I could literally take a dump and make a drink and return to the desk with the workstation still stalling there without having reached the fsck stage.

systemd-analyze also could not detect any holdups and reported that the boot completed in 2min, which is complete bollocks.

[angrypie]

Long time ago I did experiment and XFS lost far more data than Ext4. Usually fsck only deletes files that where unlinked before power loss.

Not anymore. Can't remember when they fixed that.

Anyway, XFS exists since 1993 and was used in IRIX, so it's hardly new either. EXT4 being derived from Minix's crappy filesystem is the problem.

[lyamc]

fsck by default is preferable, like auto-saving in a document writer. There is time cost, yes, but fsck can happen in parallel, so the time cost is minimal.

My computer BIOS is set to automatically reboot after power is restored, and I imagine that I'm not the only person that does that for trying to run something 24/7.

[k1e0x]

ZFS with no FSCK's given.

(had to)

[F.Ultra]

I agree with the server and disagree with desktops and laptops. The reason being is most people don't have the greatest power grids so better to err on the side of caution. A car wreck miles away from me made me lose power for a split second yesterday while the grid rerouted. Just long enough for me to have to boot every system and set all my clocks on everything else

I expect the average server to have a UPS, be in a building with one, or both so not needing fsck by default is fine.

Shouldn't that instead be handled at mount time if the filesystem was not properly unmounted on the last boot? Never really fully understood the Linux habit of running a full fsck every X boot just in case.

[onlyLinuxLuvUBack]

I think it's bad to have it on by default on servers because when it reboots it must come up as fast as possible to have the least downtime possible to not lose money.
It seems to me that it's bad to have it on by default on desktops too because it would make the already slow boot even slower.
How about leaving people to decide when they need it and trigger it manually ?
They already did this crap on the ISO which are very annoying having to press CTRL+C every time you boot from an ISO instead of letting people do it manually like before.

But what to expect from Canonical which always think: "The user is too stupid, let's do some guesswork!"

It's shiny and new, come on ubuntu , where are you ?

[skeevy420]

Shouldn't that instead be handled at mount time if the filesystem was not properly unmounted on the last boot? Never really fully understood the Linux habit of running a full fsck every X boot just in case.

tune2fs -c 50 /dev/disk

[FPScholten]

It's not UEFI. The workstation POSTS in about a minute, then loads grub2, so it's not firmware related.

The hangup occurs after grub2 has closed and the kernel is bringing up the HID interfaces like the mouse and keyboard, and happily stalls there for approximately 10min before performing a fsck which returns nothing, then starts up the TTY or GDM, depending on my boot option in grub2. I could literally take a dump and make a drink and return to the desk with the workstation still stalling there without having reached the fsck stage.

systemd-analyze also could not detect any holdups and reported that the boot completed in 2min, which is complete bollocks.

Try adding this to your kernel command line in grub: random.trust_cpu=on
If this works, then your system did not generate enough entropy to continue to boot, and will only continue booting when sufficient entropy is reached, and that can take a lot of time...