linux-ext4 - Re: Bug In ext4 in kernels > 2.6.39 - Not mounting with arguments/options I specify in fstab on root remount

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]

Date:	Sat, 22 Oct 2011 02:53:34 -0500
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

Also, I didn't intend to come across cross there... I appreciate the 
efforts you are taking there.

It's just, I don't know what could've changed between .29 and 3.0 that 
would break an entire init system so that it won't remount root rw...

On 10/22/2011 02:51 AM, 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...
>
> This is all a big wtf though. I'm going to go complain at the arch 
> devs now... I've not finished porting openrc to it yet.
>
> On 10/22/2011 12:00 AM, Ted Ts'o wrote:
>> On Thu, Oct 20, 2011 at 10:29:49PM -0500, Matt Parnell wrote:
>>> The output of /proc/cmdline on 3.0.7:
>>>
>>> BOOT_IMAGE=/boot/vmlinuz26-zen root=/dev/sdb1 ro rootfstype=ext4
>>> rootflags=data=writeback noatime nodiratime barrier=0 discard
>>> noinitrd
>>>
>>>
>>> On 10/09/2011 06:44 PM, Ted Ts'o wrote:
>>>> On Sun, Oct 09, 2011 at 05:10:54PM -0500, Matt Parnell wrote:
>>>>> /proc/mounts (as you can see it's not being remounted rw for some
>>>>> reason - /dev/sdc1 is the flash drive I used to pipe this info onto):
>>>>>
>>>>> rootfs / rootfs rw 0 0
>>>>> /dev/root / ext4 ro,relatime,barrier=1 0 0
>> I haven't had a chance to check on v3.0 (I'm currently travelling and
>> penning this from an airplane), but on v3.1-rc3, it works for me under
>> KVM.  I fire up kvm-qemu this way:
>>
>> $QEMU -enable-kvm -boot order=c $NET \
>>        -drive file=$ROOT_QCOW2,if=virtio$SNAPSHOT \
>>        -drive file=$VDB,cache=none,if=virtio \
>>        -drive file=$VDC,cache=none,if=virtio \
>>        -drive file=$VDD,cache=none,if=virtio \
>>        -nographic -smp $NR_CPU -m $MEM \
>>        --kernel $KERNEL \
>>        --append "root=/dev/vda console=ttyS0,115200 
>> rootflags=data=writeback" |\
>> tee $LOGFILE
>>
>> with this in /proc/cmdline:
>>
>> candygram:~# cat /proc/cmdline
>> root=/dev/vda console=ttyS0,115200 rootflags=data=writeback maint
>>
>> ... and this is what I have in /proc/mounts:
>>
>> candygram:~# head -2 /proc/mounts
>> rootfs / rootfs rw 0 0
>> /dev/root / ext4 rw,noatime,user_xattr,acl,barrier=1,data=writeback 0 0
>>
>> ... and what I have in /etc/fstab:
>>
>> UUID=ce4d6b98-2aa9-42d4-a127-995a795a0b02    /    ext4    
>> noatime,data=writeback 0 1
>>
>> The kvm image I'm using is using Debian unstable image generated using
>> debootstrap, and uses no modules or initrd's --- which makes it easier
>> for me to boot since $KERNEL is set to:
>>
>>      /tyt/linux/ext4/arch/x86/boot/bzImage
>>
>> This allows me to fire up test kernel right from my build tree,
>> without needing to set up any kind of initrd nonsense.  :-)
>>
>>                                                     - Ted
--
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