[comp.os.minix] Desperate help needed with my hard disk

greg@viewlogic.com (Gregory Larkin) (02/27/91)

[NOTE: This was originally rejected by the list server]

Hello,

Somehow, for the nth time, I have managed to trash the super block of
one of my hard disk partitions.  Is there any way I can restore the
super block?  This partition contains my entire source tree, and would
be very time consuming to replace.  "fsck -r /dev/hd6" reports "bad
magic number in super block - fatal".

Could the super block be trashed if the start sector is not even? I
remember seeing this as an incompatibility between 1.3 and 1.5.  The
super block somehow got trashed around the time when I first booted
minix 1.5 up from a shoelace diskette (i.e. loaded on the fly).

related question:  say I have 3 HD partitions mounted.  I log out. Is
	 	   it safe to reboot at this time, or must all
		   partitions be umounted first?

How can this problem be prevented forever??

Thanks,
--
Greg Larkin (ASIC Engineer)
Viewlogic Systems, Inc. (The CAE Company)
293 Boston Post Road West ____________________________________________
Marlboro, MA 01752        |"This is a fragile ball we are living on; |
508 480 0881 x321         |it's a miracle and we are destroying it.."|
Email: greg@Viewlogic.COM |Peter Garrett, Midnight Oil               |
                          --------------------------------------------

cechew@sol1.cs.monash.edu.au (Earl Chew) (02/28/91)

greg@viewlogic.com (Gregory Larkin) writes:


>Somehow, for the nth time, I have managed to trash the super block of
>one of my hard disk partitions.  Is there any way I can restore the
>super block?  This partition contains my entire source tree, and would

I don't think so... not unless you have a block-by-block backup of the file
system. Don't you have a back up for the source tree?

>Could the super block be trashed if the start sector is not even? I

I don't think so. 1.5.10 will refuse to see the file system if this is the
problem (ie you couldn't have mounted it in the first place). Then again, you
could have been extremely clever...

>related question:  say I have 3 HD partitions mounted.  I log out. Is
>	 	   it safe to reboot at this time, or must all
>		   partitions be umounted first?

No. You must sync all file systems before rebooting. I also unmount all file
systems before sync().

>How can this problem be prevented forever??

Get the shutdown script. It does all of this for you.

Earl
--
Earl Chew, Dept of Computer Science, Monash University, Australia 3168
EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655778 FAX: 03 5655146
----------------------------------------------------------------------

hp@vmars.tuwien.ac.at (Peter Holzer) (03/06/91)

cechew@sol1.cs.monash.edu.au (Earl Chew) writes:

>greg@viewlogic.com (Gregory Larkin) writes:

>>related question:  say I have 3 HD partitions mounted.  I log out. Is
>>	 	   it safe to reboot at this time, or must all
>>		   partitions be umounted first?

>No. You must sync all file systems before rebooting. I also unmount all file
>systems before sync().

If I remember correctly the main loop of init contains a sync ()
just after the wait (). So the disks are synced every time you
log out (and also every time a process exits whose parent does
not exist anymore).

That reminds me of a problem I recently had (well I still have
it, but I am ignoring it). When I ran fsck on my root
partition, it discovered a few inodes with NLINKS != COUNT. The
inodes are not referenced in any directory, and when I ran fsck
repeatedly with -a, both NLINKS and COUNT were decremented by 24
(mod 256) each time.

Any ideas?

--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |

paul@ukpoit.co.uk (Paul Wood) (03/08/91)

In article <2365@tuvie.UUCP> hp@vmars.tuwien.ac.at (Peter Holzer) writes:

>If I remember correctly the main loop of init contains a sync ()
>just after the wait (). So the disks are synced every time you
>log out (and also every time a process exits whose parent does
>not exist anymore).

Hmmm ... I am running MacMinix, and if I edit a file with vi, quit vi, quit
MacMinix and then restart, I will get a problem with the file I was editting.
( there have been a few postings recently describing this problem )
However, if I sync prior to quitting, then no problem occurs.

It would appear that Minix is not syncing prior to quitting. This may be a 
problem specific to MacMinix. Help anybody?

paul@ukpoit.co.uk                                Paul Wood, 31 Buttermere Drive,
                                                 Dronfield Woodhouse, Sheffield,
                                                 England, S18 5PX.
-- 
Paul Wood       | UUCP Mail:  paul@ukpoit.co.uk   | iT: The Information
iT (Unix Group) | Bang-Style: ...!ukc!ukpoit!paul |     Technology Business of
Barker Lane     | Voice:      +44 246 214256      |     the UK Post 0ffice
Chesterfield    | FAX:        +44 246 214353      |

klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (03/12/91)

In <2365@tuvie.UUCP> hp@vmars.tuwien.ac.at (Peter Holzer) writes:

>cechew@sol1.cs.monash.edu.au (Earl Chew) writes:

>>greg@viewlogic.com (Gregory Larkin) writes:

>>>related question:  say I have 3 HD partitions mounted.  I log out. Is
>>>	 	   it safe to reboot at this time, or must all
>>>		   partitions be umounted first?

>>No. You must sync all file systems before rebooting. I also unmount all file
>>systems before sync().

In the umount() call is a sync() inclusive -- so if you unmounted all 
non-volatile file systems (all but /dev/ram) you don't have to sync
any more.
(Side note -- i only sync, and do not umount. Can't because / == harddisk.
	      Never encounter any problems, though )

Klamer
-- 
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl	{backbone}!mcsun!mi.eltn.utwente.nl!klamer