Monadnock Linux User Group - July 14th

2005-07-13 Thread guy Pardoe
The next meeting of the Monadnock Linux User Group (MonadLUG) will be this
Thursday, July 14th, 7:00pm, at the SAU 1 Superintendent's Office behind
South Meadow School in Peterborough.

This is a combined meeting with CentraLUG (of the Concord area) and will
feature guest speaker Ira Krakow, discussing WINE and running Windows
applications on Linux.




 AGENDA 

1.  Announcements.

2.  An overview of Wine, which enables Windows applications to run in Linux,
and Winelib, which enables Windows application sources to compile and run on
Linux.
Ira discusses Wine and Winelib, which make it possible to run some
Windows applications on Linux, and to more easily port applications that
were originally written for a Windows platform.
He'll also touch on other projects that can help an enterprise overcome
its Windows dependencies, such as ReactOS (the open source port of Windows
NT), MinGW (the port of GCC for Windows programs), and Mono (essentially,
Wine for .NET and C#). Ira is currently co- authoring a book for
Prentice-Hall, on Wine and Winelib; his co- author is Brian Vincent.

3.  Adjourn to Harlow's.

*


We're also looking for topics for future meetings.  If you have a suggestion
or would like to present a topic yourself, please contact me at
[EMAIL PROTECTED]

Please forward this announcement to anyone you think may be interested in
attending.  

Thank you,

Guy Pardoe
MonadLUG Coordinator

___
gnhlug-announce mailing list
gnhlug-announce@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Boston Linux Meeting Wednesday, July 20, 2005

2005-07-13 Thread Jerry Feldman
When: July 20, 2005 7:00PM (6:30 for Q&A)
Topic: Assorted topics
Moderator: BLU members
Location:  MIT Building E51 Room 315
Rajiv Manglani  will be presenting and intro on Ruby on Rails. "Rails is
a full-stack, open-source web framework in Ruby for writing real-world
applications with joy and less code than most frameworks spend doing
XML sit-ups." http://www.rubyonrails.com/

David Kramer will be presenting and overview of jEdit, a programmer's
text editor:
http://sourceforge.net/projects/jedit/


-- 
Jerry Feldman <[EMAIL PROTECTED]>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9


pgp8zxTkGgLMW.pgp
Description: PGP signature


Re: access beyond end of device?

2005-07-13 Thread Benjamin Scott

On Jul 13 at 11:08am, Bill McGonigle wrote:
Right.  If you assume a filesystem was truncated.  I was assuming a bad 
partition table lead mkfs to create an incorrect superblock which lead to an 
inode with an invalid data block location.


  mke2fs writes to the end of the device, so if the device ends prematurely, 
mke2fs will abort and you don't get a filesystem.  So that's not it.


  Sample output of a test I just performed, using a 16 MiB loopback device 
(irrelevant output trimmed for brevity):



<

$ mke2fs /dev/loop0 16384
mke2fs 1.36 (05-Feb-2005)
4096 inodes, 16384 blocks
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
$

$ mke2fs /dev/loop0 16385
mke2fs 1.36 (05-Feb-2005)
mke2fs: Filesystem larger than apparent device size.
Proceed anyway? (y,n) y
4096 inodes, 16385 blocks

Writing inode tables: 0/2
Could not write 8 blocks in inode table starting at 69: Attempt to write block 
from filesystem resulted in short write
$ 

<


Does e2fsck validate the existence of blocks in the ext2 allocation bitmap 
without trusting the partition table?


  Well, e2fsck doesn't know about partition tables.  It asks the kernel how 
big the device is.  Of course, the kernel mainly uses the partition table to 
determine device size, but I don't think it will let you have a partition 
bigger then the containing block device.


  But let's say a filesystem does get truncated somehow.  What happens?

  I created my test filesystem on a loopback device of 16 MiB.  fsck works 
fine.  I undid the loop dev and used "dd" to copy the image, but 1024 bytes 
short.  I then looped that and ran e2fsck.  The results are interesting:



<

$ e2fsck /dev/loop0
e2fsck 1.36 (05-Feb-2005)
The filesystem size (according to the superblock) is 16384 blocks
The physical size of the device is 16383 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
/dev/loop0 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop0: 11/4096 files (9.1% non-contiguous), 661/16384 blocks
$

<


  So it correctly identified the problem, but when told to do the check 
anyway, passed the filesystem as okay!


  Even more bizarre: If I try to copy a large file into that filesystem, it 
fails with ENOSPC (No space left on device), reports the filesystem as 
(practically) full, but otherwise appears to be okay.  I expected the 
filesystem driver to consider this error serious enough to remount-ro (which 
is the error behavior I set with tune2fs).  I saw the following in the kernel 
log:



<

attempt to access beyond end of device
loop0: rw=1, want=32768, limit=32766
Buffer I/O error on device loop0, logical block 16383
lost page write due to I/O error on loop0

<


  e2fsck still passes the filesystem, too!  (Other then the warning about the 
size mismatch, which is, admittedly, pretty serious.)


  I can only assume (1) there is no important metadata in the last block of 
the device and (2) when the filesystem driver gets a premature EOF on the 
write, it just fails the call as if the filesystem was "normally full". 
Still, I'm not sure I would call this "expected behavior".


  Finally, I tried truncating the loop image to 1 MiB (losing 15 of the 
original 16 MiB).  *That* resulted in immediate puke from e2fsck, even if I 
forced it to continue.



I'm hoping we'll get a report when the cause is determined.


  Indeed!

--
Ben <[EMAIL PROTECTED]>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Laptop HD help (Tom or Ben, please read this one)

2005-07-13 Thread Travis Roy

Damn, it's DEAD!

That actually worked, I was able to mount it, but once I tried to go 
anywhere on the drive I got the click of doom.


Ben or Tom, do you have the contact info of that hard drive place we 
would send drives to for Net Tech. My brother wants to go that route, 
the drive had all his books for his business on it.



Have you considered booting the laptop up with a Knoppix disk and
offloading the data to a network share?  Or is the laptop itself dead?
-N



My brother's laptop HD is dying.. Anybody have a 2.5" to 3.5" HD adapter
so I can save the day and get the data off the drive..

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss




___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Laptop HD help

2005-07-13 Thread Travis Roy

Ohhh, that's a good idea.

The drive is starting to click, and being the typical computer user, he 
has no backups.. It doesn't click often so there is probably hope to get 
most of the stuff off before it totally dies off.




Have you considered booting the laptop up with a Knoppix disk and
offloading the data to a network share?  Or is the laptop itself dead?
-N



My brother's laptop HD is dying.. Anybody have a 2.5" to 3.5" HD adapter
so I can save the day and get the data off the drive..

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss




___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Laptop HD help

2005-07-13 Thread Neil Schelly
Have you considered booting the laptop up with a Knoppix disk and
offloading the data to a network share?  Or is the laptop itself dead?
-N

> My brother's laptop HD is dying.. Anybody have a 2.5" to 3.5" HD adapter
> so I can save the day and get the data off the drive..
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
>

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Laptop HD help

2005-07-13 Thread Travis Roy
My brother's laptop HD is dying.. Anybody have a 2.5" to 3.5" HD adapter 
so I can save the day and get the data off the drive..


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: access beyond end of device?

2005-07-13 Thread Bill McGonigle

On Jul 13, 2005, at 02:21, Benjamin Scott wrote:

  In other words, if I have my 3 TiB filesystem that sudden gets 
truncated at 90 GiB, all the filesystem metadata that was past 90 GiB 
is now gone, leaving a gaping hole in the filesystem's internal data 
structures.


Right.  If you assume a filesystem was truncated.  I was assuming a bad 
partition table lead mkfs to create an incorrect superblock which lead 
to an inode with an invalid data block location.


Does e2fsck validate the existence of blocks in the ext2 allocation 
bitmap without trusting the partition table? That would be a useful 
test but my Google-fu isn't strong enough to find out.  An 'fsck -c' 
might force it to.


I'm hoping we'll get a report when the cause is determined.

-Bill
-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Mobile: 603.252.2606
http://www.bfccomputing.com/Pager: 603.442.1833
AIM: wpmcgonigleText: [EMAIL PROTECTED]

For fastest support contact, please follow:
http://bfccomputing.com/support_contact.html

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss