On Tue, 9 Mar 2010 14:08:34 -0500 (EST), Karl Klinger wrote: > Clive McBarton wrote: >> >> Good point, that is probably important. ext3. >> > > From: http://www.mjmwired.net/kernel/Documentation/filesystems/ext3.txt > > ro Mount filesystem read only. Note that ext3 will replay > the journal (and thus write to the partition) even when > mounted "read only". Mount options "ro,noload" can be > used to prevent writes to the filesystem. > > There is really no need for a journal on /boot. Why not use ext2?
Good observation, Karl. But if there have been no changes to the disk during its last mount, there should be nothing in the journal that causes any writes to be done. He has already verified that a umount / mount sequence using the ro option does not change the checksum. The most likely causes are a "dirty shutdown" (i.e. no clean umount during shutdown) or alterations made by the boot loader. For example, the boot loader may be updating the mount count or updating the "last referenced date/time", if there is such a field in the filesystem, for the kernel image or the initial RAM disk image. Many filesystems have a "last referenced date/time" field for a file, which gets updated even if the file itself is accessed read-only. This information is needed in support of archival software. For example, you may write a rule in your archival software something like, "if a file has not been referenced in the last 30 days, then archive it to tape". You can't write rules like that unless the filesystem keeps track of when a file was last referenced. If the filesystem is mounted read-only, then this field may not be maintained. But the boot loader doesn't know that Linux is going to mount the filesystem read-only. And it may be maintaining that field when it reads the kernel image or the initial RAM disk image. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1614069833.17936131268170295274.javamail.r...@md01.wow.synacor.com
