Bug 1375894 - blivet should not do a forced e2fsck in rescue mode
Summary: blivet should not do a forced e2fsck in rescue mode
Status: CLOSED DUPLICATE of bug 1170803
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 24
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1189909
TreeView+ depends on / blocked
Reported: 2016-09-14 08:05 UTC by Fabrice Bellet
Modified: 2017-05-22 21:38 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-05-22 21:38:51 UTC

Attachments (Terms of Use)

Description Fabrice Bellet 2016-09-14 08:05:23 UTC
I noticed that blivet in updateSizeInfo() always makes a full e2fsck on all detected partitions, when running anaconda in rescue mode, and selecting 1/ --continue-- , which is somewhat an unwanted behavior, as some fsck operations can take a *very* long time on some systems.

The only way to bypass this forced fsck is to drop to a shell immediately, and to manually detect, setup and mount all the needed partitions.

This behavior changed since the F-23 installer.

Maybe blivet could be put in installer_mode also when anaconda is running is rescue mode, which I think is not the case ?

Comment 1 Fabrice Bellet 2016-09-14 08:14:24 UTC
Err, blivet *is* put in installer_mode actually (blivet/formats/fs.py):

>        if flags.installer_mode and self._resize.available:
>            # if you want current/min size you have to call updateSizeInfo
>            try:
>                self.updateSizeInfo()
>            except FSError:
>                log.warning("%s filesystem on %s needs repair", self.type,

Comment 2 Charles R. Anderson 2016-10-30 23:01:40 UTC
This also happens in Fedora 25 when clicking the "Continue" button in the installer after selecting the language.  The installer appears to hang during the fsck. 15 minutes so far...

Comment 3 Charles R. Anderson 2017-05-22 21:36:51 UTC
*** Bug 1189905 has been marked as a duplicate of this bug. ***

Comment 4 Charles R. Anderson 2017-05-22 21:38:51 UTC

*** This bug has been marked as a duplicate of bug 1170803 ***

Note You need to log in before you can comment on or make changes to this bug.