On Monday 25 May 2009, martin f krafft wrote: > > The only fixes that I can think of are: > > a) Ask initscripts' authors to add a check for already r/w root > > filesystem and leave the root filesystem r/w. > > b) On-the-fly change fstab to remove extra options. > > > > I find (b) to be the easiest approach but I'm not sure that it won't > > cause problems. Any thoughts on that? > > No, definitely do not touch (b).
Remeber that the change will happen inside the protected filesystem and will be lost at the next boot. > I think (c) would be best: > > (c) fix aufs to support errors=remount-ro, and even if it justs > ignores the option. After all, I am unsure what errors mean in > a tmpfs context. It's only related to aufs. tmpfs never gets those options. After the fsprotect's initramfs script runs, the new root filesystem is an aufs filesystem. When the checkroot attempts to remount it read-write it passes the existing options to mount, which are not recognized by aufs. This happens with other options too. I tested it with reiserfs' notail option. I don't believe that making aufs ignore all unrecognized options is the correct way to solve it. It will introduce problems to all people using it when they pass wrong options. AFAIK XFS did a similar change recently, ignoring all unknown options on remount (a quick&dirty test just verified this), but I'm not sure about this either. > > p.s. I'm CC'ing this to the bug report address to keep track of the > > conversation. It may be usefull for future reference. > > If you set your Mail-Followup-To header correctly, then I would have > replied too. ;) Changing M-F-T for each mail with kmail is practically impossible. Mutt is more flexible with this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
