Re: fdisk message error

2001-09-12 Thread Thomas Duffy
On Wed, 2001-09-12 at 13:18, Roberto Giorgetti wrote:

> Have I to create a /dev/hda3 from 0 to 16706 before? If yes how is
> this possible? I cannot put 0 as "First cylinder" (Value out of
> range). I can only put value equal or greater to 8842 as "First
> cylinder".

well, I would suggest nuking the partition table and created a new sun
label...choosing the defaults for custom will create 1, 2, and 3.  then
you can delete 1 and 2 and make them the correct size for you, maybe
adding part 4.

if you have data on these drives, then you could try to match the
numbers up exactly and try to remount the partitions once you
reconfigure.  I would backup your important stuff before attempting
this, though :)

the r flag means the partition is mountable...not an issue.  you can
turn it off and on using the "c" option in fdisk if you do not like it
there. i don't think it is used under linux.

you can go into expert mode (x) and verify (v) the partition table is ok
maybe?...

-tduffy



Re: fdisk message error

2001-09-12 Thread Roberto Giorgetti
Thank you Tom for your answer. (Also to Hakan for his one, I
subscribe his question about the 'r'-Flag meaning).

Maybe I didn't understand well how I have to proceed. In fact
starting from the situation:

--
   Device FlagStart   EndBlocks   Id  System
/dev/hda1   r 0  8322   4194288   83  Linux native
/dev/hda2  8322  8842262080   82  Linux swap
--

I created a /dev/hda4 partition as Linux native. But I received
the same error message when I wrote it to the partition table and
when I reboot the new partition disappears.

Have I to create a /dev/hda3 from 0 to 16706 before? If yes how is
this possible? I cannot put 0 as "First cylinder" (Value out of
range). I can only put value equal or greater to 8842 as "First
cylinder".

Thank you also to Hakan for his reply 

Roberto Giorgetti


On Wed, Sep 12, 2001 at 09:27:37AM -0700 or thereabouts, Thomas Duffy wrote:
> On Tue, 2001-09-11 at 13:12, Roberto Giorgetti wrote:
> 
> > --
> >Device FlagStart   EndBlocks   Id  System
> > /dev/hda1   r 0  8322   4194288   83  Linux native
> > /dev/hda2  8322  8842262080   82  Linux swap
> > /dev/hda3  8842 16706   39634565  Whole disk
> > --
> > 
> > N.B. I followed the reccomendation to set the type of the third 
> > disk to 'Whole disk'.
> > Then I run w command to write onto the partition table and I
> > receive: 
> 
> The whole point of having the third partition being the "Whole Disk" is
> that it should be the whole disk.  Make it go from 0 to 16706.  Don't
> mount this partition.
> 
> Then create a /dev/hda4 with the rest of the space > 8842 and use that
> to mount and put data on.
> 
> -tom duffy



current vger 2.4 boot problems

2001-09-12 Thread John Wood
not exactly sure what is up, but 2.4.10-pre4 doesn't seem to want
to boot on my ultra1. 2.4.9 was fine, but 2.4.10-pre4 locks the
machine just after silo starts to load it. iirc, i am not the only
person to have this happen on an ultra1. has anyone else had problems
with current vger?


john

--
  john wood

  systems administrator, gmo inc 



Re: fdisk message error

2001-09-12 Thread Thomas Duffy
On Tue, 2001-09-11 at 13:12, Roberto Giorgetti wrote:

> --
>Device FlagStart   EndBlocks   Id  System
> /dev/hda1   r 0  8322   4194288   83  Linux native
> /dev/hda2  8322  8842262080   82  Linux swap
> /dev/hda3  8842 16706   39634565  Whole disk
> --
> 
> N.B. I followed the reccomendation to set the type of the third 
> disk to 'Whole disk'.
> Then I run w command to write onto the partition table and I
> receive: 

The whole point of having the third partition being the "Whole Disk" is
that it should be the whole disk.  Make it go from 0 to 16706.  Don't
mount this partition.

Then create a /dev/hda4 with the rest of the space > 8842 and use that
to mount and put data on.

-tom duffy





Invitation to the 6th Linux Developers Meeting in Oldenburg

2001-09-12 Thread Martin Schulze

  -
  6th Linux Developers Meeting in Oldenburg


   Thursday, September 27th to Sunday, 30th


   University of Oldenburg, Wechloy
  -


This is the public invitation for Linux developers to attend this
years' Linux Developers Meeting in Oldenburg.  The scope of this
meeting is to port Linux to non-intel architectures. It is derived
from the linux/m68k meeting 1995 in Solingen , though, recently there
were a lot of other architectures as well.

