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.compilersAttachment:
signature.asc
Description: This is a digitally signed message part