On Thu, 11 Mar 2010 19:39:11 -0500 (EST), Clive McBarton wrote:
> Stephen Powell wrote:
>> If you can't figure out how to make grub use the "list of sectors"
>> method, I once again suggest that you switch to lilo.
>
> The whole point is to make the system secure. So let's look at lilo's
> secur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Powell wrote:
> If you can't figure out how to make grub use the "list of sectors"
> method, I once again suggest that you switch to lilo.
The whole point is to make the system secure. So let's look at lilo's
security:
Password stored as pl
Clive McBarton wrote:
Very interesting point. Indeed running fsck when the shutdown was clean
seems pointless.
Agreed, I don't think there's anything else to it.
And clearly whoever started fsck had no idea that it would take longer
and longer as drives got newer.
We should probably note th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob McGowan wrote:
> This brings up the question, though, as to why these forced checks are
> done in the first place. The man page talks about failed hardware and
> kernel bugs, etc., but ...
Very interesting point. Indeed running fsck when the shut
Mario 'BitKoenig' Holbe wrote:
> Clive McBarton wrote:
>> and while the system is turned off. The "online to offline" comparison
>> works fine, whereas the "offline to online" does not always work, hence
>
> What exactly does "not always" mean?
> Maybe it's just the periodic fsck which changes th
On one of the hardware platforms that I support, namely running Debian in
a virtual machine under z/VM (s390/s390x architecture) there is a
very simple solution to this whole problem: make the /boot partition
a read-only minidisk. That way, the hypervisor (the CP component
of z/VM) does not allow
thib wrote:
I'd really look at the boot loader now.
Which I did. It's not it. Grub doesn't touch anything.
For the record, I fired up a VM and tried, on *squeeze*:
ext2 / grub2
ext2 / grub1
ext3 / grub1
Mount time never changed, checksums were always identical.
The filesystem was mo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Brockway wrote:
> Hi Clive. I've never used diff to compare binary files.
>
> Is the md5sum of the different files the same?
diff works fine on binary, why shouldn't it? The output is empty or
"binary files differ". I never bothered to verify
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Brockway wrote:
> Are you concerned about corruption
Filesystem corruption? Not at all. It's a read-only partition. It cannot
go corrupt unless the disk breaks.
> or someone (with root) compromising your kernel image
Indeed.
> Also even if /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Hector wrote:
> On Mon, 2010-03-08 at 23:11 +0100, Clive McBarton wrote:
>
>> When I reboot, the partition /boot (it is a separate partition, not a
>> directory) changes. It is not supposed to. None of the files on it have
>> changed or can ch
On Wed, 10 Mar 2010 17:30:04 -0500 (EST), thib wrote:
> You can find the ext3_super_block data structure in linux/ext3_fs.h[1], line
> 444 in current mainline 2.6.
>
> I noted:
> ...
> __le32 s_mtime;/* Mount time */
> /*30*/__le32 s_wtime;/* Write
Clive McBarton wrote:
There may be software out there but I don't know of any, particularly
such that can check partitions, just software that merely checks files.
Well I would prefer that software to be aware of the filesystem, actually,
it doesn't add much more complexity and removes superbl
Clive McBarton wrote:
Ron Johnson wrote:
Note that "Last write time:" might not mean what you think it does. I
say that because on my system /dev/sda2 is / and I've written a whole
bunch of data to it in the past 25.5 days, yet the LWT still matches the
LMT.
Very interesting. I wasn't surpris
On Mon, 2010-03-08 at 23:11 +0100, Clive McBarton wrote:
> When I reboot, the partition /boot (it is a separate partition, not a
> directory) changes. It is not supposed to. None of the files on it have
> changed or can change, since it is mounted with option "ro". But the
> checksum of the partit
On Thu, 11 Mar 2010, Robert Brockway wrote:
The filesystem sees no distinction between mounting during boot or mounting
any other time. It does increment the mount count. I even went and
confirmed this on one of my systems. Same situation - ext3 /boot.
Hmm I knew I should have read to the
On Tue, 9 Mar 2010, Clive McBarton wrote:
umount /boot; mount /boot; dd_rescue /dev/sda1 /tmp/boot1;
umount /boot; mount /boot; dd_rescue /dev/sda1 /tmp/boot2;
diff /tmp/boot1 /tmp/boot2
Hi Clive. I've never used diff to compare binary files.
Is the md5sum of the different files the same?
On Tue, 9 Mar 2010, Clive McBarton wrote:
Yes, of course. I mean "md5sum /dev/sda1".
Hi Clive. If you don't mind me asking, why are you doing this? Are you
concerned about corruption or someone (with root) compromising your kernel
image, or perhaps something else?
Also even if /boot was
On Mon, 8 Mar 2010, Ron Johnson wrote:
grub (and maybe lilo) never used to be able to boot from an xfs partition.
Grub can boot from xfs now. Lilo always could. If you install xfs as the
root filesystem on older versions of Debian Stable the installer is smart
enough to realise that Grub w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mario 'BitKoenig' Holbe wrote:
> Clive McBarton wrote:
>> and while the system is turned off. The "online to offline" comparison
>> works fine, whereas the "offline to online" does not always work, hence
>
> What exactly does "not always" mean?
That
Clive McBarton wrote:
> and while the system is turned off. The "online to offline" comparison
> works fine, whereas the "offline to online" does not always work, hence
What exactly does "not always" mean?
Maybe it's just the periodic fsck which changes the mount count?
Check your fstab for the l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
>>> Would you care to share your solution, Clive?
>>
>> Currently I take checksums of the partition regularly during operation
>> and while the system is turned off. The "online to offline" comparison
>> works fine, whereas the "offline to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Johnson wrote:
> Note that "Last write time:" might not mean what you think it does. I
> say that because on my system /dev/sda2 is / and I've written a whole
> bunch of data to it in the past 25.5 days, yet the LWT still matches the
> LMT.
Very
On 2010-03-10 18:58, Clive McBarton wrote:
Ron Johnson wrote:
# dumpe2fs -h /dev/sda2 | grep time
dumpe2fs 1.41.10 (10-Feb-2009)
Last mount time: Sat Feb 13 08:39:01 2010
Last write time: Sat Feb 13 08:39:01 2010
Great command. Good to know it.
I used that and found out th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Johnson wrote:
> # dumpe2fs -h /dev/sda2 | grep time
> dumpe2fs 1.41.10 (10-Feb-2009)
> Last mount time: Sat Feb 13 08:39:01 2010
> Last write time: Sat Feb 13 08:39:01 2010
>
Great command. Good to know it.
I used that and fou
Ron Johnson wrote:
On 2010-03-10 16:30, thib wrote:
Maybe I missed something relevant.
# dumpe2fs -h /dev/sda2 | grep time
dumpe2fs 1.41.10 (10-Feb-2009)
Last mount time: Sat Feb 13 08:39:01 2010
Last write time: Sat Feb 13 08:39:01 2010
I will not comment on this.
..
Of
On 2010-03-10 16:30, thib wrote:
Stephen Powell wrote:
Actually, that could be an important clue. Perhaps the "last mount date"
is what is being updated. And since both mounts were on the same day,
the date did not change. But if you reboot tomorrow ...
I don't know if that's it, of course.
Stephen Powell wrote:
Actually, that could be an important clue. Perhaps the "last mount date"
is what is being updated. And since both mounts were on the same day,
the date did not change. But if you reboot tomorrow ...
I don't know if that's it, of course. It's just a theory at this point.
Clive McBarton wrote:
The "online to offline" comparison has value, just the "offline to
online" comparison does not. More precisely: You never know if any
checksums taken on a running system are reported correctly. But: If you
take an online system (powered up), take checksums of important files
On Wed, 10 Mar 2010 15:24:48 -0500 (EST), Clive McBarton wrote:
> Cameron Hutchison wrote:
>> If it were me trying to diagnose this, I would be diffing the images
>> that should be the same and seeing where they are different.
>
> OK. I tried that. Unfortunately more rebooting did not produce any n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cameron Hutchison wrote:
> If it were me trying to diagnose this, I would be diffing the images
> that should be the same and seeing where they are different.
OK. I tried that. Unfortunately more rebooting did not produce any new
change in the boot pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> Sorry, I meant, how would you run the hashing program before the
> reboot? I think it has little value if it's ran by the live system
> beeing checked. Sames goes for a check after the actual boot - only a
> hypervising or external syste
Clive McBarton writes:
>Stephen Powell wrote:
>> 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.
>I assume you mean "atime", which ex
On Tue, 9 Mar 2010 18:50:59 -0500 (EST), Clive McBarton wrote:
> Stephen Powell wrote:
>> But the
>> boot loader doesn't know that Linux is going to mount the filesystem
>> read-only.
>
> That's a highly interesting point. It doesn't? I thought everything in
> the boot process mounts everything i
Clive McBarton wrote:
I'm not saying grub cannot do it, but I do see a reason:
grub has its config in a *file*. By default anyway. Something called
menu.lst which controls how the grub display looks like and so on. When
grub loads, it loads this file first. There are also other files, like
devic
Clive McBarton wrote:
Up to now, I never heard of any advantage whatsoever of ext2 over ext3.
ext3 now differs from ext2, aside from the journal. We can run ext3 without
one, so there's no real reason to continue to use ext2. One could say the
same thing about ext3 and ext4, actually, but t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> Clive McBarton wrote:
>>> For the record, grub can also load a kernel and an initrd by just
>>> providing a block list, as you described for lilo. Since the filesystem
>>> is made read-only, this shouldn't be too ugly and certainly worth
Clive McBarton wrote:
For the record, grub can also load a kernel and an initrd by just
providing a block list, as you described for lilo. Since the filesystem
is made read-only, this shouldn't be too ugly and certainly worth trying.
Really? Great. How exactly? I looked at the man and info pag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> 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.
Great! Spect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> For the record, grub can also load a kernel and an initrd by just
> providing a block list, as you described for lilo. Since the filesystem
> is made read-only, this shouldn't be too ugly and certainly worth trying.
Really? Great. How e
Stephen Powell wrote:
You might try switching to lilo as your boot loader and see if that
solves your problem. I use lilo as my boot loader and have for a long
time. I may be able to assist you if you have difficulty.
For the record, grub can also load a kernel and an initrd by just providing
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
>
> roMount filesystem read only. Note that ext3 will replay
> the jour
On Tue, 9 Mar 2010 14:02:48 -0500 (EST), thib wrote:
> Bob McGowan wrote:
>> On further consideration, there are other places where things could be
>> happening, before the "system" is fully started, meaning before the
>> 'mount' options you're using would have any effect.
>>
>> These don't necess
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 onl
Bob McGowan wrote:
On further consideration, there are other places where things could be
happening, before the "system" is fully started, meaning before the
'mount' options you're using would have any effect.
These don't necessarily do anything (in the "write" sense ;), but are
places to consid
Ron Johnson wrote:
On 2010-03-09 02:58, thib wrote:
Ron Johnson wrote:
I'd hash each of the files in /boot (storing the results in a thumb
drive if you are paranoid) just before you reboot and then just after.
How would you do it after with an offline system? That would require
to systemati
On 2010-03-09 02:58, thib wrote:
Ron Johnson wrote:
I'd hash each of the files in /boot (storing the results in a thumb
drive if you are paranoid) just before you reboot and then just after.
How would you do it after with an offline system? That would require to
systematically run the machin
Clive McBarton wrote:
> Bob McGowan wrote:
>> It is almost certainly the mount count.
>
> I just manually unmounted and mounted the device a few times. With the
> arguments I have in fstab ("ro","noatime"). In other words, I did
>
> umount /boot; mount /boot; dd_rescue /dev/sda1 /tmp/boot1;
> umo
Ron Johnson wrote:
I'd hash each of the files in /boot (storing the results in a thumb
drive if you are paranoid) just before you reboot and then just after.
How would you do it after with an offline system? That would require to
systematically run the machine in a virtualized environment (an
On 2010-03-08 22:24, Clive McBarton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
Well, ask the
developers of whatever is touching it. If noboby knows, that will
require some code digging.
But I don't know what is touching it. That's what this thread is about.
It's about m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> Well, ask the
> developers of whatever is touching it. If noboby knows, that will
> require some code digging.
But I don't know what is touching it. That's what this thread is about.
It's about me asking what is touching it. All I know
Clive McBarton wrote:
thib wrote:
maybe it would be acceptable to ask for a new little switch.
Or hack ext3.
Ask who? The maintainers of tune2fs? The maintainers of ext3? Both will
say what I already know, that manually mounting and unmounting an ext3
partition read-only does not modify it in
Clive McBarton wrote:
thib wrote:
Maybe someone simply has reasons not to put /boot on a separate volume.
Now I sure agree that it isn't needed in virtually every other cases,
but would it really hurt?
We are already discussing this in your thread "Single root filesystem
evilness decreasing i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> maybe it would be acceptable to ask for a new little switch.
> Or hack ext3.
Ask who? The maintainers of tune2fs? The maintainers of ext3? Both will
say what I already know, that manually mounting and unmounting an ext3
partition read-on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> Maybe someone simply has reasons not to put /boot on a separate volume.
> Now I sure agree that it isn't needed in virtually every other cases,
> but would it really hurt?
We are already discussing this in your thread "Single root files
Ron Johnson wrote:
grub (and maybe lilo) never used to be able to boot from an xfs partition.
Grub is doing fine, although it's true it had some issues in the past (just
read about them, actually). Can't talk about lilo.
As for the shiver, I also am confused. A 64MB partition, though, real
Clive McBarton wrote:
OK, I studied the tune2fs manpage. I found that it controls what happens
when a certain mount count or mount interval is reached. Which requires
mount count and time to be already stored in the filesystem. What I need
is not to prevent the reaction to this data (count and ti
On 2010-03-08 18:35, thib wrote:
Aioanei Rares wrote:
xfs as a /boot partition?
Why not?
[This is so going off topic.]
grub (and maybe lilo) never used to be able to boot from an xfs
partition.
As for the shiver, I also am confused. A 64MB partition, though,
really doesn't need a hig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> I would suggest going through the tune2fs(8) manpage and find
> out what could be.. tuned. You know what? I think your first
> suggestion is a good one - look at the mount count configuration for a
> starter.
OK, I studied the tune2fs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob McGowan wrote:
> It is almost certainly the mount count.
I just manually unmounted and mounted the device a few times. With the
arguments I have in fstab ("ro","noatime"). In other words, I did
umount /boot; mount /boot; dd_rescue /dev/sda1 /tmp/
thib wrote:
Clive McBarton wrote:
Good point, that is probably important. ext3.
Well then I would suggest going through the tune2fs(8) manpage and
find out what could be.. tuned. You know what? I think your first
suggestion is a good one - look at the mount count configuration for a
star
On 03/09/2010 02:35 AM, thib wrote:
Aioanei Rares wrote:
xfs as a /boot partition?
Why not?
[This is so going off topic.]
-thib
Ok, so let's prevent this and end the thread. :-)
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
On Mon March 8 2010 16:28:40 Clive McBarton wrote:
> I do NO write operation whatsoever on it. It is not allowed to change in
> ANY way.
It's probably not that large. Save a few copies with dd and see
where they differ. Might turn up a clue.
--Mike Bird
--
To UNSUBSCRIBE, email to debian-us
Aioanei Rares wrote:
xfs as a /boot partition?
Why not?
[This is so going off topic.]
-thib
--
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/4b9597be.80...@stamm
Clive McBarton wrote:
Good point, that is probably important. ext3.
Well then I would suggest going through the tune2fs(8) manpage and find out
what could be.. tuned. You know what? I think your first suggestion is a
good one - look at the mount count configuration for a starter.
If noth
On 03/09/2010 02:30 AM, Clive McBarton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Moore wrote:
Is this checksum failing for every file, or just some?
It's the checksum for the partition that changes. I don't have checksums
of the individual files but since the metad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Moore wrote:
> Is this checksum failing for every file, or just some?
It's the checksum for the partition that changes. I don't have checksums
of the individual files but since the metadata of every single file
stays the same, presumably so do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
thib wrote:
> I'm guessing OP literally checksums the volume from the block device.
Yes, of course. I mean "md5sum /dev/sda1".
> If I'm right, it could be anything, really, lots of filesystem metadata
> moving around without actually touching any fi
On 03/09/2010 02:09 AM, Ron Johnson wrote:
On 2010-03-08 17:50, thib wrote:
Aioanei Rares wrote:
How do you check this "checksum of the partition" ?
I'm guessing OP literally checksums the volume from the block
device. If I'm right, it could be anything, really, lots of
filesystem metadata
On 2010-03-08 17:50, thib wrote:
Aioanei Rares wrote:
How do you check this "checksum of the partition" ?
I'm guessing OP literally checksums the volume from the block device.
If I'm right, it could be anything, really, lots of filesystem metadata
moving around without actually touching any
Aioanei Rares wrote:
How do you check this "checksum of the partition" ?
I'm guessing OP literally checksums the volume from the block device. If
I'm right, it could be anything, really, lots of filesystem metadata moving
around without actually touching any file contents (access times, for
On Monday March 8 2010 3:11:05 pm Clive McBarton wrote:
> When I reboot, the partition /boot (it is a separate partition, not a
> directory) changes. It is not supposed to. None of the files on it have
> changed or can change, since it is mounted with option "ro". But the
> checksum of the partitio
On 03/09/2010 12:11 AM, Clive McBarton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I reboot, the partition /boot (it is a separate partition, not a
directory) changes. It is not supposed to. None of the files on it have
changed or can change, since it is mounted with option "ro". B
72 matches
Mail list logo