Just like the last years, the purpose of this meeting is to get as
much of the Linux/m68k core developers and active users together to
discuss current problems, show off projects, exchange news, and
generally to have fun.

Like last year, the meeting will take place from thursday afternoon
(September 27th) to sunday evening (September 30th).  You don't have
to attend from thursday, it's an offer for those of you who would like
to and who can afford coming early.  If you can't make it that early,
just join when you can afford it.  The meeting will take place at the
same place like last year (that is University of Oldenburg, Wechloy).

For those of you, who don't know Oldenburg yet, it's in the northern
part of Germany.  That means, you'll find lots of green areas (trees,
meadows etc.), good air and less industries.  The meeting will be held
at the science building of the University of Oldenburg, in Oldenburg
Wechloy.

If you would like to attend the meeting, please send back this form,
so I can calculate space, power, food and stuff.  Space, power and
connectivity will thankfully be sponsored by the University, food and
stuff will be sponsored by ffis e.V., except dinner in restaurants.
We will be able to use showers inside of the sport building.

You'll need to take with you these things: machines, monitors,
technical documentation (very important), enough triple plugs for your
machines, some network cabling, some hubs/switches, sleeping bag, air
mattress, towel, shower stuff, plate, cutlery, coffee mug.

Comprehensive Information are on the web:
http://oldenburger.linuxtage.de/Oldenburg2001/

Regards,

Joey

-- 8< -- 8< -- 8< -- 8< --

Linux Developer's Meeting in Oldenburg 2001 - Sept 27th - 30th

Name  :
E-Mail:

I'd like to attend on these days:

[ ] Thursday, September 27th
[ ] Friday, September 28th
[ ] Saturday, September 29th
[ ] Sunday, September 30th

Dinner will be from 7pm - 9pm or something.  If you plan to arrive
within this period, make sure you know how to reach me mobile.

Number of machines ...:
Number of monitors ...:

Name may be placed on web page: ( ) yes
( ) no

-- 8< -- 8< -- 8< -- 8< --


pgp2NIEg3gt0C.pgp
Description: PGP signature


Re: kernel 2.4.x compile failure on Ultra 1

2001-09-12 Thread Noah Meyerhans
On Wed, Sep 12, 2001 at 03:47:20AM +0200, Ben Castricum wrote:
> I think a came across this problem as well. Try compiling the kernel with
> SMP, i think the atomic_dec_and_lock only gets exported when SMP is being
> used. Unfortunately I run accross more problems later on when trying to
> compile 2.4.9, hopefully you have more luck.

Yup, that did it.  It also turned out that I needed to enable PCI
support, despite the fact that the Ultra1 is an SBus machine.  But all
seems to be well now.

Thanks.
noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpZMOfwVw4Nw.pgp
Description: PGP signature


RE: kernel 2.4.x compile failure on Ultra 1

2001-09-12 Thread Peter Haworth
On Wed, 12 Sep 2001 03:47:20 +0200, Ben Castricum wrote:
> I think a came across this problem as well. Try compiling the kernel with
> SMP, i think the atomic_dec_and_lock only gets exported when SMP is being
> used. Unfortunately I run accross more problems later on when trying to
> compile 2.4.9, hopefully you have more luck.

I had to compile an SMP kernel to get it to work, but I didn't have any other 
problems.

-- 
Peter Haworth   [EMAIL PROTECTED]
"The only way I could enjoy DOS is if I were lobotomized"
-- Tom Christiansen



Re: Solution (Was: Sparc has slow disk access)

2001-09-12 Thread hakubw00
> 
> > time cat smalltebledefinition | psql database -> real0m0.306s
> > time psql -e database < smalltabledefinition  -> real0m0.295s
> >
> > may this 0.009s help you ;-)
> In fact, no.  But I try to find a method which keeps my sparc beeing
> faster than my PC, because I could have saved a certain amount of
> money
> if the Sun is faster in some dd commands but not in the every day
> work.
> I don´t talk about fractions of seconds.  I´m talking about half a
> minute
> or so.
I run this test on my Ultra10, but this was a tiny tabledef,
i could imagine that 'cat' ing a file and piping it can take much longer
with large tabledefs.
I mean -  give it a try.



regards
--
Hakan Kuecuekyilmaz, FHT-Esslingen   
<[EMAIL PROTECTED]>
[... University of Applied Sciences Esslingen Germany...]
collaborative encyclopedia project 


