Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Arthur Marsh]

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?


Arthur.

Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Ben Hutchings]

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

Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Ben Hutchings]

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.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:linux 3.17-1~exp1
Bug #764572 [initramfs-tools] initramfs-tools: fails to finish booting with 
dirty filesystem(s)
Bug reassigned from package 'initramfs-tools' to 'src:linux'.
No longer marked as found in versions initramfs-tools/0.118 and 
initramfs-tools/0.116.
Ignoring request to alter fixed versions of bug #764572 to the same values 
previously set
Bug #764572 [src:linux] initramfs-tools: fails to finish booting with dirty 
filesystem(s)
Marked as found in versions linux/3.17-1~exp1.
> tag -1 moreinfo
Bug #764572 [src:linux] initramfs-tools: fails to finish booting with dirty 
filesystem(s)
Added tag(s) moreinfo.

-- 
764572: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764572
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Arthur Marsh]

Ben Hutchings wrote, on 13/10/14 06:16:

On Mon, 2014-10-13 at 02:38 +1030, Arthur Marsh wrote:

Package: initramfs-tools
Version: 0.116
Followup-For: Bug #764572

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?

Another datapoint. I have a hard disk whose filesystems are *not* mounted
at start-up, but after a corruption issue, the disk's state causes a lock-up
requiring a hardware reset and a second start-up (not helpful if this was a
remote machine).

On the second (successful) start-up I saw these messages:

$ dmesg|grep sdc
[4.934246] sd 2:0:1:0: [sdc] 66055248 512-byte logical blocks: (33.8 
GB/31.4 GiB)
[4.934523] sd 2:0:1:0: [sdc] Write Protect is off
[4.934580] sd 2:0:1:0: [sdc] Mode Sense: 00 3a 00 00
[4.934703] sd 2:0:1:0: [sdc] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[4.967651]  sdc: sdc1 sdc2  sdc5 sdc6 sdc7  sdc3
[4.968073] sdc: p3 size 1950 extends beyond EOD, enabling native 
capacity

[...]

This means: your hard drive has an HPA
https://en.wikipedia.org/wiki/Host_Protected_Area configured, but you
actually use that area under Linux.  Linux automatically enables access
to the HPA when it detects this.  This was implemented in 2.6.34 and
backported to squeeze; you just didn't notice the messages before.

Ben.



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.


Regards,

Arthur.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54426758.2020...@internode.on.net

Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Arthur Marsh]

Package: initramfs-tools
Version: 0.116
Followup-For: Bug #764572

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Another datapoint. I have a hard disk whose filesystems are *not* mounted
at start-up, but after a corruption issue, the disk's state causes a lock-up
requiring a hardware reset and a second start-up (not helpful if this was a
remote machine).

On the second (successful) start-up I saw these messages:

$ dmesg|grep sdc
[4.934246] sd 2:0:1:0: [sdc] 66055248 512-byte logical blocks: (33.8 
GB/31.4 GiB)
[4.934523] sd 2:0:1:0: [sdc] Write Protect is off
[4.934580] sd 2:0:1:0: [sdc] Mode Sense: 00 3a 00 00
[4.934703] sd 2:0:1:0: [sdc] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[4.967651]  sdc: sdc1 sdc2  sdc5 sdc6 sdc7  sdc3
[4.968073] sdc: p3 size 1950 extends beyond EOD, enabling native 
capacity
[5.173494] sd 2:0:1:0: [sdc] 78242976 512-byte logical blocks: (40.0 
GB/37.3 GiB)
[5.174584] sdc: detected capacity change from 33820286976 to 40060403712
[5.226390]  sdc: sdc1 sdc2  sdc5 sdc6 sdc7  sdc3
[5.228297] sdc: detected capacity change from 0 to 40060403712
[5.228595] sd 2:0:1:0: [sdc] Attached SCSI disk

Somehow this error the first time round was partially fixed and then caused
a lock-up, then on the second boot attempt completed.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

