Re: still upgrading from 2.0 to 7.0

2016-08-21 Thread Thor Lancelot Simon
On Fri, Aug 19, 2016 at 12:47:36PM +0100, Steve Blinkhorn wrote:
> 
> Kernelized RAIDframe activated
> ataraid0: found 1 RAID volume
> ld0 at ataraid0 vendtype 0 unit 0: Promise ATA SPAN array
> ld0: 76319 MB, 9729 cyl, 255 head, 63 sec, 512 bytes/sect x 156301425

You have one or more drives configured as a RAID 0 set in the host
BIOS or possibly a separate controller BIOS.  The thing to hope for
is that it's *not* the same underlying drive you're accessing as wd0...!

You didn't notice before because NetBSD 2 didn't have a device driver
for the Promise software RAID.

I would be very, very careful about this: if you turn it off, it is
possible the stupid Promise BIOS may render your disk inaccessible even
if you turn it back on.  Your best bet is probably a kernel or boot
settings which disable the "ataraid" driver.

Thor


Re: still upgrading from 2.0 to 7.0

2016-08-19 Thread Eric Haszlakiewicz
On August 19, 2016 7:47:36 AM EDT, st...@prd.co.uk wrote:
>So I installed new bootbocks and new boot code.   What I need to do
>now is force the system to boot from /dev/wd0a, swap to /dev/wd0b and
>use /sbin/init without needing console interaction.What it does at
>present at the end of the hardware probe (still in green screen) is
>say that the boot device is unknown, then prompts for a root device
>with /dev/ld0a as the default.If I disable ld* in autoconf then
>the system proceeds to boot normally.   Here is the relevant bit of
...
>It must surely be possible to specify root and swap partitions
>somewhere in a configuration file.   But I have read and reread so
>many man pages now that I think I must just be missing something
>terroibly obvious.

It doesn't appear to be possible, but is disabling ld* works then you should be 
able to add that to boot.cfg as:

   userconf disable ld*

If you build a custom kernel you can specify it there, but that's a bit of a 
pain, and easy to forget the next time you update.

Eric





Re: still upgrading from 2.0 to 7.0

2016-08-19 Thread Steve Blinkhorn
So I installed new bootbocks and new boot code.   What I need to do
now is force the system to boot from /dev/wd0a, swap to /dev/wd0b and
use /sbin/init without needing console interaction.What it does at
present at the end of the hardware probe (still in green screen) is
say that the boot device is unknown, then prompts for a root device
with /dev/ld0a as the default.If I disable ld* in autoconf then
the system proceeds to boot normally.   Here is the relevant bit of
dmesg.boot:

Kernelized RAIDframe activated
ataraid0: found 1 RAID volume
ld0 at ataraid0 vendtype 0 unit 0: Promise ATA SPAN array
ld0: 76319 MB, 9729 cyl, 255 head, 63 sec, 512 bytes/sect x 156301425
sectors
ld0: mbr partition exceeds disk size
ld0: mbr partition exceeds disk size  
ld0: mbr partition exceeds disk size
ld0: mbr partition exceeds disk size
ld0: mbr partition exceeds disk size
boot device: ld0
root on ld0a dumps on ld0b
ld0: mbr partition exceeds disk size
Supported file systems: union umap tmpfs smbfs puffs ptyfs procfs
overlay null n
tfs nfs msdos mfs lfs kernfs fdesc ext2fs ffs coda cd9660
no file system for ld0 (dev 0x1300)
cannot mount root, error = 79

It must surely be possible to specify root and swap partitions
somewhere in a configuration file.   But I have read and reread so
many man pages now that I think I must just be missing something
terroibly obvious.

You wrote:
> 
> --=-=-=
> Content-Type: text/plain
> 
> 
> note that you may be better off with newer first-stage bootblocks
> (e.g. bootxx_ffsv1).  I sent you a script earlier that updates my
> system; read boot(8) and installboot(8) carefully, and figure out your
> root fs type.  My script may well be wrong for you.
> 
> #!/bin/sh
> 
> installboot -v /dev/rwd0a /usr/mdec/bootxx_ffsv1
> 
> cp -p /usr/mdec/boot /
> 
> --=-=-=
> Content-Type: application/pgp-signature; name="signature.asc"
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iEYEARECAAYFAle174EACgkQ+vesoDJhHiUo6gCgio7KLFvUm+L6xnuQmmfJmW5r
> tKcAoK55mI/ir/YQwT4OHEND75B+ECAb
> =OvTm
> -END PGP SIGNATURE-
> --=-=-=--
> 


-- 
Steve Blinkhorn 



Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread Steve Blinkhorn
I don't know: They are Fujitsu Primergy RX100 servers with dual-core
Pentium 4 processors.   Fujitsus UK are looking for the appropriate
datasheet.

If there is a hardware RAID controller, would this connect with the ld0
device dtected in the hardware probe?

You wrote:
> 
> st...@prd.co.uk (Steve Blinkhorn) writes:
> 
> > If I replace the old copy oof boot with the one that comes from 7.0
> > then an attempt is made to boot from a dvice called ld0 - which I never
> > kne was there, which fails with a message about RAID, the master boot
> > record and the  size of the partition.   I'm wholly out of my depth
> > here.   All I need is for the system to boot non-interactively from
> > wd0 with root on wd0a, swap on wd0b and init from /sbin/init.   Always
> > happened automatically for me before.
> 
> ld0 would be a member of the logical block driver: man 4 ld
> 
> The system doesn't have a hardware raid controller on it does it??
> 
> 
> 
> -- 
> Brad Spencer - b...@anduin.eldar.org - KC8VKS
> http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]
> 