-
This mail sent through IMP: webmail.fht-esslingen.de



Re: Solution (Was: Sparc has slow disk access)

2001-09-12 Thread Tille, Andreas
On Wed, 12 Sep 2001 [EMAIL PROTECTED] wrote:

> > Sparc/Solaris:  45s
> > Sparc/Linux:35s   !! (We are really good, aren´t we?)
> > PC/Linux:   61s
>
> Gratulations
Thanks :).

> time cat smalltebledefinition | psql database -> real0m0.306s
> time psql -e database < smalltabledefinition  -> real0m0.295s
>
> may this 0.009s help you ;-)
In fact, no.  But I try to find a method which keeps my sparc beeing
faster than my PC, because I could have saved a certain amount of money
if the Sun is faster in some dd commands but not in the every day work.
I don´t talk about fractions of seconds.  I´m talking about half a minute
or so.

Kind regards

Andreas.



Re: Solution (Was: Sparc has slow disk access)

2001-09-12 Thread hakubw00

> Seems that there were not an optimal bs-default value on Sparc for
> this
> test.  If I set bs explicitely this way I got:
> 
> Sparc/Solaris:  45s
> Sparc/Linux:35s   !! (We are really good, aren´t we?)
> PC/Linux:   61s

Gratulations

> By the way it would be of course interesting, how to adjust reading
> block size in other applications than dd.  I started testing when I
> recognized that some PostgreSQL tables I created via
> 
>cat tabledefinition | psql database
> 
> took much more time than on my PC.  Moreover I´m afraid that database
> access is slower if some parts of it do not fit into memory.
> 
> Any hints how to tune that?
> 

time cat smalltebledefinition | psql database -> real0m0.306s
time psql -e database < smalltabledefinition  -> real0m0.295s

may this 0.009s help you ;-)


regards
--
Hakan Kuecuekyilmaz, FHT-Esslingen   
<[EMAIL PROTECTED]>
[... University of Applied Sciences Esslingen Germany...]
collaborative encyclopedia project 


-
This mail sent through IMP: webmail.fht-esslingen.de



Fwd: Re: fdisk message error

2001-09-12 Thread hakubw00
Hello,

first of all my condolence to all U.S. citizens, I still can not believe what
happend.


Quoting Roberto Giorgetti <[EMAIL PROTECTED]>:

> The 9Gb disk of my SUN Ultra 5 machine with Debian unstable is
> not completely used, so I run fdisk /dev/hda and p command
> receiving:
> 
> --
> Disk /dev/hda (Sun disk label): 16 heads, 63 sectors, 16706
> cylinders
> Units = cylinders of 1008 * 512 bytes
> 
>Device FlagStart   EndBlocks   Id  System
> /dev/hda1   r 0  8322   4194288   83  Linux native
> /dev/hda2  8322  8842262080   82  Linux swap
> --
> 
> Then I create a third partition in this way:
> 
> --
>Device FlagStart   EndBlocks   Id  System
> /dev/hda1   r 0  8322   4194288   83  Linux native
> /dev/hda2  8322  8842262080   82  Linux swap
> /dev/hda3  8842 16706   39634565  Whole disk
> --

The third partition has to be the "whole" disk. Your whole disk
starts at 8842 not at 0.
I still dont know what the 'r'-Flag means, can someone enlighten me?

regards
--
Hakan Kuecuekyilmaz, FHT-Esslingen   
<[EMAIL PROTECTED]>
[... University of Applied Sciences Esslingen Germany...]
collaborative encyclopedia project 


-
This mail sent through IMP: webmail.fht-esslingen.de



Solution (Was: Sparc has slow disk access)

2001-09-12 Thread Tille, Andreas
Hello,

people might remember my question about the E250 server with slower
disk access than a usual PC which I testet by some dd copying.  Now
I found a solution:

$ dd if=hd-test.filenof=hd-test.file.out bs=1024k
 

Seems that there were not an optimal bs-default value on Sparc for this
test.  If I set bs explicitely this way I got:

Sparc/Solaris:  45s
Sparc/Linux:35s   !! (We are really good, aren´t we?)
PC/Linux:   61s

By the way it would be of course interesting, how to adjust reading
block size in other applications than dd.  I started testing when I
recognized that some PostgreSQL tables I created via

   cat tabledefinition | psql database

took much more time than on my PC.  Moreover I´m afraid that database
access is slower if some parts of it do not fit into memory.

Any hints how to tune that?

Kind regards

Andreas.