Re: FQDNs for netbooted hosts via DHCP?
On Mon, 16 Jul 2018, Roy Marples wrote: > Sadly, all my machines are x86 based. I have an ERLITE mips router where I > also run dhcpcd, and it doesn't stamp on routes there either, so I'm pretty > sure this isn't an arch issue ... but I could be wrong. The only route that was an issue was the local route to the NFS server. Somehow a netbooted x86 system can complete the configuration, but non-x86 dies as soon as 'dhcpcd' (or the earlier 'dhclient') touches the interface. Interface is downed, root file system is gone, can't bring interface back up, game over. I've got a fresh build of -current just installed for the netbooted Lemote YeeLoong. Need to give it a whirl with "dhcp" in the "ifconfig.rtk0" file and see if the situation has changed. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: FQDNs for netbooted hosts via DHCP?
On 15/07/2018 23:54, John D. Baker wrote: On Sun, 15 Jul 2018, Roy Marples wrote: But have we considered an alternative? The in kernel DHCP client as I see it is just to handle network booting yes? Once userland is netmounted, dhcpcd can then take over? If so, does the kernel DHCP This seems to be a condition unique to x86 platforms, that one can re-configure the network interface with 'dhcpcd' (and in the past, 'dhclient') on a netbooted host. All the non-x86 platforms I've tried this with hang (NFS error 69) when the network interface is reconfigured. Possibly arrange for 'dhcpcd' to not touch the interface, but just gather and set up the ancillary information requested/provided. As of dhcpcd-7 at least that should no longer be the case. So -current and -8, dhcpcd won't touch pre-existing routes if it doesn't need to. I don't recall you saying what NetBSD or dhcpcd version you were using. Roy
Re: FQDNs for netbooted hosts via DHCP?
On Sun, 15 Jul 2018, Roy Marples wrote: > But have we considered an alternative? The in kernel DHCP client as > I see it is just to handle network booting yes? Once userland is > netmounted, dhcpcd can then take over? If so, does the kernel DHCP This seems to be a condition unique to x86 platforms, that one can re-configure the network interface with 'dhcpcd' (and in the past, 'dhclient') on a netbooted host. All the non-x86 platforms I've tried this with hang (NFS error 69) when the network interface is reconfigured. Possibly arrange for 'dhcpcd' to not touch the interface, but just gather and set up the ancillary information requested/provided. > client even need to set the hostname? If not, we can remove that to > make the kernel smaller. Indeed, those netbooted hosts in my tests which didn't get a name at all via the in-kernel DHCP client had no trouble booting. I didn't test the case where 'dhcpcd' wasn't running, however. IIRC, it'll just end up as "Amnesiac" (via 'getty', or "1" in 'xdm') and one can set the preferred name in "rc.conf". -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: FQDNs for netbooted hosts via DHCP?
On 15/07/2018 12:16, Robert Elz wrote: | The only other concern I have with this is that if we have two | interfaces and dhcpcd receives the same short hostname on both but only | a domain on one of them, then the hostname will flip-flop between short | and long hostnames. I'm not sure I see that (and in any case that kind of server mis-config is likely to cause issues anyway) but I will accept your more experience in this area. And no, we would not want that. | This is probably unlikely, but is worth pointing out. The way I see it, the best way of fixing this is to improve the in kernel dhcp client to set the fqdn using hostname + domain and control the default behaviour via sysctl (I do agree with kre that FQDN should be the default). But have we considered an alternative? The in kernel DHCP client as I see it is just to handle network booting yes? Once userland is netmounted, dhcpcd can then take over? If so, does the kernel DHCP client even need to set the hostname? If not, we can remove that to make the kernel smaller. Roy
Re: FQDNs for netbooted hosts via DHCP?
On Sun 15 Jul 2018 at 18:16:15 +0700, Robert Elz wrote: > The test "language" was very badly defined (ie: not at all really.) > > To avoid problems with that, there are very specific rules about > where to look for operators depending upon just how many args > exist - with those rules, it is possible to use test safely. But > when it gets to > 4 args (or even some cases with just 4) it > is just too hard to create meaningful usage rules that anyone would > understand or remember. What one hand giveth ( expression1 -a expression2, ( expression ) ) the other hand taketh away... Rather silly. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: booting from gpt/raid?
On Thu 05 Jul 2018 at 10:52:12 +0300, Andreas Gustafsson wrote:
> MLH wrote:
> > Boot Options are:
> > Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN
>
> A USB memory stick emulates a hard drive, so USB-HDD should work.
A USB stick formatted like a hard drive *should* always work.
Many BIOSes also allow booting from a USB stick formatted as a cdrom,
i.e. filled with an .iso image.
Here is a script I once made to create a bootable dvd from the install
sets. I made it to have a non-standard live and install dvd that also
includes all sources. I had also been trying to include (apart from the
amd64 version) i386 and VAX on the same dvd, but I didn't get far with
that.
This one was working for 7.1.1/amd64.
#!/bin/sh
# Make a bootable cd for amd64.
# If the same method works for VAX, I have to look into.
#
#set -x
arch=amd64
sets="kern-GENERIC modules base comp etc games man misc text"
xsets="xbase xcomp xetc xfont xserver"
work=work.$arch
top=$(pwd)
what=${top##*/}
mkdir $work
cd $work
umask
echo "Creating a ${what} dvd image:"
for set in $sets $xsets
do
echo "Extracting ${set} (using chroot)..."
tar --chroot -x -p -z -f $top/$arch/binary/sets/${set}.tgz
done
# Put bootfiles in place:
# For amd64:
cp -p ./usr/mdec/boot .
cp -p ./usr/mdec/bootxx_cd9660 ./bootxx_cd9660.${arch}
cat >boot.cfg etc/rc.d/filltmpfs <<'EOF'
# PROVIDE: filltmpfs
# REQUIRE: root
# BEFORE: mountcritlocal
$_rc_subr_loaded . /etc/rc.subr
name="filltmpfs"
rcvar="filltmpfs"
start_cmd="filltmpfs_start"
stop_cmd=":"
filltmpfs_start()
{
# hack to get around bugs in kernfs's rootdev/rrootdev lookup.
ls -l /dev/* > /dev/null 2>&1
# prepare important directories in the tmpfses, so dhcpcd and vi will work
echo "Prepare important directories in the tmpfses, so dhcpcd and vi will
work."
mount_critical_filesystems local
/bin/mkdir -p /var/run /var/db /var/log /var/tmp /var/spool /var/cron
touch /var/log/messages /var/log/authlog /var/log/cron /var/log/xferlog
touch /var/log/lpd-errs /var/log/maillog
}
load_rc_config $name
run_rc_command "$1"
EOF
chmod a+x etc/rc.d/filltmpfs
cat >etc/fstab <>etc/rc.conf <<'EOF'
critical_filesystems_local="$critical_filesystems_local /tmp"
rc_configured=YES
filltmpfs=YES
mountall=YES
hostname="installer"
postfix=NO
no_swap=YES
wscons=YES
EOF
sed etc/ttys.new \
-e '/^console/s/on /off /' \
-e '/^ttyE/s/off /on /'
mv etc/ttys.new etc/ttys
mkdir mnt2 targetroot kern proc
ln -s . release
echo "Link in distribution:"
ln ${top}/CHANGES* ${top}/LAST_MINUTE ${top}/README.files .
(cd ${top}; find ${arch} source shared -type d ) |
while read dir
do
echo "${dir}"
mkdir -p ${dir}
ln ${top}/${dir}/* ${dir}/ 2>/dev/null
done
cd dev
rm -f console # force the system to make a tmpfs /dev
# ./MAKEDEV all
cd ..
echo "Creating the iso image..."
makefs -t cd9660 \
-o
"bootimage=i386;usr/mdec/bootxx_cd9660,no-emul-boot,rockridge,allow-deep-trees,allow-multidot,volumeid=${what}.${arch}"
\
${top}/live-and-install.$arch.iso .
cd $top
echo "Testing the image:"
echo dd if=/dev/zero of=disk.img bs=1m count=1536
echo qemu-system-x86_64 -cdrom boot.amd64.iso -drive
file=disk.img,index=0,media=disk,format=raw # -netdev user,id=mynet0 -device
e1000,netdev=mynet0
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
Re: PCI passthrough not working with bhyve and NetBSD
"Farid Joubbi" wrote: => I tried the install CD for the latest HEAD-201807121210Z. => It can see both the NICs, but they don't work. => Trying to configure them with DHCP, it looks as if the NIC is sending a => DISCOVERY but timing out never receiving anything back (I doubt that it is => actually sending anything on the wire). => Then it constantly throws this on the console: "wm0: device timeout (lost => interrupt)". That sounds like the kernel missing interrupts from the NIC, in which case it may actually be sending out the requests but failing to see the replies. Perhaps posting the dmesg, or at least the lines about the NICs, could help. Gary Duzan => On Sat, Jul 14, 2018 at 8:34 PM Farid Joubbi wrote: => =>> I have a working configuration for NetBSD on bhyve. It's not a problem =>> with vm-bhyve https://github.com/churchers/vm-bhyve =>> =>> NetBSD 7.1.2 does not initiate the bge0 nor wm0 at all under bhyve, as I =>> wrote earlier. =>> It seems to run perfectly fine other than that. =>> The "normal" vioif0 works fine. =>> =>> I tried NetBSD 8.0 RC2. =>> It finds both NICs! All of a sudden I feel hope ;-) =>> Unfortunately I can only get link-local addresses on both NICs. =>> And I also get this printed on the console every now and then: "bge0: =>> watchdog timeout -- resetting". =>> =>> I will try and get it to NetBSD-current and see. =>> =>> =>> On Tue, Jul 10, 2018 at 5:30 AM Travis Paul wrote: =>> =>>> =>>> =>>> > On 9 Jul 2018, at 5:58 AM, Farid Joubbi wrote: =>>> > =>>> > Thanks for the reply. =>>> > After reading it, I realize that the learning curve for me to =>>> understand what is going on is a bit too steep. =>>> > I know only some basic C programming from university courses several =>>> years ago. =>>> > This kind of learning was not what I had in mind when I figured that =>>> I =>>> want to run a new NetBSD installation this summer... ;-( =>>> =>>> FWIW, NetBSD runs fine on Bhyve without PCI passthru. I'm running a few =>>> NetBSD 7 and 8 VMs on FreeBSD 11. =>>> =>>> I can share some commands to get a NetBSD system up if you're =>>> interested =>>> but I'm not using PCI passthru so I can't assist there. =>>> =>>> Best, =>>> Travis =>>> =>> =>
Re: FQDNs for netbooted hosts via DHCP?
Date:Sun, 15 Jul 2018 11:18:22 +0100
From:Roy Marples
Message-ID:
| If we're going to test that, then we need to check the converse for
| ${hsort} && [ "$hostname" = "${hostname%%.*}" ]
First irrelevant comment, the %%.* instead of #*. is an irrelevant variation,
the only point of this comparison is to see whether there is a '.' in
${hostname} and both ways modify the expansion if a '.' appears, and
leave it unchanged (and comparing equal) if not, so it makes no difference
which is used (I originally wrote the line using % instead of # but then
saw that you had used # elsewhere, and made it be consistent). It's
different in the cases where you want to actually use the result of course.
Hmm, now I look closer I see that you have used both forms already,
(though the %%.* form is used where you are actually comparing different
host name varss, so getting the value from it matters) so I guess this is even
less relevant than I thought!
More relevantly, and perhaps showing my extreme bias against short
form hostname settings, but no, I would not do that - the short form can
(and in the case in question, did) get set almost by accident. If the
FQDN form is preferred, then overriding the "accident" (the kernel needing
to config a name so it can boot over the net) is reasonable.
On the other hand, if a FQDN has been configured, it is almost certainly
deliberate, and probably should not be overridden.
| The actual change required is a bit more invasive than that line change
| though, but it suffices for this discussion.
OK, I was guessing a bit, and I agree with the last sentiment.
| The only other concern I have with this is that if we have two
| interfaces and dhcpcd receives the same short hostname on both but only
| a domain on one of them, then the hostname will flip-flop between short
| and long hostnames.
I'm not sure I see that (and in any case that kind of server mis-config
is likely to cause issues anyway) but I will accept your more experience
in this area.
And no, we would not want that.
| This is probably unlikely, but is worth pointing out.
Agreed - in any case this was just a (semi half baked, I certainly
did not consider all of the ramifications) suggestion to see if there
was some easier way to deal with the kernel self-configuring its
hostname in a more automated way than exists now. It would be
better if only that case was overridden, rather than the
hostname=short
in rc.conf form as well.
| You're referring to this?
| http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
|
| >4 arguments:
| The results are unspecified.
Yes.
| Well, Today I Learned something new I guess.
As I (think) I said, in the script in question there probably is no
issue, the "unspecified results" are because of what can happen
if some of the args happen to look just like test operators.
The test "language" was very badly defined (ie: not at all really.)
To avoid problems with that, there are very specific rules about
where to look for operators depending upon just how many args
exist - with those rules, it is possible to use test safely. But
when it gets to > 4 args (or even some cases with just 4) it
is just too hard to create meaningful usage rules that anyone would
understand or remember.
| I suppose my only concern is speed ... that would not produce any more
| subshells on NetBSD or any modern shell would it? Guess I should do some
| testing around that.
On NetBSD right now it probably would, the NetBSD sh forks itself into
oblivion for the most trivial of excuses... But that will get fixed sometime
hopefully not too far away (performance improvements are next on the
sh fix agenda once the actual known bugs are all gone...)
Most other shells, no, test (and [ ) is almost universally built in, and most
modern shells do not fork unnecessarily to run benign builtin commands.
But unless you're planning to run the expression in a tight loop, I really
would not worry about it, compared with the cost of starting the shell
to run the script, the cost of an extra fork to run an extra [ is noise
(even when done a few times during the life of the script.)
kre
Re: FQDNs for netbooted hosts via DHCP?
On 15/07/2018 11:18, Roy Marples wrote:
On 15/07/2018 03:37, Robert Elz wrote:
As with most client/server systems, there are two separate things that
need
to be made to work - the server has to send the data that you want it to
send (which might mean altering what the client requests, or server
config,
or ...) and then the client needs to "do the right thing" with the
data that is
returned.
Lastly, for this, I wonder if perhaps that final "false" in need_hostname
(in dhcpcd-hooks/30-hostname) might instead be something more like
${hfqdn} && [ "${hostname}" = "${hostname#*.}" ]
If we're going to test that, then we need to check the converse for
${hsort} && [ "$hostname" = "${hostname%%.*}" ]
The actual change required is a bit more invasive than that line change
though, but it suffices for this discussion.
Patch here:
http://www.netbsd.org/~roy/dhcpcd-hostname-promotion.diff
Please test and let me know if it works for you!
Roy
Re: FQDNs for netbooted hosts via DHCP?
On 15/07/2018 03:37, Robert Elz wrote:
As with most client/server systems, there are two separate things that need
to be made to work - the server has to send the data that you want it to
send (which might mean altering what the client requests, or server config,
or ...) and then the client needs to "do the right thing" with the data that is
returned.
Lastly, for this, I wonder if perhaps that final "false" in need_hostname
(in dhcpcd-hooks/30-hostname) might instead be something more like
${hfqdn} && [ "${hostname}" = "${hostname#*.}" ]
If we're going to test that, then we need to check the converse for
${hsort} && [ "$hostname" = "${hostname%%.*}" ]
The actual change required is a bit more invasive than that line change
though, but it suffices for this discussion.
so that (If I got that correct) if we want a FQDN as the hostname, and
what has been set (by something else) is not a FQDN but just a short
name, then we allow dhcpcd to set the FQDN (overriding whatever was
set before). If it had been this way, the force_hostname stuff would not
have been needed.
If that change is mde though it would need to be made clear that
(as the default is to set a FQDN) that simply setting a short hostname
in rc.conf would not be effective, dhcpcd.conf would also need to be
modified to allow short names if the DHCP server returns names.
The only other concern I have with this is that if we have two
interfaces and dhcpcd receives the same short hostname on both but only
a domain on one of them, then the hostname will flip-flop between short
and long hostnames.
This is probably unlikely, but is worth pointing out.
Roy: I'd also suggest getting rid of the '-a' operator in test arg lists,
while it is probably OK in all systems as used, it is not really
safe - test with more than 4 args (not counting the ']' when present)
produces unspecified results. Use && instead. There are two of
them in that script (well, the same one, more or less, in
need_hostname() and set_hostname())
You're referring to this?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
>4 arguments:
The results are unspecified.
Well, Today I Learned something new I guess.
I suppose my only concern is speed ... that would not produce any more
subshells on NetBSD or any modern shell would it? Guess I should do some
testing around that.
Roy
Re: PCI passthrough not working with bhyve and NetBSD
I tried the install CD for the latest HEAD-201807121210Z. It can see both the NICs, but they don't work. Trying to configure them with DHCP, it looks as if the NIC is sending a DISCOVERY but timing out never receiving anything back (I doubt that it is actually sending anything on the wire). Then it constantly throws this on the console: "wm0: device timeout (lost interrupt)". On Sat, Jul 14, 2018 at 8:34 PM Farid Joubbi wrote: > I have a working configuration for NetBSD on bhyve. It's not a problem > with vm-bhyve https://github.com/churchers/vm-bhyve > > NetBSD 7.1.2 does not initiate the bge0 nor wm0 at all under bhyve, as I > wrote earlier. > It seems to run perfectly fine other than that. > The "normal" vioif0 works fine. > > I tried NetBSD 8.0 RC2. > It finds both NICs! All of a sudden I feel hope ;-) > Unfortunately I can only get link-local addresses on both NICs. > And I also get this printed on the console every now and then: "bge0: > watchdog timeout -- resetting". > > I will try and get it to NetBSD-current and see. > > > On Tue, Jul 10, 2018 at 5:30 AM Travis Paul wrote: > >> >> >> > On 9 Jul 2018, at 5:58 AM, Farid Joubbi wrote: >> > >> > Thanks for the reply. >> > After reading it, I realize that the learning curve for me to >> understand what is going on is a bit too steep. >> > I know only some basic C programming from university courses several >> years ago. >> > This kind of learning was not what I had in mind when I figured that I >> want to run a new NetBSD installation this summer... ;-( >> >> FWIW, NetBSD runs fine on Bhyve without PCI passthru. I'm running a few >> NetBSD 7 and 8 VMs on FreeBSD 11. >> >> I can share some commands to get a NetBSD system up if you're interested >> but I'm not using PCI passthru so I can't assist there. >> >> Best, >> Travis >> >