-- 
Steve Blinkhorn 




Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread Steve Blinkhorn
If I replace the old copy oof boot with the one that comes from 7.0
then an attempt is made to boot from a dvice called ld0 - which I never
kne was there, which fails with a message about RAID, the master boot
record and the  size of the partition.   I'm wholly out of my depth
here.   All I need is for the system to boot non-interactively from
wd0 with root on wd0a, swap on wd0b and init from /sbin/init.   Always
happened automatically for me before.


I wrote:
> 
> I thhink this was the issue.   I took Brad's advice and re-installed
> the sets making sure I included a p in the tar options.
> 
> So now I have just one issue to solve before packing these beasts back
> off to work in the data centre.   When I reboot I get - in green screen
> mode - prompts for root filesystem, swap device etc., whereas I need
> them to boot non-interactively.
> 
> I see in my other 7.0 systems a /kern in the filesystem and in
> /etc/fstab.  Should I be setting this up (and how)>
> 
> --
> Steve Blinkhorn 
> 
> You wrote:
> > 
> > On August 18, 2016 9:45:31 AM EDT, st...@prd.co.uk wrote:
> > >Still upgrading from 2.0 to 7.0, I have a running system and I can
> > >login as root at the console using the password I have set.   I can
> > >login as an ordinary user across the network, but I cannot su from
> > >there, and on the console if I su to an ordinary account and then try
> > >to su from there, I gent authentication failure.
> > 
> > Does su have the setuid bit set?
> > 
> > 
> > 
> > 
> 
> 
> 


-- 
Steve Blinkhorn 


This email is for the addressee only.   If you are not the addressee
you should immediately delete this email from your system(s) and
inform us.   It may contain information that is confidential or
otherwise privileged, and should not be copied or redistributed to
recipients not originally specified as addressees without permission.

S F Blinkhorn MA PhD CPsychol FBPsS, Managing Director,
Psychometric Research & Development Ltd.
PO Box 1143, St Albans, Herts, AL1 9UT, UK
Registered in England No. 1909571
Registered Office: 45 Grosvenor Rd., St Albans, Herts, AL1 3AW
Phone: +44 (0)1727 841455
http://www.prd.co.uk



Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread Steve Blinkhorn
I thhink this was the issue.   I took Brad's advice and re-installed
the sets making sure I included a p in the tar options.

So now I have just one issue to solve before packing these beasts back
off to work in the data centre.   When I reboot I get - in green screen
mode - prompts for root filesystem, swap device etc., whereas I need
them to boot non-interactively.

I see in my other 7.0 systems a /kern in the filesystem and in
/etc/fstab.  Should I be setting this up (and how)>

--
Steve Blinkhorn 

You wrote:
> 
> On August 18, 2016 9:45:31 AM EDT, st...@prd.co.uk wrote:
> >Still upgrading from 2.0 to 7.0, I have a running system and I can
> >login as root at the console using the password I have set.   I can
> >login as an ordinary user across the network, but I cannot su from
> >there, and on the console if I su to an ordinary account and then try
> >to su from there, I gent authentication failure.
> 
> Does su have the setuid bit set?
> 
> 
> 
> 




Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread Greg Troxel

st...@prd.co.uk (Steve Blinkhorn) writes:

> I very much suspect that this is a PAM issue of some kind but I have
> little familiarity with this sort of configuration.   So far as I can
> see, /etc/pam.d/su is not different from the same file on other 7.0
> systems I have running.   I have checked, and su is /usr/bin/su.

Unpack the etc.tgz set someplace (I leave it in /usr/netbsd-etc) and run
"diff -ur" against /etc/pam.d and /usr/netbsd-etc/etc/pam.d.   Make your
system match the new sets, unless you really understand why, for all
files, not just the ones you think matter.  Note that the su pam file
includes the system pam file.





signature.asc
Description: PGP signature


Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread Swift Griggs
On Thu, 18 Aug 2016, Steve Blinkhorn wrote:
> I can login as an ordinary user across the network, but I cannot su from 
> there, and on the console if I su to an ordinary account and then try to 
> su from there, I gent authentication failure.

You probably already know this, but make sure the users you are trying to 
'su' from are members of the 'wheel' group. Otherwise, they will not be 
allowed to 'su' to root. 

-Swift


Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread Eric Haszlakiewicz
On August 18, 2016 9:45:31 AM EDT, st...@prd.co.uk wrote:
>Still upgrading from 2.0 to 7.0, I have a running system and I can
>login as root at the console using the password I have set.   I can
>login as an ordinary user across the network, but I cannot su from
>there, and on the console if I su to an ordinary account and then try
>to su from there, I gent authentication failure.

Does su have the setuid bit set?





Re: still upgrading from 2.0 to 7.0

2016-08-18 Thread yancm
> I can
> login as an ordinary user across the network, but I cannot su from
> there, and on the console if I su to an ordinary account and then try
> to su from there, I gent authentication failure.
>
I use the sudo package to get root.

in the sudo config (using visudo) I have:

## User privilege specification
##
rootALL=(ALL) ALL
myusername   ALL=(ALL) ALL

then I just use sudo rather than su...

I think that may work in your case...

--gene





still upgrading from 2.0 to 7.0

2016-08-18 Thread Steve Blinkhorn
Still upgrading from 2.0 to 7.0, I have a running system and I can
login as root at the console using the password I have set.   I can
login as an ordinary user across the network, but I cannot su from
there, and on the console if I su to an ordinary account and then try
to su from there, I gent authentication failure.

I very much suspect that this is a PAM issue of some kind but I have
little familiarity with this sort of configuration.   So far as I can
see, /etc/pam.d/su is not different from the same file on other 7.0
systems I have running.   I have checked, and su is /usr/bin/su.

I'm about to start upgrading the 3.0 system to 7.0 - this already had
a working PAM configuration, which I don't want to trash...

-- 
Steve Blinkhorn