Fwd: binding non local ip.
-- Forwarded message --
From: joris dedieu
Date: 2011/1/9
Subject: Re: binding non local ip.
To: Julian Elischer
2011/1/7 Julian Elischer :
> On 1/7/11 4:57 AM, joris dedieu wrote:
>>
>> Hi,
>> I need a to bind non local ips daemons that don't
>> implement IP_BINDANY sockopt.
>
> I'm not sure you need it
> you can use the ipfw 'fwd' command to make a locally bound
> socket act and look as if it is bound to a non local address
>
> You need to tell us a little more about what you need to do
>
> for example,
> Is the socket just listenning? or is it initiating?
listenning I think.
Typicaly prepare a spare server.
eg:
- Failover as with carp but with more complexes actions has shutting
down the power of the main server, check data consistency, check if
the problem is not just a reboot or a buggy service that need to be
restarted.
- Switch an ip from a main server to a already configured proxy (during a dos)
- monitor that spare service is running.
>
>> There are several solutions as patching every single daemon
>> or using carp (You may not want automatic failover), jailing
>> the process and of course binding INADDR_ANY when possible ...
>>
>> As I'm too lazy for this, I wrote a little (maybe ugly as my
>> kernel knowledges are really low) patch that add a sysctl
>> entry in net.inet.ip that allow binding non local ips. It's
>> maybe buggy and insecure but it seems to work.
>
> seems ok, but if the daemon is initiating, how does it know to bind to a non
> local address?
It doesn't know. That's the goal. So when the address became local
it's already ready. So you don't discover that it's misconfigured or
broken, or that else your dummy colleague has imagined :) . You or a
script ifconfig the alias and back to bed !
> also. if you have source, a single setsockopt() in each one is not much of a
> job..
I already do this for haproxy and for apr. But (for haproxy) it seems
to be too specific to be integrated upstreams. For other services (as
tomcat) that don't know privileges dropping it's more problematic as
IP_BINDANY needs in most case root privileges.
I think that a system wide solution should be a good thing.
Joris
>
>
>> What do you think about it ?
>>
>> Thanks
>> Joris
>>
>> --- a/sys/netinet/in_pcb.c
>> +++ b/sys/netinet/in_pcb.c
>> @@ -321,6 +321,9 @@ in_pcbbind(struct inpcb *inp, struct sockaddr
>> *nam, struct ucred *cred)
>> *
>> * On error, the values of *laddrp and *lportp are not changed.
>> */
>> +static int bindany = 0; /* 1 allows to bind a non local ip */
>> +SYSCTL_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,&bindany, 0,
>> + "Allow to bind a non local ip");
>> int
>> in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t
>> *laddrp,
>> u_short *lportp, struct ucred *cred)
>> @@ -393,8 +396,12 @@ in_pcbbind_setup(struct inpcb *inp, struct
>> sockaddr *nam, in_addr_t *laddrp,
>> * to any endpoint address, local or not.
>> */
>> if ((inp->inp_flags& INP_BINDANY) == 0&&
>> - ifa_ifwithaddr_check((struct sockaddr *)sin)
>> == 0)
>> - return (EADDRNOTAVAIL);
>> + ifa_ifwithaddr_check((struct sockaddr *)sin)
>> == 0) {
>> + if(bindany> 0)
>> + inp->inp_flags |= INP_BINDANY;
>> + else
>> + return (EADDRNOTAVAIL);
>> + }
>> }
>> laddr = sin->sin_addr;
>> if (lport) {
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>>
>
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: binding non local ip.
2011/1/9 Eygene Ryabinkin :
Sorry for my mail client broken that do not send mails to the list :)
I'll take care.
> Joris, good day.
>
> Sun, Jan 09, 2011 at 06:29:20PM +0100, joris dedieu wrote:
>> Thanks Eygene for this greate review !
>
> No problems ;))
>
>> 2011/1/7 Eygene Ryabinkin :
>> > Fri, Jan 07, 2011 at 01:57:21PM +0100, joris dedieu wrote:
>> >> What do you think about it ?
>> > [...]
>> >> +static int bindany = 0; /* 1 allows to bind a non local ip */
>> >> +SYSCTL_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW, &bindany, 0,
>> >> + "Allow to bind a non local ip");
>> >
>> > On at least 8.x, you will likely want to use VNET_* macros to enable
>> > your new sysctl to be virtualized. Something like this:
>> > {{{
>> > VNET_DEFINE(int, inp_bindany) = 0;
>> > SYSCTL_VNET_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,
>> > &VNET_NAME(inp_bindany), 0, "Force INP_BINDANY on all sockets");
>> > }}}
>> > and use VNET(inp_bindany) in subsequent code.
>> Ok it make sense. I will use VNET_*. There are a lot of SYSCTL_* in
>> netinet and netinet6. Is changing this for VNET_* an open task?
>
> I think that the most of them that are applicable to VNET were
> already converted. It is better to ask at freebsd-...@freebsd.org.
>
>> Greate. It makes me understand the way a lot of things are written.
>> Avoid branching if you can.
>> I see that OPSET macro in netinet/ip_output.c lock the inp struct. Is
>> there a need of it there ?
>
> Yes. I had overlooked the need of locking here, sorry.
I wrote a better patch that avoid locking and inp struct modification.
diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c
index d742887..f41e4da 100644
--- a/sys/netinet/in_pcb.c
+++ b/sys/netinet/in_pcb.c
@@ -321,6 +321,9 @@ in_pcbbind(struct inpcb *inp, struct sockaddr
*nam, struct ucred *cred)
*
* On error, the values of *laddrp and *lportp are not changed.
*/
+VNET_DEFINE(int, inp_bindany) = 0;
+SYSCTL_VNET_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,
+&VNET_NAME(inp_bindany), 0, "Force INP_BINDANY on all sockets");
int
in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp,
u_short *lportp, struct ucred *cred)
@@ -392,7 +395,8 @@ in_pcbbind_setup(struct inpcb *inp, struct
sockaddr *nam, in_addr_t *laddrp,
* If INP_BINDANY is set, then the socket may be bound
* to any endpoint address, local or not.
*/
- if ((inp->inp_flags & INP_BINDANY) == 0 &&
+ if (VNET(inp_bindany) == 0 &&
+ (inp->inp_flags & INP_BINDANY) == 0 &&
ifa_ifwithaddr_check((struct sockaddr *)sin) == 0)
return (EADDRNOTAVAIL);
}
diff --git a/sys/netinet/in_pcb.h b/sys/netinet/in_pcb.h
index 4ba19e6..3720121 100644
--- a/sys/netinet/in_pcb.h
+++ b/sys/netinet/in_pcb.h
@@ -467,6 +467,7 @@ VNET_DECLARE(int, ipport_randomcps);
VNET_DECLARE(int, ipport_randomtime);
VNET_DECLARE(int, ipport_stoprandom);
VNET_DECLARE(int, ipport_tcpallocs);
+VNET_DECLARE(int, inp_bindany);
#defineV_ipport_reservedhigh VNET(ipport_reservedhigh)
#defineV_ipport_reservedlowVNET(ipport_reservedlow)
diff --git a/sys/netinet/raw_ip.c b/sys/netinet/raw_ip.c
index c91d4a9..17a2e78 100644
--- a/sys/netinet/raw_ip.c
+++ b/sys/netinet/raw_ip.c
@@ -897,6 +897,7 @@ rip_bind(struct socket *so, struct sockaddr *nam,
struct thread *td)
if (TAILQ_EMPTY(&V_ifnet) ||
(addr->sin_family != AF_INET && addr->sin_family != AF_IMPLINK) ||
(addr->sin_addr.s_addr &&
+ VNET(inp_bindany) == 0 &&
(inp->inp_flags & INP_BINDANY) == 0 &&
ifa_ifwithaddr_check((struct sockaddr *)addr) == 0))
return (EADDRNOTAVAIL);
>
>> Do you mean there is a way to control user input (ie 0 or 42, but
>> nothing else)?
>
> No, I meant that if you'll use the custom sysctl value handler (via
> SYSCTL_VNET_PROC, not vie SYSCTL_VNET_INT), then you can convert any
> non-zero value to INP_BINDANY and zero to zero. But given the need of
> locking, I don't think that this won't be good to take this road: one
> simple non-conditional logical instruction will be harmless even if it
> is executed when it is not needed; but the block of
> lock-logicalop-unlock will be worse.
> --
> Eygene Ryabinkin ,,,^..^,,,
> [ Life's unfair - but root password helps! | codelabs.ru ]
> [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sys/boot/boot0/boot0.S - r186598
On Sun, Jan 09, 2011 at 12:57:24PM -0600, Tom Judge wrote: > On 09/01/2011 12:33, Luigi Rizzo wrote: > > On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: > >> Hi, > >> > >> Today I ran into an issue where setting the default slice with boot0cfg > >> -s is broken. > > a few questions inline: > > > Output inline, full script log attached. > > If you need more info let me know. can you take a dump of the boot sector at various stages indicated below: > DUMP #1: ORIGINAL BOOT SECTOR DUMP #2: AFTER THE BOOT SECTOR UPDATE DUMP #3: AFTER A REBOOT WITH NO KEYPRESS DUMP #4: AFTER THE SUCCESSFUL BOOT IN SLICE 2 At least from this we can tell how #4 differs from #2/#3 cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sys/boot/boot0/boot0.S - r186598
On 09/01/2011 12:33, Luigi Rizzo wrote: > On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: >> Hi, >> >> Today I ran into an issue where setting the default slice with boot0cfg >> -s is broken. > a few questions inline: > Output inline, full script log attached. If you need more info let me know. >> Update the active slice to 2: >> === >> # boot0cfg -s 2 -v ad0 >> # flag start chs type end chs offset size >> 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 >> 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 >> 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 >> >> version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) >> options=packet,update,nosetdrv >> volume serial ID 9090-9090 >> default_selection=F2 (Slice 2) >> === > what do you get here if you re-run > > boot0cfg -v ad0 > > before rebooting ? It seems that boot0cfg does not re-read > data from disk so if the write for some reason fails > (e.g. kern.geom.debugflags=0) you don't see the actual configuration > of the boot sector. > Looking at the code there should be an error message if writing > to disk fails, but maybe the error reporting oes not work well... > > Fresh transcript: # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F1 (Slice 1) # boot0cfg -s 2 -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # >> Reboot and let boot0 time out and boot default slice 2: >> === >> # boot0cfg -v ad0 >> # flag start chs type end chs offset size >> 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 >> 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 >> 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 >> >> version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) >> options=packet,update,nosetdrv >> volume serial ID 9090-9090 >> default_selection=F2 (Slice 2) >> === >> The system actually booted into slice 1 here. > What does the system show as Default when it reboots ? F1 or F2 ? > This is just to check if the update actually went to disk. > > # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # shutdown -r now Shutdown NOW! shutdown: [pid 1104] # Rebooting... 1 FreeBSD 2 FreeBSD F6 PXE Boot: 2 -- Let time out, snip loader/beastie hit 6 at the menu -- OK show loaddev disk0s1a: OK --boot system and login -- # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # mount /dev/label/nanobsd1 on / (ufs, local, read-only) devfs on /dev (devfs, local, multilabel) /dev/md0 on /etc (ufs, local) /dev/md1 on /var (ufs, local) # glabel status |grep nanobsd label/nanobsd1 N/A ad0s1a label/nanobsd2 N/A ad0s2a # >> This was verified by dropping to the loader prompt and using show to grab: >> loaddev=disk0s1a: >> >> Reboot and hit 2 at the boot0 prompt: >> === >> # boot0cfg -v ad0 >> # flag
Re: NFS performance
As requested earlier, I've moved the thread to freebsd-stable. -- George ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sys/boot/boot0/boot0.S - r186598
On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: > Hi, > > Today I ran into an issue where setting the default slice with boot0cfg > -s is broken. a few questions inline: > This is related to a section of this revision: > > + commit Warner's patch "orb $NOUPDATE,_FLAGS(%bp)" > to avoid writing to disk in case of a timeout/default choice; > > This issue is quite well documented in bin/134907 which has been open > since May 2009. > > Reproduced with a fresh nanobsd build: > > Boot 1 - Slice 1 active as set by nanobsd image builder: > > === > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F1 (Slice 1) > === > > Update the active slice to 2: > === > # boot0cfg -s 2 -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F2 (Slice 2) > === what do you get here if you re-run boot0cfg -v ad0 before rebooting ? It seems that boot0cfg does not re-read data from disk so if the write for some reason fails (e.g. kern.geom.debugflags=0) you don't see the actual configuration of the boot sector. Looking at the code there should be an error message if writing to disk fails, but maybe the error reporting oes not work well... > Reboot and let boot0 time out and boot default slice 2: > === > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F2 (Slice 2) > === > The system actually booted into slice 1 here. What does the system show as Default when it reboots ? F1 or F2 ? This is just to check if the update actually went to disk. > This was verified by dropping to the loader prompt and using show to grab: > loaddev=disk0s1a: > > Reboot and hit 2 at the boot0 prompt: > === > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x00 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x80495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F2 (Slice 2) > === > > This time we really boot into slice 2. > > The attached patch backs out the relevant part of r186598. > > There was a post on the embedded list that suggested this work around: > echo 'a 2' | fdisk -f /dev/stdin ad0 > boot0cfg -s 2 ad0 > > There are 2 issues with this: > 1) It can't be done without setting kern.geom.debugflags to 0x10. > 2) It resulted in most/all commands resulting in the error message > "Device not configured" including the second command and 'shutdown -r now'. > > Both of which leave this really work around fairly broken. > > > Tom > cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sys/boot/boot0/boot0.S - r186598
On 09/01/2011 04:38, Daniel Braniss wrote: >> There was a post on the embedded list that suggested this work around: >> echo 'a 2' | fdisk -f /dev/stdin ad0 >> boot0cfg -s 2 ad0 >> >> There are 2 issues with this: >> 1) It can't be done without setting kern.geom.debugflags to 0x10. >> 2) It resulted in most/all commands resulting in the error message >> "Device not configured" including the second command and 'shutdown -r now= >> '. >> >> Both of which leave this really work around fairly broken. > the problem is that boot0cfg -s does NOT update the boot block, it fails! > the work around is: > boot0cfg -s -t n dev > then > gpart set -a active -i n dev > > danny > Hi Danny, The bug does not seem to be in boot0cfg as: 1) It succeeds to write the new configuration to the boot block every time i have tried. 2) It does not touch the partition table at all only the mbr, so it was never designed to change the active partition. If this is not a bug in boot0 then its a bug in the man pages for boot0cfg as it does make reference to having to change the active slice to make this work. Tom signature.asc Description: OpenPGP digital signature
Re: NFS Performance
> Rick > Do you have more details on the issue is it 8.x only ? Can you point > us to the stable thread abourt this ? > The bug is in the krpc, which means it's 8.x specific (at least for NFS, I'm not sure if the nlm used the krpc in 7.x?). David P. Discher reported a performance problem some time ago when testing the FreeBSD8 client against certain servers. (I can't find the thread, so maybe it never had a freebsd-stable@ cc after all.) Fortutnately John Gemignani spotted the cause (for at least his case, because he tested a patch that seemed to resolve the problem). The bug is basically that the client side krpc for TCP assumed that the 4 bytes of data that hold the length of the RPC message are in one mbuf and don't straddle multiple mbufs. If the 4 bytes does straddle multiple mbufs, the krpc gets a "garbage message length" and then typically wedges and eventually recovers by starting a fresh TCP connection up and retrying the outstanding RPCs. I have no idea if George is seeing the same problem, but the 1.5minute logjams suggest that it might. I emailed him a patch and, hopefully, he will report back on whether or not it helped. A patch for the above bug is "in the works" for head, rick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sys/boot/boot0/boot0.S - r186598
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --enig51B4786EC9D39188BAE04052 > Content-Type: multipart/mixed; boundary="070003060308030201090207" > > This is a multi-part message in MIME format. > --070003060308030201090207 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Hi, > > Today I ran into an issue where setting the default slice with boot0cfg > -s is broken. > > This is related to a section of this revision: > > + commit Warner's patch "orb $NOUPDATE,_FLAGS(%bp)" > to avoid writing to disk in case of a timeout/default choice; > > This issue is quite well documented in bin/134907 which has been open > since May 2009. > > Reproduced with a fresh nanobsd build: > > Boot 1 - Slice 1 active as set by nanobsd image builder: > > =3D=3D=3D > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) > options=3Dpacket,update,nosetdrv > volume serial ID 9090-9090 > default_selection=3DF1 (Slice 1) > =3D=3D=3D > > Update the active slice to 2: > =3D=3D=3D > # boot0cfg -s 2 -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) > options=3Dpacket,update,nosetdrv > volume serial ID 9090-9090 > default_selection=3DF2 (Slice 2) > =3D=3D=3D > > Reboot and let boot0 time out and boot default slice 2: > =3D=3D=3D > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) > options=3Dpacket,update,nosetdrv > volume serial ID 9090-9090 > default_selection=3DF2 (Slice 2) > =3D=3D=3D > The system actually booted into slice 1 here. > This was verified by dropping to the loader prompt and using show to grab= > : > loaddev=3Ddisk0s1a: > > Reboot and hit 2 at the boot0 prompt: > =3D=3D=3D > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x00 0: 1: 1 0xa5494: 15:63 63 498897 > 2 0x80495: 1: 1 0xa5989: 15:63 499023 498897 > 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 > > version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) > options=3Dpacket,update,nosetdrv > volume serial ID 9090-9090 > default_selection=3DF2 (Slice 2) > =3D=3D=3D > > This time we really boot into slice 2. > > The attached patch backs out the relevant part of r186598. > > There was a post on the embedded list that suggested this work around: > echo 'a 2' | fdisk -f /dev/stdin ad0 > boot0cfg -s 2 ad0 > > There are 2 issues with this: > 1) It can't be done without setting kern.geom.debugflags to 0x10. > 2) It resulted in most/all commands resulting in the error message > "Device not configured" including the second command and 'shutdown -r now= > '. > > Both of which leave this really work around fairly broken. the problem is that boot0cfg -s does NOT update the boot block, it fails! the work around is: boot0cfg -s -t n dev then gpart set -a active -i n dev danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
