Encryption for 2.14

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#21 Post by BarryK »

If I recall correctly, fusermount doesn't have an option to remount read-only. That was the problem, and I think this is mentioned in the rc.shutdown script. I tried to do the next best thing, kill all processes running on the mounted ntfs partition and of course flush the f.s.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#22 Post by BarryK »

Okay, it's done. Automatically it will be ext3 as mentioned in my earlier post. This can be tested in 2.16pre-alpha due in a few days.

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#23 Post by GuestToo »

according to the fusermount man page:

-z lazy unmount (works even if resource is still busy)

i'm not exactly sure what that means

it does say somewhere that you can force an unmount, like this: umount-FULL -f $FS and that it always works ... except when it has been lazy unmounted first

so maybe for ntfs drives, you could do something like this at the end of the shutdown script:

fusermount -u $FS || umount-FULL -f $FS

or maybe:

fusermount -u $FS || fusermount -z $FS

i don't really know, i do know that at least one person was complaining that their ntfs home dir seemed to be not unmounting cleanly, and the pup_save file always had some orphan inodes ... i don't even have any ntfs partitions ... oh, and i was wrong when i wrote e2fsck -y -p ... those options are mutually exclusive

in any case, i think it's better if the drives are unmounted, whether a lazy unmount or a forced unmount, because it often leaves an incorrect inode count from deleted files that were not completely deleted, which causes error messages, which bothers people, even though it is not a serious error

i don't care whether you use ext3 or ext2 ... i think i prefer ext3, i just think it is probably not necessary to force a full file system check on every boot ... an encrypted file system is probably easier to damage if the file system is not unmounted cleanly, but if it is unmounted cleanly, e2fsck should know and it should be ok to skip the full check ... and this is all done automatically with the one e2fsck command

User avatar
fudgy
Posts: 86
Joined: Wed 07 Jun 2006, 09:40
Location: Berlin, Germany

#24 Post by fudgy »

GuestToo wrote:[...] that at least one person was complaining that their ntfs home dir seemed to be not unmounting cleanly, and the pup_save file always had some orphan inodes ...
hello, i think this person was me. The ntfs home dir is in the union-fs... so remounting ro would be probabely the best thing.
Isn't it possible to remove branches from the union and then unmounting them ? (I think Nathan F is already testing aufs, very interesting!)

i want to mention that Puppy is my working system for a year now and it runs at least 14h a day. So - relyability is one of the things i have an eye on.

- fudgy

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#25 Post by PaulBx1 »

This is the tread where I dug out the information earlier:

http://www.murga-linux.com/puppy/viewto ... 53&t=13508

Post Reply