headers
Rhialto | 1 Feb 2006 02:04
Picon

Re: The reason for securelevel

On Thu 26 Jan 2006 at 15:29:36 -0500, Chapman Flack wrote:
> Julio M. Merino Vidal wrote:
> >>  Can one even run X with securelevel=1 yet? I kept maintaining a  patch
> >It used to be possible with pkgsrc/sysutils/aperture.  Haven't
> >tried for a looong while, though.
> 
> Seems to me there was a recent thread about that on port-i386,
> which revealed that (a) aperture apparently does work on that
> platform, and (b) aperture works because a hole was carved in the

it does, I am using it, and I really want to use it on amd64 too but it
doesn't work there.
This is a prime example of splitting up securelevel, because I really
want to run my server at securelevel 1 but I can't, if I want to run X
too. While theoretically perhaps running X makes the system insecure, in
practice it still is a safer system if only it could run on level 1.

> -Chap
-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.
Permalink | Reply | 0 comments |
headers
Juan RP | 1 Feb 2006 02:53

Re: Multiboot support for review

On Tue, 31 Jan 2006 21:19:21 +0100
"Julio M. Merino Vidal" <jmmv84 <at> gmail.com> wrote:

> Hi all,
> 
> after some hacking days, I've finally got some code to make NetBSD
> Multiboot-compliant.  We already discussed this here and all I got
> was positive feedback:
> 
> 	http://mail-index.netbsd.org/tech-kern/2005/12/28/0008.html
> 
> The patch still needs some cleanup and bug fixing (specially testing
> that several things work after the changes) but, while I do those,
> I want to ask for feedback because the code won't change that much.
> The preliminary patch is at:
> 
> 	ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/multiboot.diff

I just tried your patch (thanks for doing it BTW) but didn't work. 
I've followed the instructions of multiboot(8)'s manpage:

* Build kernel with options MULTIBOOT
* Apply patch grub-fix-addresses.diff to grub and reinstall it with
  "grub-install /dev/wdNd"
* Modify /grub/menu.lst with:

title NetBSD/Multiboot
kernel (hd0,1,a)/netbsd.gz -c console=pc root=wd0a

When the ELF image is already loaded the boot process hangs.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Juan RP | 1 Feb 2006 03:53

Re: Multiboot support for review

On Wed, 1 Feb 2006 02:53:59 +0100
Juan RP <juan <at> xtrarom.org> wrote:

> On Tue, 31 Jan 2006 21:19:21 +0100
> "Julio M. Merino Vidal" <jmmv84 <at> gmail.com> wrote:
> 
> > Hi all,
> > 
> > after some hacking days, I've finally got some code to make NetBSD
> > Multiboot-compliant.  We already discussed this here and all I got
> > was positive feedback:
> > 
> > 	http://mail-index.netbsd.org/tech-kern/2005/12/28/0008.html
> > 
> > The patch still needs some cleanup and bug fixing (specially testing
> > that several things work after the changes) but, while I do those,
> > I want to ask for feedback because the code won't change that much.
> > The preliminary patch is at:
> > 
> > 	ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/multiboot.diff
> 
> I just tried your patch (thanks for doing it BTW) but didn't work. 
> I've followed the instructions of multiboot(8)'s manpage:
> 
> * Build kernel with options MULTIBOOT
> * Apply patch grub-fix-addresses.diff to grub and reinstall it with
>   "grub-install /dev/wdNd"
> * Modify /grub/menu.lst with:
> 
> title NetBSD/Multiboot
(Continue reading)

Permalink | Reply | 2 comments |
headers
George Georgalis | 1 Feb 2006 06:00

Re: Multiboot support for review

On Tue, Jan 31, 2006 at 09:19:21PM +0100, Julio M. Merino Vidal wrote:
>
>after some hacking days, I've finally got some code to make NetBSD
>Multiboot-compliant.  We already discussed this here and all I got
>was positive feedback:
>
>	http://mail-index.netbsd.org/tech-kern/2005/12/28/0008.html

>Here come some things I'd like to discuss:
>
>- In the past days, someone suggested the idea of adding a textual
>  data representation to pass variable/value pairs between the kernel
>  and userspace.  I've had to do something similar to pass some boot
>  information between GRUB and the kernel, and hence implemented such
>  an interface.
>
>  It is currently very, very simple, but it may do the job in the
>  cases where it's needed (e.g., mount(2) arguments).
>
>  It is named 'optstr' and is implemented in sys/optstr.h and
>  kern/subr_optstr.c.  See the manual page in the patch file.

