Re: reboot hangs on RAQ 2+ install

On 11/30/05, Andrew L. Gould <algould <at> datawok.com> wrote:
> I just installed NetBSD 2.1 to a RAQ 2+.  The installation appears to
> finish successfully, but while rebooting, the server hangs with the
> message "Starting Up".
>
> I read through the archives and found messages back in
> September regarding scsi support being a problem on the RAQ 2+'s.  The
> solution in the archives was to build a kernel without scsi support.
> Unfortunately, I don't have another computer running NetBSD at this
> time to build such a kernel.
>
> I can't telnet or ssh from the laptop with the restore CD to check for
> additional information.
>
> Does anyone have a working NetBSD 2.1 kernel running on a RAQ2+ that
> they could send me?

2.1 probably isn't stable anyway.

You should use one of the 3.0 release candidates, or wait a little
while for 3.0 release.

Andy

Re: ridiculous uid

On 11/30/05 17:31:11, Steven M. Bellovin wrote:
...
> >$ id daemon
> >uid=16777216(daemon) gid=16777216 groups=16777216,1(daemon)
> >
> 
> Looks like an endian problem.  3154575360 is 0xBC070000; 0x07BC is
> 1980.  Similarly, 16777216 is 0x1000000, while daemon should be uid
> 1.

Hmm, indeed. It's probably useful to notice that I booted and mounted  
everything from an other-endian system (sparc). More, if I mount a  
directory with extracted base and etc (RC5 sets) from my (x86) laptop  
and chroot to that, uids are not swapped.

Can somebody confirm this is cobalt or mipsel specific? Chrooting to an  
nfs mounted dir from the sparc on my laptop doesn't show the same  
problem (although my laptop runs -current, I have no clue if that  
matters).

Kind reagrds
dieter

--

-- 
	For Speedy CVS Updates of your NetBSD trees check
	http://scu.bsdusr.net/scu
--
	There is virtue in doing the right thing just for
	the sake of doing it right.  -- Nicholas Petreley

Re: ridiculous uid

On Thu, 1 Dec 2005, dieter Roelants wrote:
> Hmm, indeed. It's probably useful to notice that I booted and mounted 
> everything from an other-endian system (sparc). More, if I mount a directory 
> with extracted base and etc (RC5 sets) from my (x86) laptop and chroot to 
> that, uids are not swapped.
>
> Can somebody confirm this is cobalt or mipsel specific? Chrooting to an nfs 
> mounted dir from the sparc on my laptop doesn't show the same problem 
> (although my laptop runs -current, I have no clue if that matters).

Sounds like /etc/{s,}pwd.db are endian-specific
(which are the binary versions of /etc/master.passwd and /etc/passwd, see 
pwd_mkdb(8) and vipw(8))

  - Hubert

Re: reboot hangs on RAQ 2+ install

On Wed, 30 Nov 2005 18:27:37 -0700
Andy Ruhl <acruhl <at> gmail.com> wrote:

> On 11/30/05, Andrew L. Gould <algould <at> datawok.com> wrote:
> > I just installed NetBSD 2.1 to a RAQ 2+.  The installation appears
> > to finish successfully, but while rebooting, the server hangs with
> > the message "Starting Up".
> >
> > I read through the archives and found messages back in
> > September regarding scsi support being a problem on the RAQ 2+'s.
> > The solution in the archives was to build a kernel without scsi
> > support. Unfortunately, I don't have another computer running
> > NetBSD at this time to build such a kernel.
> >
> > I can't telnet or ssh from the laptop with the restore CD to check
> > for additional information.
> >
> > Does anyone have a working NetBSD 2.1 kernel running on a RAQ2+ that
> > they could send me?
> 
> 2.1 probably isn't stable anyway.
> 
> You should use one of the 3.0 release candidates, or wait a little
> while for 3.0 release.
> 
> Andy

I may have to go the 3.0 route.

I installed 1.6.2 (for grins), which worked; but I still had the

Re: ridiculous uid

On 12/01/05 23:17:11, Hubert Feyrer wrote:
> Sounds like /etc/{s,}pwd.db are endian-specific
> (which are the binary versions of /etc/master.passwd and /etc/passwd,  
> see pwd_mkdb(8) and vipw(8))

