On Mon, 2015-12-07 at 10:30 +1030, Arthur Marsh wrote: > > Ben Hutchings wrote on 07/12/15 09:33: > > Control: reassign -1 src:linux 3.17-1~exp1 > > Control: tag -1 moreinfo > > > > On Sat, 18 Oct 2014 23:42:56 +1030 Arthur Marsh wrote: > > [...] > > > Hi, I still have the issue that with initramfstools later than 0.116 (ie > > > 0.117 and 0.118) that with the disks corrupted, the boot process would > > > hang. > > > > > > With initramfs-tools 0.116, the boot process proceeded normally and > > > successfully run fsck on the filesystems to be mounted (the disk above > > > with a HPA was not listed in /etc/fstab to have any filesystems mounted). > > > > > > I'm not sure how to reproduce this bug without resorting to somehow > > > deliberately corrupting a filesystem and/or disk partition table. > > > > I think this must be a kernel or hardware bug that is triggered by > > slightly different behaviour in initramfs-tools. > > > > Have you seen this issue recur with more recent kernel versions? > > > > Ben. > > > > I haven't seen this issue more recently but haven't had a dirty > filesystem apart from those caused by a few power failures. > > Part of the problem may be that the forced filesystem checks with later > than 0.116 version of initramfs-tools do not display any visible > progress on the console, so it's not always clear what is happening. > > Is there a way to make the forced fsck progress (e.g. for the root > filesystem) visible on the console with current versions of initramfs-tools?
No, but you can find the output in /run/initramfs/fsck.log (both in the
initramfs and after booting).
Ben.
--
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
signature.asc
Description: This is a digitally signed message part