I have a frustrating problem that I'd like to point out; maybe you
have some ideas but I'm not sure if it has or could have anything
to do with the stage you are working on...

Hardware:
x86 mobo
two pci based SATA channels
two onboard SATA channels
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Nemeth | 1 Feb 2006 08:59
Picon
Favicon

unidentified cardbus cards

     On the weekend, I was playing with a Cisco CB21AG wireless card.
It was nice to see it recognised as an ath(4) card and just work.
However, dmesg didn't identify it and just printed some basic
information about its capabilities.  I tried turning on various
*VERBOSE options to see if I could get the vendor and product ids and
see what other information I could get, but I didn't find the right
magic option.  Can anybody clue me in?  I would like to add it to the
appropriate file (pcidevs?).
Permalink | Reply | 2 comments |
headers
Martin Husemann | 1 Feb 2006 09:34
Picon

Re: unidentified cardbus cards

On Tue, Jan 31, 2006 at 11:59:16PM -0800, John Nemeth wrote:
> see what other information I could get, but I didn't find the right
> magic option.  Can anybody clue me in?  I would like to add it to the
> appropriate file (pcidevs?).

Have a look at pcictl(8) - the "list" command should give you all the
information you need.

Martin
Permalink | Reply | 1 comment |
headers
Martin Husemann | 1 Feb 2006 09:39
Picon

Re: unidentified cardbus cards

On Wed, Feb 01, 2006 at 09:34:11AM +0100, Martin Husemann wrote:
> Have a look at pcictl(8) - the "list" command should give you all the
> information you need.

Stupid me, you did say "cardbus", didn't you?

Does "options  CARDBUS_DEBUG" not make the kernel print the info you want?
The code looks like it should:

                DPRINTF(("cardbus_attach_card: "
                    "Vendor 0x%x, Product 0x%x, CIS 0x%x\n",
                    CARDBUS_VENDOR(id), CARDBUS_PRODUCT(id), cis_ptr));

Martin
Permalink | Reply | 0 comments |
headers
Julio M. Merino Vidal | 1 Feb 2006 09:41
Picon

Boot drive [was Re: Multiboot support for review]

Changed the subject because this has nothing to do with Multiboot.

El 01/02/2006, a las 6:00, George Georgalis escribió:

>
> Problem:
> init numbers drives in this order: pci SATA, onboard SATA, onboard  
> PATA
> (I'm not blaming init, it may be a wacko bios providing the devices
> in the wrong order, but I've not been able to try in other hardware)
[...]

I don't know what PATA is, but anyway...

init(8) does not number drives.  It is the kernel who initializes the
drivers and, depending on the order in which that happens and the
number of drives, they will get some identifiers or others.

I *think* wedges are a solution to this problem but I do not know
anything about them.

Another solution is to rebuild a custom kernel and change its
configuration to force the detection of drives in a specific order.
E.g., instead of saying:

wd* at atabus?
wd* at umass?

You'd say:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Carosone | 1 Feb 2006 10:28
Picon

Re: Boot drive [was Re: Multiboot support for review]

On Wed, Feb 01, 2006 at 09:41:06AM +0100, Julio M. Merino Vidal wrote:
> I *think* wedges are a solution to this problem but I do not know
> anything about them.
> 
> Another solution is to rebuild a custom kernel and change its
> configuration to force the detection of drives in a specific order.

Yet another solution is to (ab)use raidframe autoconfig for this.
Stick a raid label on each disk, define each as a single-device
stripe, or as a mirror with a missing second half in case you might
add one later, and raidctl -A yes them.  The volume names (raid0,
raid1, raid2, etc) will stay with the drives, and you use those in
fstab. raidctl -A root the one you want for root.

It's somewhat weird and lame, but it works.

--
Dan.
Permalink | Reply | 1 comment |
headers
Ignatios Souvatzis | 1 Feb 2006 11:26
Picon
Favicon

Re: Boot drive [was Re: Multiboot support for review]

On Wed, Feb 01, 2006 at 09:41:06AM +0100, Julio M. Merino Vidal wrote:

> I don't know what PATA is, but anyway...

Parallel ATA, probably.

	-is
Permalink | Reply | 0 comments |

Gmane