Re: What causes bad inodes?
On Mon, Mar 10, 2008 at 09:34:14PM +0000, postid wrote:
> Douglas A. Tutty wrote:
> >On Sun, Mar 09, 2008 at 07:57:03PM +0000, postid wrote:
> >
> >>Douglas A. Tutty wrote:
> >>>On Sun, Mar 09, 2008 at 03:59:45PM +0000, postid wrote:
> >>>The magic keystrokes just sync the disks, they do not unmount the
> >>>filesystems. Thus, things can become corrupted. If it were me, after
> >>>such a reboot, I'd come up in init=/bin/sh and run fsck manually.
> >>
> >>Please pardon my ignorance here, but what do you mean by "come up
> >>in init=/bin/sh"?
> >
> >Edit the kernel command line, add init=/bin/sh
> >When the kernel boots, instead of runing /bin/init, it will run /bin/sh
> >and give you a shell, no password required.
>
> Isn't this a bit of a security breach? Anyone booting my laptop
> would have potential access to my files. Would a person using
> this shell have root privileges?
Yes it is a security breach, and yes you get root. For a laptop, you
should protect grub with a password. If you are concerned someone will
read /boot/grub/menu.list, then that password should be hashed in that
file. See the grub book for details.
Basically, with grub password protected, a user can boot any of the menu
items without a password. However, to edit any of the boot parameters
or to get to a grub command line (where you can boot anything you want),
you need to enter the grub password.
Notice that this is only helpful if your bios doesn't already allow
someone to insert a CD (e.g. Knoppix) and boot that without entering a
password.
> I suppose I could just use a Knoppix CD to edit the line only
> when needed.
If you can do that without a password, so can anyone else. The
advantage of doing it from init=/bin/sh is that then its the same
version of filesystem tools on the same kernel as the system.
> > No initscripts will have
> >run so only the root fs will be mounted ro, the other filesystems will
> >not be mounted at all. This is one reason why its good to have separate
> >filesystems. Keeps the / fs small and unlikely to be corrupted.
> >
> So at that point I run fsck, right?
Yes, using whatever parameters are appropriate. You may want to run man
to a file in /root so that you can view the man page for e.g. e2fsck.
> >>>Ideally, you'd use ext3 with data=journal. That way, syncing the disks
> >>>will get the data _somewhere_ on the disk so that replaying the journal
> >>>in a normal boot fsck would set things right.
> >>>
> >>
> >>Again, my apologies, this time for not supplying more complete
> >>info. I'm using ext3, running Sarge on an IBM R40 laptop along
> >>with Knoppix (hd install) and WinXP (for encrypted DVDs.
> >
> >I've never used Knoppix so I don't know what mode they use for ext3.
> >Debian by default only journals metadata not your actual data. Its
> >supposed to guarantee that the filesystem stays consistant in the event
> >of an unclean shutdown but your data is at risk. data=journal means
> >that your data is journaled as well. See the man pages.
> >
> Am I therefore risking the system files but saving the data if I
> data=journal?
No, data=journal journals both data and metadata, but this takes a bit
more time so is slower. Check your man page because data=journal may be
the default in Sarge.
> >>>Well, ideally, the system should be stable enough not to need a reboot.
> >>>If this is Etch, check for bug reports.
> >
> It's Sarge. I'm in a busy time of year and don't have time to
> upgrade yet.
You do know that Etch has been out for a year and that security support
either has ended or is about to end? There have been several kernel
updates to Etch for security breaches, plus the usual other security
updates.
> >Can you update a Knoppix hd-install or do you just reinstall a newer
> >knoppix?
> >
> I don't think it updates. Knoppix is based on Debian, but is
> really not meant for use on other than a CD or DVD. I installed
> it long ago to check out some unstable features and just have
> never gotten rid of it.
Then your laptop is unsecure and some of your difficulties could be
caused by it being breached.
> >>>If the hard drive is dying, there should be some errors in
> >>>/var/log/syslog. Also, install smartmontools so that you can check the
> >>>S.M.A.R.T. data on the drives. If smart tells you that the drive is
> >>>failing then believe it. If it tells you that everything is fine, take
> >>>it with a grain of salt. Always have good backups.
> Installed smartmontools today. Thanks for the advice.
>
> postid
Good luck.
Doug.
Reply to: