Re: pxeboot and /boot filesystem, share /boot/kernel
> I want to tighten up my spaces for diskless machines and I came across > this puzzle with pxeboot: > > I can share /usr and most other filesystems, but my individual roots > for the machine each have to have the full kernel. But /boot/kernel > is rather large these days and totally identical, so I'd rather share > it. > > %% > > You can only specify a root filesystem location via the dhcp options. > Then, whatever kernel is there in location:/boot/kernel (or rather, > loader.rc) will be booted, which will then pick up the / filesystem > via location:/etc/fstab. > > This is not quite what I want, because I want /boot/kernel to be > shared, purely for filesize reasons. But I can't specify a separate > /boot filesystem. I can't find an easy way to share /boot but not > share /. > > Or in other words, the core of the problem is that I want to share > /boot/kernel but not share /etc/fstab. > > %% > > So, while writing this mail it occured to me that what I can do is put > a /boot/loader.rc on the individual / filesystems that then redirects > to a common kernel location. But I don't see how I can make this work > as I do not have the option to point to a new NFS mount in > /boot/loader.conf, or do I? > > So what I would want is (on the server): > /diskless-usr/ > /diskless-kernel/ [has /boot/kernel/ in it] > /diskless/root1/ [has /boot/loader.conf in it] > /diskless/root2/ > > DHCP "root-path" is then addr:/diskless/root1 > > Where > /diskless/root1/boot/loader.conf > specifies > addr:/diskless-kernel/boot/kernel/kernel > instead of just a filename. > > Now, the question is how do I make loader.4th able to mount NFS or use > tftp? > > %% > > I think I have three paths to go here: > > 1) make pxeboot understand a separate "boot-path" dhcp option. > > 2) make loader.4th able to use NFS or tftp. IP is already up by the >time it is started. > > 3) only share /boot/kernel/kernel and share a NFS mount for the >modules, but that's very messy. > look in rc.initdiskless, you'll see there the solution. if you mount unionfs /etc, you can have a /(root) mounted read-only. unless there is something I don't see, there is no real reason to separate / from /usr. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pxeboot and /boot filesystem, share /boot/kernel
On Sun, Jul 01, 2007 at 05:35:40PM -0400, Martin Cracauer wrote:
> Bernd Walter wrote on Sun, Jul 01, 2007 at 09:36:41PM +0200:
> > On Sun, Jul 01, 2007 at 02:13:34PM -0400, Martin Cracauer wrote:
> > 4) Use different / on the same server filesystem with hardlinked /boot.
>
> Hmm, directory hardlinks through NFS server? But might do.
I ment the files in it hardlinked.
> I also considered hacking up the NFS server code to resolve individual
> symlinks of my choice. I like this feature a lot when serving samba
> shares to Windows clients to make stupid applications actually place
> stuff where I want it. But this solution is bad news if you rebase
> your NFS server.
Yes - too easy to forget.
> %%
>
> It has been pointed out to me that BSD used to have
> /etc/fstab. back in the day. That seems to be easy enough
> to re-introduce given that pxeboot already set the IP address.
>
> However, it is somewhat hackey since in effect your first root
> filesystem (common for all clients) gets used only once for /etc/fstab
> and is only used to redirect to a new (indivual) root filesystem.
I have something quite similar with a bunch of NetBSD hosts.
Common / with different var partitions mounted by custom scripts and
not by fstab.
Since hostname was already set by dhcp at this point it worked.
> > 5) Use two / - one common for booting and a client specific.
> >loader.rc in common will overwrite rootfs.
> >But I'm unshure if you can get host specific data, e.g. MAC from net
> >interface.
>
> That is somewhat similar to /etc/fstab. but would require the
> 4th to know about networking.
It does know the bootdev and I just checked the soruce and it even sets
variables:
common/dev_net.c:setenv("boot.netif.ip", inet_ntoa(myip), 1);
common/dev_net.c:setenv("boot.netif.netmask", intoa(netmask), 1);
common/dev_net.c:setenv("boot.netif.gateway", inet_ntoa(gateip), 1);
common/dev_net.c:setenv("boot.netif.hwaddr", temp, 1);
common/dev_net.c:setenv("boot.nfsroot.server", inet_ntoa(rootip), 1);
common/dev_net.c:setenv("boot.nfsroot.path", rootpath, 1);
No hostname, but IP and MAC.
You just have to use the variables in your own loader.rc to overwrite
the path.
You can fetch them with getenv:
s" boot.netif.ip" getenv
Well - my forth is too rusty, so I can't help on the if/setenv part.
> > 6) Don't install *.symbols and live with multiple file space usage for
> >the rest.
>
> Right but not sportish :-)
:-)
> Overall, I also need to keep in mind that some but but all of my
> diskless clients will have individual kernels and that I want the most
> elegant way to express this.
If you want you can select the kernel in your loader.rc as well...
> Or a per-host kernel setting in loader.rc which normally points to the
> common kernel but can point to an individual one. But as mentioned
> earlier, this is difficult to do if you / is already unshared, unless
> the loader can deal with NFS or tftp to load from a
> address:/boot/... location.
It can at least read any file from the already mounted NFS path.
No problem to read /boot/kernel.hostx/ instead of default.
Don't know if you can switch to another NFS path.
--
B.Walterhttp://www.bwct.de http://www.fizon.de
[EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pxeboot and /boot filesystem, share /boot/kernel
Bernd Walter wrote on Sun, Jul 01, 2007 at 09:36:41PM +0200: > On Sun, Jul 01, 2007 at 02:13:34PM -0400, Martin Cracauer wrote: > > I want to tighten up my spaces for diskless machines and I came across > > this puzzle with pxeboot: > > > > I can share /usr and most other filesystems, but my individual roots > > for the machine each have to have the full kernel. But /boot/kernel > > is rather large these days and totally identical, so I'd rather share > > it. [...] > > I think I have three paths to go here: > > > > 1) make pxeboot understand a separate "boot-path" dhcp option. > > > > 2) make loader.4th able to use NFS or tftp. IP is already up by the > >time it is started. > > > > 3) only share /boot/kernel/kernel and share a NFS mount for the > >modules, but that's very messy. > > 4) Use different / on the same server filesystem with hardlinked /boot. Hmm, directory hardlinks through NFS server? But might do. I also considered hacking up the NFS server code to resolve individual symlinks of my choice. I like this feature a lot when serving samba shares to Windows clients to make stupid applications actually place stuff where I want it. But this solution is bad news if you rebase your NFS server. %% It has been pointed out to me that BSD used to have /etc/fstab. back in the day. That seems to be easy enough to re-introduce given that pxeboot already set the IP address. However, it is somewhat hackey since in effect your first root filesystem (common for all clients) gets used only once for /etc/fstab and is only used to redirect to a new (indivual) root filesystem. > 5) Use two / - one common for booting and a client specific. >loader.rc in common will overwrite rootfs. >But I'm unshure if you can get host specific data, e.g. MAC from net >interface. That is somewhat similar to /etc/fstab. but would require the 4th to know about networking. > 6) Don't install *.symbols and live with multiple file space usage for >the rest. Right but not sportish :-) %% Overall, I also need to keep in mind that some but but all of my diskless clients will have individual kernels and that I want the most elegant way to express this. The most elegant way to do this would either be a per-host /boot filesystem mount (which I would want to be used both at kernel load time and during runtime). Or a per-host kernel setting in loader.rc which normally points to the common kernel but can point to an individual one. But as mentioned earlier, this is difficult to do if you / is already unshared, unless the loader can deal with NFS or tftp to load from a address:/boot/... location. Martin -- %%% Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pxeboot and /boot filesystem, share /boot/kernel
On Sun, Jul 01, 2007 at 02:13:34PM -0400, Martin Cracauer wrote: > I want to tighten up my spaces for diskless machines and I came across > this puzzle with pxeboot: > > I can share /usr and most other filesystems, but my individual roots > for the machine each have to have the full kernel. But /boot/kernel > is rather large these days and totally identical, so I'd rather share > it. > > %% > > You can only specify a root filesystem location via the dhcp options. > Then, whatever kernel is there in location:/boot/kernel (or rather, > loader.rc) will be booted, which will then pick up the / filesystem > via location:/etc/fstab. > > This is not quite what I want, because I want /boot/kernel to be > shared, purely for filesize reasons. But I can't specify a separate > /boot filesystem. I can't find an easy way to share /boot but not > share /. > > Or in other words, the core of the problem is that I want to share > /boot/kernel but not share /etc/fstab. > > %% > > So, while writing this mail it occured to me that what I can do is put > a /boot/loader.rc on the individual / filesystems that then redirects > to a common kernel location. But I don't see how I can make this work > as I do not have the option to point to a new NFS mount in > /boot/loader.conf, or do I? > > So what I would want is (on the server): > /diskless-usr/ > /diskless-kernel/ [has /boot/kernel/ in it] > /diskless/root1/ [has /boot/loader.conf in it] > /diskless/root2/ > > DHCP "root-path" is then addr:/diskless/root1 > > Where > /diskless/root1/boot/loader.conf > specifies > addr:/diskless-kernel/boot/kernel/kernel > instead of just a filename. > > Now, the question is how do I make loader.4th able to mount NFS or use > tftp? > > %% > > I think I have three paths to go here: > > 1) make pxeboot understand a separate "boot-path" dhcp option. > > 2) make loader.4th able to use NFS or tftp. IP is already up by the >time it is started. > > 3) only share /boot/kernel/kernel and share a NFS mount for the >modules, but that's very messy. 4) Use different / on the same server filesystem with hardlinked /boot. 5) Use two / - one common for booting and a client specific. loader.rc in common will overwrite rootfs. But I'm unshure if you can get host specific data, e.g. MAC from net interface. 6) Don't install *.symbols and live with multiple file space usage for the rest. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP SmartArray ( CISS ) and CAMCONTROL
On Mon, Jun 11, 2007 at 05:31:54PM -0400, Mark Saad wrote: Hello Hackers@ I have been searching around and I can not find an answer to a problem of mine . Does anyone know if its possible to make camcontrol show the drive health for drives in a HP SMART Array . Currently it will show the Array heath by running camcontrol devlist -v . arrayprobe (http://www.strocamp.net/opensource/arrayprobe.php) could be ported, I guess. -- Sergey Svishchev pgpsbnl18g9VZ.pgp Description: PGP signature
Re: SII3512 rev0 ?
>NetBSD:
> dev/pci/satalink.c
>
>/*
> * Rev. <= 0x01 of the 3112 have a bug that can cause data
> * corruption if DMA transfers cross an 8K boundary. This is
> * apparently hard to tickle, but we'll go ahead and play it
> * safe.
> */
>if (PCI_REVISION(pa->pa_class) <= 0x01) {
>sc->sc_dma_maxsegsz = 8192;
>sc->sc_dma_boundary = 8192;
>
>FreeBSD:
> dev/ata/ata-chipset.c
>
>if ((ctlr->chip->cfg2 & SIIBUG) && ch->dma) {
>/* work around errata in early chips */
>ch->dma->boundary = 16 * DEV_BSIZE;
>ch->dma->segsize = 15 * DEV_BSIZE;
DEV_BSIZE = (1<<9) = 512 bytes
boundary = 8192
segsize = 7680 <- Differs by 512 bytes from NetBSD..
Anyone knows why segsize differs?
>And of course there may be other differences I didn't find.
The table used to parse pci setup:
{{ ATA_SII3114, 0x00, SIIMEMIO, SII4CH,ATA_SA150, "SiI 3114" },
{ ATA_SII3512, 0x02, SIIMEMIO, 0, ATA_SA150, "SiI 3512" },
{ ATA_SII3112, 0x02, SIIMEMIO, 0, ATA_SA150, "SiI 3112" },
{ ATA_SII3112_1, 0x02, SIIMEMIO, 0, ATA_SA150, "SiI 3112" },
{ ATA_SII3512, 0x00, SIIMEMIO, SIIBUG,ATA_SA150, "SiI 3512" },
{ ATA_SII3112, 0x00, SIIMEMIO, SIIBUG,ATA_SA150, "SiI 3112" },
{ ATA_SII3112_1, 0x00, SIIMEMIO, SIIBUG,ATA_SA150, "SiI 3112" },
{ ATA_SII3124, 0x00, SIIPRBIO, SII4CH,ATA_SA300, "SiI 3124" },
{ ATA_SII3132, 0x00, SIIPRBIO, 0, ATA_SA300, "SiI 3132" },
And it's parsed with this conditional:
pci_get_revid(dev) >= index->chiprev /* ata_match_chip() */
So for 3112 rev 0,1 SIIBUG will be enabled on FreeBSD-curr. Ie same behaviour
as for when to apply the fix.
This hw seems to be like russian roulette ;)
Maybe it would be a good idea to have chip revision displayed in the syslog
such that an sysadm can quickly spot possible troublesome hw..
In ata_sii_ident() replace:
sprintf(buffer, "%s %s controller", idx->text, ata_mode2str(idx->max_dma));
With something along the lines of:
int chiprev;
chiprev = (int)pci_get_revid(dev);/* assumed unfailable :) */
sprintf(buffer, "%s rev %d %s controller",
idx->text, chiprev, ata_mode2str(idx->max_dma) );
/P
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pxeboot and /boot filesystem, share /boot/kernel
I want to tighten up my spaces for diskless machines and I came across this puzzle with pxeboot: I can share /usr and most other filesystems, but my individual roots for the machine each have to have the full kernel. But /boot/kernel is rather large these days and totally identical, so I'd rather share it. %% You can only specify a root filesystem location via the dhcp options. Then, whatever kernel is there in location:/boot/kernel (or rather, loader.rc) will be booted, which will then pick up the / filesystem via location:/etc/fstab. This is not quite what I want, because I want /boot/kernel to be shared, purely for filesize reasons. But I can't specify a separate /boot filesystem. I can't find an easy way to share /boot but not share /. Or in other words, the core of the problem is that I want to share /boot/kernel but not share /etc/fstab. %% So, while writing this mail it occured to me that what I can do is put a /boot/loader.rc on the individual / filesystems that then redirects to a common kernel location. But I don't see how I can make this work as I do not have the option to point to a new NFS mount in /boot/loader.conf, or do I? So what I would want is (on the server): /diskless-usr/ /diskless-kernel/ [has /boot/kernel/ in it] /diskless/root1/ [has /boot/loader.conf in it] /diskless/root2/ DHCP "root-path" is then addr:/diskless/root1 Where /diskless/root1/boot/loader.conf specifies addr:/diskless-kernel/boot/kernel/kernel instead of just a filename. Now, the question is how do I make loader.4th able to mount NFS or use tftp? %% I think I have three paths to go here: 1) make pxeboot understand a separate "boot-path" dhcp option. 2) make loader.4th able to use NFS or tftp. IP is already up by the time it is started. 3) only share /boot/kernel/kernel and share a NFS mount for the modules, but that's very messy. Martin -- %%% Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SII3512 rev0 ?
> >> Any input on the reliability of SII3512 is also welcomed.
> >
> >dmesg | grep 3512
> >satalink0: Silicon Image SATALink 3512 (rev. 0x01)
> >
> >No reliability problems from the 3512. (up 74 days)
> >
> >This is on an Alpha box running NetBSD. I haven't tried the 3512
> >with FreeBSD.
I took a quick look at the drivers, and found a difference.
NetBSD:
dev/pci/satalink.c
/*
* Rev. <= 0x01 of the 3112 have a bug that can cause data
* corruption if DMA transfers cross an 8K boundary. This is
* apparently hard to tickle, but we'll go ahead and play it
* safe.
*/
if (PCI_REVISION(pa->pa_class) <= 0x01) {
sc->sc_dma_maxsegsz = 8192;
sc->sc_dma_boundary = 8192;
FreeBSD:
dev/ata/ata-chipset.c
if ((ctlr->chip->cfg2 & SIIBUG) && ch->dma) {
/* work around errata in early chips */
ch->dma->boundary = 16 * DEV_BSIZE;
ch->dma->segsize = 15 * DEV_BSIZE;
}
And of course there may be other differences I didn't find.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Device drivers to be commited.
On Sun, 1 Jul 2007 11:58:27 +0200 Erik Trulsson <[EMAIL PROTECTED]> wrote: > The msk(4) driver should support that chip. This driver is also > available in both -CURRENT and 6-STABLE and thus will appear in both > FreeBSD 6.3 and 7.0. great! is it as good as Marvell's one? [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Device drivers to be commited.
On Sun, Jul 01, 2007 at 02:30:00AM -0700, [EMAIL PROTECTED] wrote: > On Sun, 1 Jul 2007 01:26:09 -0700 > Josef Grosch <[EMAIL PROTECTED]> wrote: > > > There are 3 drivers that I have been using with FreeBSD 6.2-RELEASE > > and 6.2-RELEASE-p5. They are > > > > 1) Intel's new driver for em > > > > 2) Adaptec's new driver for the 3805 > > > > 3) 3ware's new SATA RAID controller (9500) > > 04. myk by Marvell (88E8056 -- gigabit NIC) > That one is taken care of, see msk(4) in CURRENT and RELENG_6. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp3N901wcR8y.pgp Description: PGP signature
Re: Device drivers to be commited.
On Sun, Jul 01, 2007 at 02:30:00AM -0700, [EMAIL PROTECTED] wrote: > On Sun, 1 Jul 2007 01:26:09 -0700 > Josef Grosch <[EMAIL PROTECTED]> wrote: > > > There are 3 drivers that I have been using with FreeBSD 6.2-RELEASE > > and 6.2-RELEASE-p5. They are > > > > 1) Intel's new driver for em The em(4) driver in -CURRENT tends to be *very* up-to-date. At the moment it is up to version 6.5.3 (which is actually newer than the 6.4.1 driver that you can download from Intel for FreeBSD 6.x) The driver in 6-STABLE lags a bit behind (as one would expect). It is currently at version 6.2.9 (which is also fairly new.) I don't know if there are any plans for upgrading this before FreeBSD 6.3. > > > > 2) Adaptec's new driver for the 3805 No idea about this one. I don't think there is support for it in either -CURRENT or 6-STABLE at the moment and I don't know if anybody is working on it at the moment. > > > > 3) 3ware's new SATA RAID controller (9500) The latest twa(4) driver from 3ware is already in both -CURRENT and 6-STABLE so it will appear in FreeBSD 6.3 as well as in 7.0 > > 04. myk by Marvell (88E8056 -- gigabit NIC) > The msk(4) driver should support that chip. This driver is also available in both -CURRENT and 6-STABLE and thus will appear in both FreeBSD 6.3 and 7.0. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Device drivers to be commited.
On Sun, 1 Jul 2007 01:26:09 -0700 Josef Grosch <[EMAIL PROTECTED]> wrote: > There are 3 drivers that I have been using with FreeBSD 6.2-RELEASE > and 6.2-RELEASE-p5. They are > > 1) Intel's new driver for em > > 2) Adaptec's new driver for the 3805 > > 3) 3ware's new SATA RAID controller (9500) 04. myk by Marvell (88E8056 -- gigabit NIC) [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Device drivers to be commited.
There are 3 drivers that I have been using with FreeBSD 6.2-RELEASE and 6.2-RELEASE-p5. They are 1) Intel's new driver for em 2) Adaptec's new driver for the 3805 3) 3ware's new SATA RAID controller (9500) The drivers can be found : Intel: http://downloadcenter.intel.com/T8Clearance.aspx?sType=&agr=Y&ProductID=839&DwnldID=10957&url=/10957/eng/em-6.4.1.tar.gz&PrdMap=&strOSs=52&OSFullName=FreeBSD*&lang=eng Adaptec: http://www.adaptec.com/en-US/speed/raid/aac/unix/aacraid_drv_freebsd6_x86_b11669_tgz.htm http://www.adaptec.com/en-US/speed/raid/aac/unix/aacraid_drv_freebsd6_x64_b11669_tgz.htm 3ware: http://www.3ware.com/KB/attachments/twa96SE.ko-32bit-freebsd_6.2-GUIDfc6bd7e1b3194d67b031c9c8277584eb.zip http://www.3ware.com/KB/attachments/twa96SE.ko-64bit-freebsd_6.2-GUID5a84058ef94843898a297faa7a282a19.zip My question is will we be seeing these drivers in 6.3? Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.2 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgp670nAawZ5O.pgp Description: PGP signature
