lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EB73FFB.9050506@gmail.com>
Date:	Sun, 06 Nov 2011 18:18:35 -0800
From:	Matt Parnell <mparnell@...il.com>
To:	Ted Ts'o <tytso@....edu>
CC:	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: Bug In ext4 in kernels > 2.6.39 - Not mounting with arguments/options
 I specify in fstab on root remount

On 10/22/2011 02:32 AM, Ted Ts'o wrote:
> On Sat, Oct 22, 2011 at 02:51:35AM -0500, Matt Parnell wrote:
>> That doesn't really help me at all, it's not
>> rootflags=data=writeback causing this, it's starting to make me
>> think that arch's init may be to blame, although I previously ruled
>> it out...
> Well, it looks like rootflags=data=writeback is not making it to the
> file system.  That's why it's not showing up in /proc/mounts, from you
> showed us.  Can you look at the kernel dmesg?
>
> You should see something like this:
>
> [    1.421146] EXT3-fs (vda): error: couldn't mount because of unsupported optional features (240)
> [    1.434057] EXT4-fs (vda): couldn't mount as ext2 due to feature incompatibilities
> [    1.454631] EXT4-fs (vda): mounted filesystem with writeback data mode. Opts: data=writeback
> [    1.455966] VFS: Mounted root (ext4 filesystem) readonly on device 254:0.
>
>
> The first line is the failure to mount the root file system as ext3.
> The 2nd is the failure to mount the file system as ext2, using the
> ext4 file system driver.  The last two lines show the options show the
> mount as ext4.
>
> What do those two lines look to you.  If you don't see "Opts:
> data=writeback", then somehow the rootflags option isn't getting passed
> down to the file system.  Then when you try to remount the file system
> read/write, the fact that you have "data=writeback" in your /etc/fstab
> causes the failure to remount.
>
> If you simply remove that from /etc/fstab, things should work better.
> The remount will preserve whatever data=journalling mode was in use
> when the root file system was originallymounted as.  If rootflags is
> non-functional, then the file system won't be mounted as
> data=writeback, but at least the boot sequence will continue without
> blowing out.
>
> 							- Ted

Since then, I created a fresh partition and re rsynced my root over onto 
it after making it WITHOUT a journal using the current sysrescue64 cd 
(kernel 3.0.1).

Same thing is happening, and the drive still refuses to mount any other 
way except

  /dev/root / ext4 rw,relatime,user_xattr,acl,barrier=1 0 0

Despite my specifying these in fstab and grub.cfg ...it's like it's not 
even passing the options somewhere, either from grub2 to the kernel or 
from my initscripts...but since I've tried using openrc too and get this 
result, I'm not sure what to do. Note that using both /dev/sdb1 and 
/dev/root don't interchange between the fstab and the kernel...I think 
the /dev/root symlink may be breaking my initscripts.

/dev/sdb1 / ext4 
noatime,nodiratime,data=writeback,nouser_xattr,barrier=0,commit=10 0 0
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