Doh, that was indeed the problem. I couldn't understand why the storage  
of the password database did matter, but indeed, I used vipw on that  
root from the sparc. I never used pwd_mkdb directly I think, and wasn't  
aware of the options for changing endianness (or even that it was  
different.) Thanks very much, Hubert, and also Steven and Christos.

dieter

--

-- 
	For Speedy CVS Updates of your NetBSD trees check
	http://scu.bsdusr.net/scu
--
	There is virtue in doing the right thing just for
	the sake of doing it right.  -- Nicholas Petreley

Re: ridiculous uid

Dieter,

>> Looks like an endian problem.  3154575360 is 0xBC070000; 0x07BC is
>> 1980.  Similarly, 16777216 is 0x1000000, while daemon should be uid
>> 1.
> 
> Hmm, indeed. It's probably useful to notice that I booted and mounted 
> everything from an other-endian system (sparc). More, if I mount a 
> directory with extracted base and etc (RC5 sets) from my (x86) laptop 
> and chroot to that, uids are not swapped.

It occurs to me that GNU/Linux's mount command has an option that allows
you to byte-swap a volume... to solve these exact types of issues. Does
anyone know if that option exists in NetBSD? My qube has been off for
months...

I'm suprised that you were even able to boot and run programs. ;)

-chris

Re: ridiculous uid

On Fri, Dec 02, 2005 at 09:31:03AM -0500, Christopher Schultz wrote:
> It occurs to me that GNU/Linux's mount command has an option that allows
> you to byte-swap a volume...

You probably misunderstood both the mount option and the problem.

If you mount a local filesystem (say on a floppy) that has been created
on a machine with different endianess, you need something to take care
of the file system endianess (NetBSD does this automagically). This is
just the file system structure, not the contents of the files stored in
the filesystem.

Here the problem is that files stored inside the filesystem were changed,
and stored in a endian dependend format. NetBSD's bdb support can
cope and handles the db structure fine in different endianess, but the
binary content fields of course have been swapped too.

There is no magic solution to this. You can not blindly swap all bytes around
in files stored inside the filesystem unless you exactly do know the structure
of the binary data.

Martin

Re: ridiculous uid

Martin,

>>It occurs to me that GNU/Linux's mount command has an option that allows
>>you to byte-swap a volume...
> 
> You probably misunderstood both the mount option and the problem.

You're right. I hadn't read the latest couple of messages (where the
revelation about the binary passwd database was mentioned). Oops!

> If you mount a local filesystem (say on a floppy) that has been created
> on a machine with different endianess, you need something to take care
> of the file system endianess (NetBSD does this automagically). This is
> just the file system structure, not the contents of the files stored in
> the filesystem.

Right... this is why I was confused about his ability to boot! ;)

> There is no magic solution to this. You can not blindly swap all bytes around
> in files stored inside the filesystem unless you exactly do know the structure
> of the binary data.

Agreed. The only way to get around this would be to have a magic number
at the beginning of the file that you could use to detect the endianness
of the file, and then (potentially) swap bytes accordingly. Or, just
always use network byte order or whatever.

-chris

postfix permissions

postfix worked for me as built with 1.6.1, but with the -current  
build there are permission problems.

I'm not sure if I need to set something for the postfix executable or  
if I need to just open up permissions on some directories.  I looked  
a bit and I'm not sure why it didn't just set everything up the way  
it needs as it did before.

For example, with a -current system from July 2005,  and a pkgsrc  
from about 3 weeks ago, postfix will build, run, listen on ports fine,
neither sendmail or postfix will be able to send messages-- they  
don't have permissions for neede ddirectories, but opening up  
permissions give me warnings about dangerous permissions and things  
still fail.

For example:

Dec  3 06:04:02 bmcewen postfix/postfix-script: starting the Postfix  
mail system
Dec  3 06:04:02 bmcewen postfix/master[24815]: daemon started --  
version 2.1.5
Dec  3 06:04:50 bmcewen sendmail[25332]: NOQUEUE: SYSERR(root): can  
not chdir(/var/spool/clientmqueue/): Permission denied
Dec  3 06:18:17 bmcewen sendmail[25013]: NOQUEUE: SYSERR(root): can  
not chdir(/var/spool/clientmqueue/): Permission denied
Dec  3 06:20:00 bmcewen sendmail[25485]: NOQUEUE: SYSERR(root): can  
not chdir(/var/spool/clientmqueue/): Permission denied

and opening up the directory gives:

Largest disk for Qube 2