A hardware reset was required when the boot process hung.

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 12M Jul  1  2013 /boot/initrd.img-3.10.0
-rw-r--r-- 1 root root 12M Sep  4  2013 /boot/initrd.img-3.11.0
-rw-r--r-- 1 root root 13M Nov  4  2013 /boot/initrd.img-3.12.0
-rw-r--r-- 1 root root 13M Jan 20  2014 /boot/initrd.img-3.13.0
-rw-r--r-- 1 root root 14M Mar 31  2014 /boot/initrd.img-3.14.0
-rw-r--r-- 1 root root 16M Sep 21 09:27 /boot/initrd.img-3.16-2-686-pae
-rw-r--r-- 1 root root 16M Oct 11 13:29 /boot/initrd.img-3.16-3-686-pae
-rw-r--r-- 1 root root 15M Aug  4 14:06 /boot/initrd.img-3.16.0
-rw-r--r-- 1 root root 16M Sep 20 09:42 /boot/initrd.img-3.17-rc5-686-pae
-rw-r--r-- 1 root root 16M Oct  6 15:48 /boot/initrd.img-3.17.0
-rw-r--r-- 1 root root 15M Oct 13 01:48 /boot/initrd.img-3.17.0+
-rw-r--r-- 1 root root 12M Jul 29 22:37 /boot/initrd.img-3.2.0-4-686-pae
-rw-r--r-- 1 root root 12M Jun 14  2013 /boot/initrd.img-3.5.0
-rw-r--r-- 1 root root 11M Jun 14  2013 /boot/initrd.img-3.6.0
-rw-r--r-- 1 root root 12M Jun 14  2013 /boot/initrd.img-3.7.0
-rw-r--r-- 1 root root 12M Jun 14  2013 /boot/initrd.img-3.8.0
-rw-r--r-- 1 root root 12M Jun 14  2013 /boot/initrd.img-3.9.0
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.17.0 root=UUID=96c96a61-8615-4715-86d0-09cb8c62638c ro

-- resume
RESUME=/dev/hda6
-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat

-- lsmod
Module  Size  Used by
snd_hrtimer12648  1 
nfc83473  0 
cpufreq_stats  13111  0 
cpufreq_conservative14802  0 
cpufreq_powersave  12554  0 
cpufreq_userspace  12771  0 
bnep   18829  2 
nfnetlink_queue17836  0 
nfnetlink_log  17591  0 
nfnetlink  14466  2 nfnetlink_log,nfnetlink_queue
bluetooth 389817  5 bnep
rfkill 21695  3 nfc,bluetooth
binfmt_misc13111  1 
nls_utf8   12493  4 
nls_cp437  12751  4 
vfat   17166  4 
fat55862  1 vfat
cuse   13213  3 
fuse   81416  1 cuse
tun26628  0 
snd_emu10k1_synth  13104  1 
snd_emux_synth 33539  2 snd_emu10k1_synth
snd_seq_midi_emul  13529  1 snd_emux_synth
snd_seq_virmidi13248  1 snd_emux_synth
snd_seq_midi_event 14503  1 snd_seq_virmidi
snd_seq52764  6 
snd_seq_midi_event,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul
w83627hf   27081  0 
hwmon_vid  12687  1 w83627hf
max665013931  0 
lp 17395  0 
uas22763  0 
usb_storage48591  2 uas
radeon   1292179  2 
ttm73197  1 radeon
drm_kms_helper 82292  1 radeon
ppdev  17363  0 
drm   248829  5 ttm,drm_kms_helper,radeon
psmouse95744  0 
evdev  17449  9 
snd_emu10k1   137141  2 snd_emu10k1_synth
i2c_algo_bit   13190  1 radeon
serio_raw  13210  0 
pcspkr 12630  0 
snd_util_mem   13821  2 snd_emux_synth,snd_emu10k1
snd_hwdep  13272  2 snd_emux_synth,snd_emu10k1
emu10k1_gp 12550  0 
snd_ac97_codec101724  1 

Bug#764572: initramfs-tools: fails to finish booting with dirty filesystem(s)

[Ben Hutchings]

On Mon, 2014-10-13 at 02:38 +1030, Arthur Marsh wrote:
 Package: initramfs-tools
 Version: 0.116
 Followup-For: Bug #764572
 
 Dear Maintainer,
 
 *** Reporter, please consider answering these questions, where appropriate ***
 
* What led up to the situation?
 
 Another datapoint. I have a hard disk whose filesystems are *not* mounted
 at start-up, but after a corruption issue, the disk's state causes a lock-up
 requiring a hardware reset and a second start-up (not helpful if this was a
 remote machine).
 
 On the second (successful) start-up I saw these messages:
 
 $ dmesg|grep sdc
 [4.934246] sd 2:0:1:0: [sdc] 66055248 512-byte logical blocks: (33.8 
 GB/31.4 GiB)
 [4.934523] sd 2:0:1:0: [sdc] Write Protect is off
 [4.934580] sd 2:0:1:0: [sdc] Mode Sense: 00 3a 00 00
 [4.934703] sd 2:0:1:0: [sdc] Write cache: enabled, read cache: enabled, 
 doesn't support DPO or FUA
 [4.967651]  sdc: sdc1 sdc2  sdc5 sdc6 sdc7  sdc3
 [4.968073] sdc: p3 size 1950 extends beyond EOD, enabling native 
 capacity
[...]

This means: your hard drive has an HPA
https://en.wikipedia.org/wiki/Host_Protected_Area configured, but you
actually use that area under Linux.  Linux automatically enables access
to the HPA when it detects this.  This was implemented in 2.6.34 and
backported to squeeze; you just didn't notice the messages before.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


signature.asc
Description: This is a digitally signed message part