Re: Problemns after updating from 6.1.4 to 6.1.5
On Sat, 18 Oct 2014, Fredrik Pettai wrote: If you haven't tried them yet, I'd recommend using jmmv's sysbuild sysupgrade tools (http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade) for consistent builds upgrades without much manual interventions... Looks interesting. Of course, I'll probably have to tweak them to get the kernel installed properly in my DOMU :) * I have to load the kernel from an external partition using grub, and thus have to edit grub's menu.lst config file! * The booted kernel is independent of what is in /netbsd, so I currently have to manually gunzip(1) the kernel on the external partition and put the results in /netbsd - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: base.tgz no longer contains './bin/[' (in HEAD and netbsd-7)
On Sat, 18 Oct 2014, Markus Kilbinger wrote:
While looking for old / outdated binaries in userland I noticed that
'./bin/[' is no longer updated / part of base.tgz (or any other *.tgz
file) in HEAD and netbsd-7, though it still seems to be listed in
'src/distrib/sets/lists/base/mi'.
I can confirm that this is a problem. There appears to be
confusion about whether or not file names should be subjected to
vis/unvis encoding.
./bin/[ appears in the set lists and METALOG, as
expected, but the ${MTREE} -CS ... command in line 180 of
src/distrib/sets/maketars changes it to ./bin/\133, and then the
${PAX} -dOw ... command in line 199 fails to add the file to
base.tgz, and it also doesn't print an error message about failure
to add the file.
--apb (Alan Barrett)
Re: Problemns after updating from 6.1.4 to 6.1.5
On Oct 19, 5:32pm, Paul Goyette wrote: } On Sat, 18 Oct 2014, Fredrik Pettai wrote: } } If you haven't tried them yet, I'd recommend using jmmv's sysbuild } sysupgrade tools } (http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade) } for consistent builds upgrades without much manual interventions... } } Looks interesting. Of course, I'll probably have to tweak them to get } the kernel installed properly in my DOMU :) } } * I have to load the kernel from an external partition using grub, and }thus have to edit grub's menu.lst config file! } } * The booted kernel is independent of what is in /netbsd, so I currently }have to manually gunzip(1) the kernel on the external partition and }put the results in /netbsd Why would you be using grub when you're keeping the kernel outside the NetBSD partition. All you need to do is add: kernel = path to kernel to your domU config. xentools is fully capable of loading a NetBSD kernel, including one that is gzipped. An example from one of my config files is: kernel = /usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz This is not something that should be dependent on your dom0 as xentools is supplied by the Xen project. }-- End of excerpt from Paul Goyette
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sun, 19 Oct 2014, John Nemeth wrote: } * I have to load the kernel from an external partition using grub, and }thus have to edit grub's menu.lst config file! } } * The booted kernel is independent of what is in /netbsd, so I currently }have to manually gunzip(1) the kernel on the external partition and }put the results in /netbsd Why would you be using grub when you're keeping the kernel outside the NetBSD partition. All you need to do is add: kernel = path to kernel to your domU config. xentools is fully capable of loading a NetBSD kernel, including one that is gzipped. An example from one of my config files is: kernel = /usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz This is not something that should be dependent on your dom0 as xentools is supplied by the Xen project. Most likely, I don't know enough (approx zero) of the XEN environment to get it right. I'm just following the explicit instructions from my DOM0 provider. As a quick summary, I initially boot up a common DOMU which runs some variant of Linux. A customer-specific very small ext2fs partition is mounted (based on my login information) on which I put my grub menu.lst file and the kernel(s) I need to boot. This partition is accessible after boot, so once I get things up and running I don't have to touch the Linux world again. (Unless, of course, I manage to completely destroy my NetBSD system, and thus would need to reinstall it from scratch.) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Problemns after updating from 6.1.4 to 6.1.5
On Oct 20, 6:38am, Paul Goyette wrote:
} On Sun, 19 Oct 2014, John Nemeth wrote:
}
} } * I have to load the kernel from an external partition using grub, and
} }thus have to edit grub's menu.lst config file!
} }
} } * The booted kernel is independent of what is in /netbsd, so I currently
} }have to manually gunzip(1) the kernel on the external partition and
} }put the results in /netbsd
}
} Why would you be using grub when you're keeping the kernel
} outside the NetBSD partition. All you need to do is add:
}
} kernel = path to kernel
}
} to your domU config. xentools is fully capable of loading a NetBSD
} kernel, including one that is gzipped. An example from one of my
} config files is:
}
} kernel = /usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz
}
} This is not something that should be dependent on your dom0 as
} xentools is supplied by the Xen project.
}
} Most likely, I don't know enough (approx zero) of the XEN environment to
} get it right. I'm just following the explicit instructions from my DOM0
} provider.
So, you're using a VPS. This can change everything depending
on how they do things. Which raises the question, who is the
provider?
} As a quick summary, I initially boot up a common DOMU which runs some
} variant of Linux. A customer-specific very small ext2fs partition is
} mounted (based on my login information) on which I put my grub menu.lst
} file and the kernel(s) I need to boot. This partition is accessible
This tells me that they are most likely using pygrub or pvgrub.
Basically these things dig around in the image for the domU to find
a grub config file, which then tells p[yv]grub what needs to be
extracted (i.e. it will copy the kernel {and initramhd for linux}
out of the image and hand it to Xen). This also tells me that in
your case, the menu.lst thing is necessary.
}-- End of excerpt from Paul Goyette
daily CVS update output
Updating src tree: P src/crypto/external/bsd/openssh/Makefile.inc P src/crypto/external/bsd/openssh/bin/Makefile.inc P src/crypto/external/bsd/openssh/bin/sshd/Makefile P src/crypto/external/bsd/openssh/dist/LICENCE P src/crypto/external/bsd/openssh/dist/OVERVIEW P src/crypto/external/bsd/openssh/dist/PROTOCOL P src/crypto/external/bsd/openssh/dist/PROTOCOL.agent P src/crypto/external/bsd/openssh/dist/PROTOCOL.certkeys U src/crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 U src/crypto/external/bsd/openssh/dist/PROTOCOL.key P src/crypto/external/bsd/openssh/dist/PROTOCOL.mux P src/crypto/external/bsd/openssh/dist/README P src/crypto/external/bsd/openssh/dist/addrmatch.c P src/crypto/external/bsd/openssh/dist/atomicio.c P src/crypto/external/bsd/openssh/dist/atomicio.h P src/crypto/external/bsd/openssh/dist/auth-bsdauth.c P src/crypto/external/bsd/openssh/dist/auth-chall.c P src/crypto/external/bsd/openssh/dist/auth-krb5.c P src/crypto/external/bsd/openssh/dist/auth-options.c P src/crypto/external/bsd/openssh/dist/auth-options.h P src/crypto/external/bsd/openssh/dist/auth-pam.c P src/crypto/external/bsd/openssh/dist/auth-pam.h P src/crypto/external/bsd/openssh/dist/auth-passwd.c P src/crypto/external/bsd/openssh/dist/auth-rh-rsa.c P src/crypto/external/bsd/openssh/dist/auth-rhosts.c P src/crypto/external/bsd/openssh/dist/auth-rsa.c P src/crypto/external/bsd/openssh/dist/auth-skey.c P src/crypto/external/bsd/openssh/dist/auth.c P src/crypto/external/bsd/openssh/dist/auth.h P src/crypto/external/bsd/openssh/dist/auth1.c P src/crypto/external/bsd/openssh/dist/auth2-chall.c P src/crypto/external/bsd/openssh/dist/auth2-gss.c P src/crypto/external/bsd/openssh/dist/auth2-hostbased.c cvs update: `src/crypto/external/bsd/openssh/dist/auth2-jpake.c' is no longer in the repository P src/crypto/external/bsd/openssh/dist/auth2-kbdint.c P src/crypto/external/bsd/openssh/dist/auth2-krb5.c P src/crypto/external/bsd/openssh/dist/auth2-none.c P src/crypto/external/bsd/openssh/dist/auth2-passwd.c P src/crypto/external/bsd/openssh/dist/auth2-pubkey.c P src/crypto/external/bsd/openssh/dist/auth2.c P src/crypto/external/bsd/openssh/dist/authfd.c P src/crypto/external/bsd/openssh/dist/authfd.h P src/crypto/external/bsd/openssh/dist/authfile.c P src/crypto/external/bsd/openssh/dist/authfile.h U src/crypto/external/bsd/openssh/dist/bcrypt_pbkdf.c U src/crypto/external/bsd/openssh/dist/blf.h U src/crypto/external/bsd/openssh/dist/blocks.c U src/crypto/external/bsd/openssh/dist/blowfish.c P src/crypto/external/bsd/openssh/dist/bufaux.c P src/crypto/external/bsd/openssh/dist/bufbn.c P src/crypto/external/bsd/openssh/dist/bufec.c P src/crypto/external/bsd/openssh/dist/buffer.c P src/crypto/external/bsd/openssh/dist/buffer.h P src/crypto/external/bsd/openssh/dist/canohost.c P src/crypto/external/bsd/openssh/dist/canohost.h U src/crypto/external/bsd/openssh/dist/chacha.c U src/crypto/external/bsd/openssh/dist/chacha.h P src/crypto/external/bsd/openssh/dist/channels.c P src/crypto/external/bsd/openssh/dist/channels.h P src/crypto/external/bsd/openssh/dist/cipher-3des1.c U src/crypto/external/bsd/openssh/dist/cipher-aesctr.c U src/crypto/external/bsd/openssh/dist/cipher-aesctr.h P src/crypto/external/bsd/openssh/dist/cipher-bf1.c U src/crypto/external/bsd/openssh/dist/cipher-chachapoly.c U src/crypto/external/bsd/openssh/dist/cipher-chachapoly.h P src/crypto/external/bsd/openssh/dist/cipher-ctr-mt.c P src/crypto/external/bsd/openssh/dist/cipher.c P src/crypto/external/bsd/openssh/dist/cipher.h P src/crypto/external/bsd/openssh/dist/cleanup.c P src/crypto/external/bsd/openssh/dist/clientloop.c P src/crypto/external/bsd/openssh/dist/clientloop.h P src/crypto/external/bsd/openssh/dist/compat.c P src/crypto/external/bsd/openssh/dist/compat.h P src/crypto/external/bsd/openssh/dist/compress.c P src/crypto/external/bsd/openssh/dist/compress.h P src/crypto/external/bsd/openssh/dist/crc32.c P src/crypto/external/bsd/openssh/dist/crc32.h U src/crypto/external/bsd/openssh/dist/crypto_api.h P src/crypto/external/bsd/openssh/dist/deattack.c P src/crypto/external/bsd/openssh/dist/deattack.h P src/crypto/external/bsd/openssh/dist/dh.c P src/crypto/external/bsd/openssh/dist/dh.h U src/crypto/external/bsd/openssh/dist/digest-libc.c U src/crypto/external/bsd/openssh/dist/digest-openssl.c U src/crypto/external/bsd/openssh/dist/digest.h P src/crypto/external/bsd/openssh/dist/dispatch.c P src/crypto/external/bsd/openssh/dist/dispatch.h P src/crypto/external/bsd/openssh/dist/dns.c P src/crypto/external/bsd/openssh/dist/dns.h U src/crypto/external/bsd/openssh/dist/ed25519.c P src/crypto/external/bsd/openssh/dist/fatal.c U src/crypto/external/bsd/openssh/dist/fe25519.c U src/crypto/external/bsd/openssh/dist/fe25519.h P src/crypto/external/bsd/openssh/dist/fmt_scaled.c P src/crypto/external/bsd/openssh/dist/fmt_scaled.h U src/crypto/external/bsd/openssh/dist/ge25519.c U src/crypto/external/bsd/openssh/dist/ge25519.h U
