Re: 5.7: size for ninja distfile?
I seem to be getting a lot of size does not match errors (unusual) leading to error 1. But when I up-arrow and replay the line it goes past it. On 5/18/15, Alan Corey wrote: > I kept getting "size does not match for ninja-1.5.3p0" and several of > the alternate sources were giving errors like 404. > > I have a file size of 168829 for > 3309498174411e02e7680ea8b470bb7d1d70bdb8.tar.gz and the archive tests > OK with gunzip -t. This size does match the distinfo, but there are > notes in the makefile about a toolchain error. > > I tried downloading ninja-1.5.3.tar.gz from > https://pypi.python.org/pypi/ninja but that didn't help. > > I finally installed the package instead. Back to building cmake for > firefox. > > -- > Credit is the root of all evil. - AB1JX > -- Credit is the root of all evil. - AB1JX
5.7: size for ninja distfile?
I kept getting "size does not match for ninja-1.5.3p0" and several of the alternate sources were giving errors like 404. I have a file size of 168829 for 3309498174411e02e7680ea8b470bb7d1d70bdb8.tar.gz and the archive tests OK with gunzip -t. This size does match the distinfo, but there are notes in the makefile about a toolchain error. I tried downloading ninja-1.5.3.tar.gz from https://pypi.python.org/pypi/ninja but that didn't help. I finally installed the package instead. Back to building cmake for firefox. -- Credit is the root of all evil. - AB1JX
Error when compiling libcrypto after 003_openssl.patch
Three weeks ago, I manually upgraded a dedicated server from 5.6 to 5.7. I couldn't use the ramdisk because I have a budget provider that effectively doesn't offer KVM access. I followed the published instructions carefully and everything seems to be working. Patch 002 applied and built cleanly, and patch 003 applied without issue. However, I get the error shown below when I attempt to build libcrypto for patch 003. I have libcrypto.so versions 30 and 32. In case libcrypto.so.30 was a vestige of 5.6 and was interfering, I built and reinstalled libssl after disabling libcrypto.so.30 with chmod. I then tried building libcrypto again, but got the same error. b_sock.so is mentioned in the error output, but I only have one instance of it, and it would have been updated when I built and reinstalled libssl. I don't have much experience with shared libraries, so I thought I should stop tinkering before I break something. At least one other user on Freenode had the same issue but hadn't yet looked into it. Has anyone else experienced this? Any ideas about what might be causing it? $ sudo sh -c 'cd /usr/src/lib/libcrypto/crypto && make obj && make && make install' /usr/src/lib/libcrypto/crypto/obj -> /usr/obj/lib/libcrypto/crypto building shared crypto library (version 32.0) cc -shared -fpic -o libcrypto.so.32.0 `lorder cryptlib.so malloc-wrapper.so mem_dbg.so cversion.so ex_data.so cpt_err.so uid.so o_time.so o_str.so o_init.s o mem_clr.so aes_misc.so aes_ecb.so aes_cfb.so aes_ofb.so aes_ctr.so aes_ige.so aes_wrap.so a_object.so a_bitstr.so a_utctm.so a_gentm.so a_time.so a_int.so a_octet.so a_print.so a_type.so a_dup.so a_d2i_fp.so a_i2d_fp.so a_enum.so a_utf8.so a_sign.so a_digest.so a_verify.so a_mbstr.so a_strex.so x_algor.so x_val .so x_pubkey.so x_sig.so x_req.so x_attrib.so x_bignum.so x_long.so x_name.so x_x509.so x_x509a.so x_crl.so x_info.so x_spki.so nsseq.so x_nx509.so d2i_pu.so d2i_pr.so i2d_pu.so i2d_pr.so t_req.so t_x509.so t_x509a.so t_crl.so t_pkey.so t_spki.so t_bitst.so tasn_new.so tasn_fre.so tasn_enc.so tasn_dec.so tasn_utl .so tasn_typ.so tasn_prn.so ameth_lib.so f_int.so f_string.so n_pkey.so f_enum.so x_pkey.so a_bool.so x_exten.so bio_asn1.so bio_ndef.so asn_mime.so asn1_gen .so asn1_par.so asn1_lib.so asn1_err.so a_bytes.so a_strnid.so evp_asn1.so asn_pack.so p5_pbe.so p5_pbev2.so p8_pkey.so asn_moid.so a_set.so bf_skey.so bf_ec b.so bf_cfb64.so bf_ofb64.so bio_lib.so bio_cb.so bio_err.so bss_mem.so bss_null.so bss_fd.so bss_file.so bss_sock.so bss_conn.so bf_null.so bf_buff.so b_pri nt.so b_dump.so b_posix.so b_sock.so bss_acpt.so bf_nbio.so bss_log.so bss_bio.so bss_dgram.so bn_add.so bn_div.so bn_exp.so bn_lib.so bn_ctx.so bn_mul.so bn _mod.so bn_print.so bn_rand.so bn_shift.so bn_word.so bn_blind.so bn_kron.so bn_sqrt.so bn_gcd.so bn_prime.so bn_err.so bn_sqr.so bn_recp.so bn_mont.so bn_mp i.so bn_exp2.so bn_gf2m.so bn_nist.so bn_depr.so bn_const.so bn_x931p.so buffer.so buf_err.so buf_str.so cmll_cfb.so cmll_ctr.so cmll_ecb.so cmll_ofb.so c_sk ey.so c_ecb.so c_enc.so c_cfb64.so c_ofb64.so chacha.so cmac.so cm_ameth.so cm_pmeth.so comp_lib.so comp_err.so c_rle.so c_zlib.so conf_err.so conf_lib.so co nf_api.so conf_def.so conf_mod.so conf_mall.so conf_sap.so cbc_cksm.so cbc_enc.so cfb64enc.so cfb_enc.so ecb3_enc.so ecb_enc.so enc_read.so enc_writ.so fcryp t.so ofb64enc.so ofb_enc.so pcbc_enc.so qud_cksm.so rand_key.so set_key.so xcbc_enc.so str2key.so cfb64ede.so ofb64ede.so ede_cbcm_enc.so dh_asn1.so dh_gen.s o dh_key.so dh_lib.so dh_check.so dh_err.so dh_depr.so dh_ameth.so dh_pmeth.so dh_prn.so dsa_gen.so dsa_key.so dsa_lib.so dsa_asn1.so dsa_vrf.so dsa_sign.so dsa_err.so dsa_ossl.so dsa_depr.so dsa_ameth.so dsa_pmeth.so dsa_prn.so dso_dlfcn.so dso_err.so dso_lib.so dso_null.so dso_openssl.so ec_lib.so ecp_smpl.so e cp_mont.so ecp_nist.so ec_cvt.so ec_mult.so ec_err.so ec_curve.so ec_check.so ec_print.so ec_asn1.so ec_key.so ec2_smpl.so ec2_mult.so ec_ameth.so ec_pmeth.s o eck_prn.so ecp_nistp224.so ecp_nistp256.so ecp_nistp521.so ecp_nistputil.so ecp_oct.so ec2_oct.so ec_oct.so ech_lib.so ech_ossl.so ech_key.so ech_err.so ec s_lib.so ecs_asn1.so ecs_ossl.so ecs_sign.so ecs_vrf.so ecs_err.so eng_err.so eng_lib.so eng_list.so eng_init.so eng_ctrl.so eng_table.so eng_pkey.so eng_fat .so eng_all.so tb_rsa.so tb_dsa.so tb_ecdsa.so tb_dh.so tb_ecdh.so tb_rand.so tb_store.so tb_cipher.so tb_digest.so tb_pkmeth.so tb_asnmth.so eng_openssl.so eng_cnf.so eng_dyn.so eng_rsax.so err.so err_all.so err_prn.so encode.so digest.so evp_enc.so evp_key.so e_des.so e_bf.so e_idea.so e_des3.so e_camellia.so e _rc4.so e_aes.so names.so e_xcbc_d.so e_rc2.so e_cast.so m_null.so m_md4.so m_md5.so m_sha.so m_sha1.so m_wp.so m_dss.so m_dss1.so m_mdc2.so m_ripemd.so m_ec dsa.so p_open.so p_seal.so p_sign.so p_verify.so p_lib.so p_enc.so p_dec.so bio_md.so bio_b64.so bio_enc.so evp_err.so e_null.so c_all.so evp_lib.so evp_pkey .so evp_pbe.so p5_crpt.so p5_crpt2.so e_old.so pmeth_lib.so pmeth_fn.so pmet
Re: Robustness in ports fetch program?
Try some of these ideas.
Change the config of pf to "conservative" or "high-latency" (man
pf.conf).
Use dpb to download the distfiles:
/usr/ports/infrastructure/bin/dpb -F 2 lang/tcl/8.5
(man -m /usr/ports/infrastructure/man dpb)
Change the ports framework to download the distfiles first from the
OpenBSD mastersites, and adjust the FTP keepalive:
export PORTS_INFRA="/usr/ports/infrastructure/db/network.conf"
echo '.include "../templates/network.conf.template"' > $PORTS_INFRA
echo 'MASTER_SITE_OPENBSD=ftp://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/' >>
$PORTS_INFRA
echo 'MASTER_SITE_OPENBSD=Yes' >> $PORTS_INFRA
echo 'FTP_KEEPALIVE=15' >> /etc/mk.conf
Create a shell/perl script which retries the download if the file
doesn't exists in the distfiles directory, and change FETCH_CMD to run
it. FETCH_CMD uses this by default: /usr/bin/ftp -V ${_PROGRESS}
-k ${FTP_KEEPALIVE} -C
On Sun, May 17, 2015 at 08:18:06AM -0400, Alan Corey wrote:
> I don't think it did this back in 5.0 days or maybe earlier. I started
> with OpenBSD 2.7, I just usually attributed problems to being my fault.
> And I've always used the ports tree, not packages. Distfiles are often
> useful across OpenBSD versions, sometimes in FreeBSD, I've even built some
> under Linux.
>
> I didn't look at what FETCH_CMD was defined as by default, I just assumed
> defining something non-null changed it. I did notice that when it retries
> it's wrongly assumed there's a problem with the first source and gone to
> another.
>
> Does every developer have perfect internet? That's very frustrating, maybe
> counterproductive in testing. Try a modem, you can probably find a free
> one. Connection interruptions and resets happen many times a day.
> On May 17, 2015 1:22 AM, "Marc Espie" wrote:
>
> > On Sat, May 16, 2015 at 10:31:24PM -0400, Alan Corey wrote:
> > > I'd seen this happen in 5.6 too, but I just caught an example of it in
> > > 5.7. My connection leaves a lot to be desired, but there's nothing I
> > > can do about that. I normally have FETCH_CMD set to use wget once I
> > > get it installed but this was in doing a standard make install of a
> > > port.
> > >
> > > The first time the connection gets interrupted, but something thinks
> > > it should be done and checks the size. That's wrong so it downloads
> > > it over again instead of just resuming the download. It should only
> > > download it over again if the size matches but the CRC is wrong.
> > > Seems like anyway.
> > >
> > > ===> Verifying install for tcl-8.5.16 in lang/tcl/8.5
> > > ===> Checking files for tcl-8.5.16p0
> > > >> Fetch
> > > >> http://downloads.sourceforge.net/sourceforge/tcl/tcl8.5.16-src.tar.gz
> > > tcl8.5.16-src.tar.gz 60% |*| 2696 KB
> > 00:00
> > > >> Size does not match for tcl8.5.16-src.tar.gz
> > > >> Fetch
> > http://ftp.openbsd.org/pub/OpenBSD/distfiles//tcl8.5.16-src.tar.gz
> > > tcl8.5.16-src.tar.gz 23% |** | 1024 KB
> > 00:03 ETA
> >
> > The problem lies in ftp(1).
> >
> > Logic in the ports tree is fine. But there's nothing it can do there:
> > somehow
> > your ftp returns 0 (e.g., success), so the partial file gets removed.
> >
> > If you want to get it fixed, you may have to provide more input, as we
> > obviously do not see that problem... First thing would be to override
> > FETCH_CMD to remove the -V, so that you can show us what ftp says about
> > things. Tracing the code thru the program would help.
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: Update OpenBSD Remotely
On Sun, May 17, 2015 at 03:08:43PM BST, Peter Leber wrote:
Hi Peter,
> Is there someone aware of a procedure which could help me solving my
> problem?
Like Atanas, I use a procedure suggested by Sébastien Marie[0].
There are several things which this script does not check for - some of
those are on my TODO list:
1. If you're upgrading from -stable to -current, then you'll need to
adjust '/etc/pkg.conf' file accordingly beforehand.
2. Your '/usr/src' directory needs to exist and contain the source code.
3. Sometimes a new snapshot might get published mid-download - you'll
simply need to re-run the script or you may simply wrap it in a loop.
4. You'll need to adjust the 'sets' manually.
5. Since it is aimed at frequent snapshot upgrades, it assumes you are
running GENERIC{.MP} kernel.
6. If you are already using '/etc/boot.conf' then you'll need to adjust
the script.
7. /dev/vnd0 is hard-coded and there's no logic there to check whether
it is in use - the same goes for '/tmp'.
8. You can add 'sysmerge', 'pkg_add -u', etc. to 'rc.firsttime' if you
like.
-
#!/bin/sh
arch=$(machine)
kernel="$(uname -v | cut -d '#' -f 1)"
release="$(uname -r)"
version="$(uname -r | tr -d '.')"
sets="base${version}.tgz comp${version}.tgz game${version}.tgz \
man${version}.tgz xbase${version}.tgz xfont${version}.tgz \
xserv${version}.tgz xshare${version}.tgz"
_snapshot() {
dir=/${release}/${arch}
test -d $dir || mkdir -p $dir
get="ftp -V -o"
site="$(awk '/^installpath/ { print $3 }' /etc/pkg.conf | rev | cut -d '/'
-f 1-2,4- | rev)"
case $kernel in
GENERIC)
bsd=bsd
;;
GENERIC.MP)
bsd="bsd bsd.mp"
;;
esac
cd $dir && for i in SHA256 SHA256.sig ; do \
$get ${dir}/${i} ${site}${i} > /dev/null 2>&1 ; done
for i in INSTALL.${arch} bsd.rd $bsd $sets ; do
test -f $i || $get ${dir}/${i} ${site}${i} > /dev/null 2>&1 ; \
first=$(awk '/\('"$i"'\)/ { print $NF ; }' SHA256) ; second=$(sha256 -q $i)
; test "$first" = "$second" || \
$get ${dir}/${i} ${site}${i} > /dev/null 2>&1 ; done
diff -q ${dir}/bsd.rd /bsd.rd > /dev/null 2>&1 || \
( mv -f /bsd.rd /obsd.rd && cp -f ${dir}/bsd.rd /bsd.rd && \
cd /usr/src/distrib/common && \
cc -o /tmp/rdsetroot elf32.c elf64.c elfrdsetroot.c && \
cd /tmp && /tmp/rdsetroot -x /bsd.rd ramdisk.img && \
vnconfig vnd0 ramdisk.img && mount /dev/vnd0a /mnt && \
echo 'Location of sets = disk
Is the disk partition already mounted = yes' > /mnt/auto_upgrade.conf && \
umount /dev/vnd0a && vnconfig -u vnd0 && \
/tmp/rdsetroot /bsd.rd ramdisk.img && rm ramdisk.img && \
echo 'boot bsd.rd' > /etc/boot.conf && \
echo '#!/bin/sh
rm -f /etc/boot.conf' > /upgrade.site && chmod 0755 /upgrade.site" && \
echo "There's a new snapshot." )
}
_snapshot
-
It's a bit crufty but it works for me :^)
Regards,
Raf
Re: Mouse setup question.
Here is some more information I can provide. When wsmoused(8) is not running and the mouse pointer starts moving to the lower left corner of the screen without any mouse being touched, I can stop it by executing: schu...@t60.schulte.it 2015-05-17T22:52:14+0200 Sunday 137 ~ $ xinput --disable 8 So disabling the "ws" driver makes the mouse pointer stop moving (by disabling the USB mouse, that is, after executing that command, only the synaptics touchpad is working afterwards). Reenabling the USB mouse by executing schu...@t60.schulte.it 2015-05-17T22:54:50+0200 Sunday 137 ~ $ xinput --enable 8 the mouse pointer immediately starts moving to the lower left corner of the screen. schu...@t60.schulte.it 2015-05-17T22:54:55+0200 Sunday 137 ~ $ xinput --list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ /dev/wsmouse0 id=7[slave pointer (2)] ⎜ ↳ /dev/wsmouse id=8[slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ /dev/wskbdid=6[slave keyboard (3)] Could someone please tell me how to make the "ws" driver produce any debugging information so that I can try to find a solution myself and maybe provide a patch? The issue started with 5.6 and 5.7 shows the same behaviour. It never happened using 5.5. Regards, -- Christian
Re: sftp script put help
On 16 May 2015 at 01:19, Craig Skinner wrote: > > I used to have a script create batch files in /tmp, > each with the full name of the incremental dump file to sftp. > > But I've found rdist. (OpenBSD uses ssh by default.) > > Look at rdist(1) EXAMPLES section, & > http://www.benedikt-stockebrand.de/rdist-intro_en.html Unfortunately, the sftp system I'll eventually be connecting to won't have rdist, but I'll definitely try to use rdist for future usage. Does it allow throttling? Thanks for teaching me about rdist! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: Updating SSH fingerprints for anoncvs.fr.openbsd.org
On 2015-05-17, Denis Fondras wrote: > Because I had to check them. For obvious reasons we need to get those from the mirror operators themselves and not from third parties. -- Christian "naddy" Weisgerber na...@mips.inka.de
Updating SSH fingerprints for anoncvs.fr.openbsd.org
Hi, Because I had to check them. Index: build/mirrors.dat === RCS file: /cvs/www/build/mirrors.dat,v retrieving revision 1.421 diff -u -p -r1.421 mirrors.dat --- build/mirrors.dat 13 May 2015 03:01:42 - 1.421 +++ build/mirrors.dat 17 May 2015 19:08:46 - @@ -326,9 +326,13 @@ AH anoncvs.fr.openbsd.org AU anoncvs AR /cvs AP ssh +SRaSHA256:d3o82eY/kIfUfmhVpwFu7Do1I7+Wol/tvWmm6Ye9HZ4 SR MD5:af:53:c8:ea:98:20:a2:81:e1:e3:c9:cb:06:d3:56:d7 +SD SHA256:8/EzaCXcEyuWAS2sOu5KNrozmDS2Xm60E4kd0lUwedg SD MD5:5e:3a:78:5f:ef:0a:53:b4:b9:2c:91:84:4f:3e:52:dd +SE SHA256:WXN4m8NHd4vcTqxmzLMMVenSh6gp8060nv39JIiCSss SE MD5:61:e1:2b:97:a4:65:4d:70:cd:23:3b:83:04:f1:2e:87 +S2 SHA256:STeC5WGChnZjIi5Rb+XTAQSbKXQJ+B9wxhaacYNff7k S2 MD5:10:80:7f:b7:76:03:7a:51:10:23:fb:1e:05:5b:93:74 0
Re: Strange shell in OpenBSD 5.7 #982
In next ISO build? CVSROOT:/cvs Module name:src Changes by: deraadt cvs.openbsd.org2015/05/17 10:55:51 Modified files: sys/sys: conf.h Log message: for decades, wsdisplay has acted in one way like it is not a tty On 5/17/15, dmitry.sensei wrote: > In the previous versions it was ok. > What "strong" report I can bring to you? :D > Example of my session: > login:root > password:** > OpenBSD 5.7-current > ls > Downloads > qwerty > ksh: [2]: qwerty: not found > > On 5/17/15, Theo de Raadt wrote: >>> When I logged in OpenBSD 5.7 #982 I don't see OS prompt and can't use >>> Tab, up and down arrow and etc. >>> >>> I have ksh in /etc/passwd >> >> Why don't you realize how weak your bug report is? >> >> > > > -- > Dmitry Orlov > -- Dmitry Orlov
Re: Strange shell in OpenBSD 5.7 #982
In the previous versions it was ok. What "strong" report I can bring to you? :D Example of my session: login:root password:** OpenBSD 5.7-current ls Downloads qwerty ksh: [2]: qwerty: not found On 5/17/15, Theo de Raadt wrote: >> When I logged in OpenBSD 5.7 #982 I don't see OS prompt and can't use >> Tab, up and down arrow and etc. >> >> I have ksh in /etc/passwd > > Why don't you realize how weak your bug report is? > > -- Dmitry Orlov
Re: Strange shell in OpenBSD 5.7 #982
> When I logged in OpenBSD 5.7 #982 I don't see OS prompt and can't use > Tab, up and down arrow and etc. > > I have ksh in /etc/passwd Why don't you realize how weak your bug report is?
Strange shell in OpenBSD 5.7 #982
Hi. When I logged in OpenBSD 5.7 #982 I don't see OS prompt and can't use Tab, up and down arrow and etc. I have ksh in /etc/passwd -- Dmitry Orlov
Re: Update OpenBSD Remotely
On May 17, 2015, at 10:08 AM, Peter Leber wrote: > > I want to build a test system based on OpenBSD 5.7 which updates > in an automated fashion. > The goal is to have a remotely located machine which runs OpenBSD 5.7 > and is constantly updated. While restarting the machine remotely via SSH > is perfectly fine to me, I do not want to access the machine locally in > order to interrupt the automatic reboot in order to trigger the manual > upgrading process. I'm fine with following -stable and -current alike. Peter, Have you looked into flashrd? http://nmedia.net/flashrd https://github.com/yellowman/flashrd/ See the section in the FAQ on how to upgrade a running system: http://www.nmedia.net/flashrd/flashrd-faq.html Itâs a matter of copying over three files and re-booting. Iâve done remote upgrades many times, but have not scripted the process. Hope this helps. âPaul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Update OpenBSD Remotely
On 17.05.2015 17:08, Peter Leber wrote: I want to build a test system based on OpenBSD 5.7 which updates in an automated fashion. The goal is to have a remotely located machine which runs OpenBSD 5.7 and is constantly updated. While restarting the machine remotely via SSH is perfectly fine to me, I do not want to access the machine locally in order to interrupt the automatic reboot in order to trigger the manual upgrading process. I'm fine with following -stable and -current alike. I recognize that there's m:tier's binary patching service (https://stable.mtier.org), but the packages are signed by m:tier rather than the OpenBSD project. While following m:tier's binary patches is a good compromise to me, it's not a perfect solution. I'm perfectly fine with running the -current flavour of OpenBSD feature- and stability-wise, but I did not have the success of remotely triggering a script, rebooting the machine and have an up and running updated machine. While I did find the autoinstall(8) feature, which, since 5.7, should be able to trigger an automatic upgrade if the file /auto_upgrade.conf is present, I did not see an effect in the bootup messages on the virtual machine I'm using for testing things out. Furthermore, I did find a tool named snap, aiming at making running -current more enjoyable (see https://github.com/qbit/snap), but it does also seem to be relying on the user to manually start the upgrading process on system reboot, if I got everything correctly. Is there someone aware of a procedure which could help me solving my problem? I thank you very much in advance. Peter Hi, autoinstall(8) is your friend: [ns]~/upgrade$ cat download #!/bin/sh rd=bsd.rd #URL=http://mirror.telepoint.bg/OpenBSD/snapshots/amd64/ #URL=http://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ URL=http://ftp5.eu.openbsd.org/ftp/pub/OpenBSD/snapshots/amd64/ #URL=http://ftp2.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/ wget -r -N -l1 -nd -R.gif,.html -Abs*,.tgz,index.txt,SHA*,INS* $URL sudo cp $rd /tmp # build rdsetroot ( cd /usr/src/distrib/common && cc -o /tmp/rdsetroot elf32.c elf64.c elfrdsetroot.c ) # extract ramdisk from bsd.rd /tmp/rdsetroot -x /tmp/bsd.rd /tmp/ramdisk.img # mount ramdisk sudo vnconfig vnd0 /tmp/ramdisk.img sudo mount /dev/vnd0a /mnt # copy config file sudo cp /auto_upgrade.conf /mnt/auto_upgrade.conf # umount ramdisk sudo umount /dev/vnd0a sudo vnconfig -u vnd0 # put modified ramdisk in bsd.rd sudo /tmp/rdsetroot /tmp/bsd.rd /tmp/ramdisk.img # backup /bsd to /obsd sudo mv /bsd /obsd # cleanup sudo rm /tmp/ramdisk.img sudo mv /tmp/bsd.rd /bsd #EOF [ns]~/upgrade$ cat /auto_upgrade.conf Which disk is the root disk = sd2 Root filesystem = sd2a Force checking of clean non-root filesystems = no Location of sets = disk Is the disk partition already mounted = yes Pathname to the sets = /mnt/home/vlado/upgrade #EOF Run download script, reboot and you are up-to-date!
Re: Update OpenBSD Remotely
On Sun, May 17, 2015 at 10:43:09AM -0400, trondd wrote: > On 2015-05-17 10:08, Peter Leber wrote: > >I do not want to access the machine locally in > >order to interrupt the automatic reboot in order to trigger the manual > >upgrading process. > > I'm not sure what you're talking about here... > > > >Is there someone aware of a procedure which could help me solving my > >problem? > > I have a dedicated system in a remote datacenter without console access. > I simply follow the FAQ to build from source and install that way. I > suppose the whole thing could be automated if you were that adventurous. > I prefer to keep an eye on what it's doing. As Peter asked about both the -stable and -current flavors of the OS, this should be clarified: FAQ 5.2 states: "If you are compiling -current from source, it is HIGHLY recommended that you only do so from a machine which you have full console access to. There will be times in the development process where the mismatch between your new kernel and your old userland may render the system inaccessible via network. This is not an issue when properly building -stable."
Re: Update OpenBSD Remotely
I think you can setup KVM for remote control ... On Sun, May 17, 2015 at 7:38 PM, Peter Leber wrote: > I want to build a test system based on OpenBSD 5.7 which updates > in an automated fashion. > The goal is to have a remotely located machine which runs OpenBSD 5.7 > and is constantly updated. While restarting the machine remotely via SSH > is perfectly fine to me, I do not want to access the machine locally in > order to interrupt the automatic reboot in order to trigger the manual > upgrading process. I'm fine with following -stable and -current alike. > > I recognize that there's m:tier's binary patching service > (https://stable.mtier.org), but the packages are signed > by m:tier rather than the OpenBSD project. While following m:tier's > binary patches is a good compromise to me, it's not a perfect solution. > I'm perfectly fine with running the -current flavour of OpenBSD feature- > and stability-wise, but I did not have the success of remotely triggering > a script, rebooting the machine and have an up and running updated > machine. > While I did find the autoinstall(8) feature, which, since 5.7, should be > able to trigger an automatic upgrade if the file /auto_upgrade.conf is > present, I did not see an effect in the bootup messages on the virtual > machine I'm using for testing things out. > Furthermore, I did find a tool named snap, aiming at making running > -current more enjoyable (see https://github.com/qbit/snap), but it does > also seem to be relying on the user to manually start the upgrading > process on system reboot, if I got everything correctly. > > Is there someone aware of a procedure which could help me solving my > problem? > I thank you very much in advance. > > Peter
Re: Update OpenBSD Remotely
On 2015-05-17 10:08, Peter Leber wrote: I do not want to access the machine locally in order to interrupt the automatic reboot in order to trigger the manual upgrading process. I'm not sure what you're talking about here... Is there someone aware of a procedure which could help me solving my problem? I have a dedicated system in a remote datacenter without console access. I simply follow the FAQ to build from source and install that way. I suppose the whole thing could be automated if you were that adventurous. I prefer to keep an eye on what it's doing. Tim.
Re: console prompt disappeared after login
> just not the TTY's same here. -- Maurits Fennis () ascii ribbon campaign /\ www.asciiribbon.org
Update OpenBSD Remotely
I want to build a test system based on OpenBSD 5.7 which updates in an automated fashion. The goal is to have a remotely located machine which runs OpenBSD 5.7 and is constantly updated. While restarting the machine remotely via SSH is perfectly fine to me, I do not want to access the machine locally in order to interrupt the automatic reboot in order to trigger the manual upgrading process. I'm fine with following -stable and -current alike. I recognize that there's m:tier's binary patching service (https://stable.mtier.org), but the packages are signed by m:tier rather than the OpenBSD project. While following m:tier's binary patches is a good compromise to me, it's not a perfect solution. I'm perfectly fine with running the -current flavour of OpenBSD feature- and stability-wise, but I did not have the success of remotely triggering a script, rebooting the machine and have an up and running updated machine. While I did find the autoinstall(8) feature, which, since 5.7, should be able to trigger an automatic upgrade if the file /auto_upgrade.conf is present, I did not see an effect in the bootup messages on the virtual machine I'm using for testing things out. Furthermore, I did find a tool named snap, aiming at making running -current more enjoyable (see https://github.com/qbit/snap), but it does also seem to be relying on the user to manually start the upgrading process on system reboot, if I got everything correctly. Is there someone aware of a procedure which could help me solving my problem? I thank you very much in advance. Peter
Re: console prompt disappeared after login
I'm experiencing the same issue. It works fine, however, after starting a xfce session inside terminator or xfce terminalâ - just not the TTY's. On Sun, May 17, 2015 at 2:19 PM, Maurits Fennis wrote: > > Yes but try typing commands its working as normal. > > This is what I meant with having access to the shell. > Good to know this isn't an isolated incident. > > -- > Maurits Fennis > > () ascii ribbon campaign > /\ www.asciiribbon.org
Re: console prompt disappeared after login
> Yes but try typing commands its working as normal. This is what I meant with having access to the shell. Good to know this isn't an isolated incident. -- Maurits Fennis () ascii ribbon campaign /\ www.asciiribbon.org
Re: console prompt disappeared after login
Yes but try typing commands its working as normal. .. On Sun, May 17, 2015 at 6:34 PM, Maurits Fennis wrote: > Hi guys, > > After upgrading to the May 17th snapshot of -current, I am only presented > with a cursor after logging in. I do have access to the shell. Does > anybody have the same problem? > > -- > Maurits Fennis > > () ascii ribbon campaign > /\ www.asciiribbon.org
Re: Robustness in ports fetch program?
2015-05-17 14:18 GMT+02:00 Alan Corey : > I don't think it did this back in 5.0 days or maybe earlier. I started > with OpenBSD 2.7, I just usually attributed problems to being my fault. > And I've always used the ports tree, not packages. Distfiles are often > useful across OpenBSD versions, sometimes in FreeBSD, I've even built some > under Linux. > > I didn't look at what FETCH_CMD was defined as by default, I just assumed > defining something non-null changed it. I did notice that when it retries > it's wrongly assumed there's a problem with the first source and gone to > another. > > Does every developer have perfect internet? That's very frustrating, maybe > counterproductive in testing. Try a modem, you can probably find a free > one. Connection interruptions and resets happen many times a day. > On May 17, 2015 1:22 AM, "Marc Espie" wrote: > >> On Sat, May 16, 2015 at 10:31:24PM -0400, Alan Corey wrote: >> > I'd seen this happen in 5.6 too, but I just caught an example of it in >> > 5.7. My connection leaves a lot to be desired, but there's nothing I >> > can do about that. I normally have FETCH_CMD set to use wget once I >> > get it installed but this was in doing a standard make install of a >> > port. >> > >> > The first time the connection gets interrupted, but something thinks >> > it should be done and checks the size. That's wrong so it downloads >> > it over again instead of just resuming the download. It should only >> > download it over again if the size matches but the CRC is wrong. >> > Seems like anyway. >> > >> > ===> Verifying install for tcl-8.5.16 in lang/tcl/8.5 >> > ===> Checking files for tcl-8.5.16p0 >> > >> Fetch >> > >> http://downloads.sourceforge.net/sourceforge/tcl/tcl8.5.16-src.tar.gz >> > tcl8.5.16-src.tar.gz 60% |*| 2696 KB >> 00:00 >> > >> Size does not match for tcl8.5.16-src.tar.gz >> > >> Fetch >> http://ftp.openbsd.org/pub/OpenBSD/distfiles//tcl8.5.16-src.tar.gz >> > tcl8.5.16-src.tar.gz 23% |** | 1024 KB >> 00:03 ETA >> >> The problem lies in ftp(1). >> >> Logic in the ports tree is fine. But there's nothing it can do there: >> somehow >> your ftp returns 0 (e.g., success), so the partial file gets removed. >> >> If you want to get it fixed, you may have to provide more input, as we >> obviously do not see that problem... First thing would be to override >> FETCH_CMD to remove the -V, so that you can show us what ftp says about >> things. Tracing the code thru the program would help.
console prompt disappeared after login
Hi guys, After upgrading to the May 17th snapshot of -current, I am only presented with a cursor after logging in. I do have access to the shell. Does anybody have the same problem? -- Maurits Fennis () ascii ribbon campaign /\ www.asciiribbon.org
Re: Robustness in ports fetch program?
I don't think it did this back in 5.0 days or maybe earlier. I started with OpenBSD 2.7, I just usually attributed problems to being my fault. And I've always used the ports tree, not packages. Distfiles are often useful across OpenBSD versions, sometimes in FreeBSD, I've even built some under Linux. I didn't look at what FETCH_CMD was defined as by default, I just assumed defining something non-null changed it. I did notice that when it retries it's wrongly assumed there's a problem with the first source and gone to another. Does every developer have perfect internet? That's very frustrating, maybe counterproductive in testing. Try a modem, you can probably find a free one. Connection interruptions and resets happen many times a day. On May 17, 2015 1:22 AM, "Marc Espie" wrote: > On Sat, May 16, 2015 at 10:31:24PM -0400, Alan Corey wrote: > > I'd seen this happen in 5.6 too, but I just caught an example of it in > > 5.7. My connection leaves a lot to be desired, but there's nothing I > > can do about that. I normally have FETCH_CMD set to use wget once I > > get it installed but this was in doing a standard make install of a > > port. > > > > The first time the connection gets interrupted, but something thinks > > it should be done and checks the size. That's wrong so it downloads > > it over again instead of just resuming the download. It should only > > download it over again if the size matches but the CRC is wrong. > > Seems like anyway. > > > > ===> Verifying install for tcl-8.5.16 in lang/tcl/8.5 > > ===> Checking files for tcl-8.5.16p0 > > >> Fetch > > >> http://downloads.sourceforge.net/sourceforge/tcl/tcl8.5.16-src.tar.gz > > tcl8.5.16-src.tar.gz 60% |*| 2696 KB > 00:00 > > >> Size does not match for tcl8.5.16-src.tar.gz > > >> Fetch > http://ftp.openbsd.org/pub/OpenBSD/distfiles//tcl8.5.16-src.tar.gz > > tcl8.5.16-src.tar.gz 23% |** | 1024 KB > 00:03 ETA > > The problem lies in ftp(1). > > Logic in the ports tree is fine. But there's nothing it can do there: > somehow > your ftp returns 0 (e.g., success), so the partial file gets removed. > > If you want to get it fixed, you may have to provide more input, as we > obviously do not see that problem... First thing would be to override > FETCH_CMD to remove the -V, so that you can show us what ftp says about > things. Tracing the code thru the program would help.
Re: swap on encrypted softraid, performance penalty?
On Sun, May 17, 2015 at 12:20:52AM +0200, Fredrik Alm wrote: > I’ve seen a few “whole disk encryption” tutorials which puts the swap outside > of the partition used for the softraid encryption, since openbsd already > encrypts the swap partition anyway. I assume that by putting the swap inside > the encrypted partition, there will be performance penalties because > encryption is done twice? could someone shed a little light on this issue? Keeping swap on the same disk as the root filesystem has some advantages. For historical reasons the system expects this in various places. More things (such as hibernate) will work out of the box this way. If you really need to avoid a performance hit on swap, I'd recommend you add more memory to the system. If that's impossible you can add an additional swap device from a non-softraid part of the disk and set it to higher priority than the default swap. See swapctl(8). The result could look something like this (sd2 being softraid crypto, sd0 being a swap partiion on bare disk): $ swapctl Device 512-blocks UsedAvail Capacity Priority /dev/sd0b 167831360 16783136 0%0 /dev/sd2b 167718630 16771863 0%1 Total 335549990 33554999 0% Also note that if your machine suports aesni (AES cpu feature flag in dmesg) softraid encryption overhead is reduced by hardware crypto.
Re: swap on encrypted softraid, performance penalty?
On Sun, 17 May 2015 04:32:38 +0200 Fredrik Alm wrote: > > On 17 May 2015, at 02:19, dan mclaughlin wrote: > > > > On Sun, 17 May 2015 00:20:52 +0200 Fredrik Alm wrote: > >> Iâve seen a few âwhole disk encryptionâ > >> tutorials which puts the swap outside of the partition used for the > >> softraid > >> encryption, since openbsd already encrypts the swap partition anyway. I > >> assume that by putting the swap inside the encrypted partition, there will > >> be performance penalties because encryption is done twice? could someone > >> shed a little light on this issue? > >> > > > > where did you see those tutorials? i attempted this some months ago (6-7) > > and > > it was not possible to have swap outside of the softraid. i forget what the > > exact problem was (i should have taken better notes...). i believe the > > system wouldn't boot properly, and i think it was because the swap partition > > was on a different device. > > > > in the end i found it easier to just leave it all in the softraid for other > > reasons in addition to that issue. as to swap encryption, i disabled it. no > > need to encrypt twice. > > this is one of the tutorials: http://www.bsdnow.tv/tutorials/fde > > I found that when the swap was on a different disk > (sd0b instead of sd1b, with the rest of the encrypted stuff on the softraid > disk) > the swap had to be added manually to the fstab and even then it was > defaulted to /dev/sdb1 (which didnât exist) for coredumps. I assume this is > why ZZZ exited with a kernel error instead of hibernating when I tried this > disklayout. When I just put everything including the swap on the softraid it > worked like normal. Iâll just try turning the swap encryption off then, > seems > easier than reconfiguring the kernel to use sd0b as a dump device. > your experience sounds familiar (swap expected to be on the root device), and is why i think i abandoned the attempt to put the swap outside the partition. though i am pretty sure i had problems right at boot, not later. honestly though, i don't know how the guy who wrote that tutorial got it to work (if in fact he did...), i remember it being completely unworkable. i think the only option was to rebuild the kernel, as you said, which really isn't an option. also, those instructions to use bioctl will only work if there has not been a softraid crypto volume there previously. you need to clear the space via dd as in bioctl(8).
Re: swap on encrypted softraid, performance penalty?
On Sun, 17 May 2015 00:20:52 +0200 Fredrik Alm wrote: > Iâve seen a few âwhole disk encryptionâ > tutorials which puts the swap outside of the partition used for the softraid > encryption, since openbsd already encrypts the swap partition anyway. I > assume that by putting the swap inside the encrypted partition, there will > be performance penalties because encryption is done twice? could someone > shed a little light on this issue? > where did you see those tutorials? i attempted this some months ago (6-7) and it was not possible to have swap outside of the softraid. i forget what the exact problem was (i should have taken better notes...). i believe the system wouldn't boot properly, and i think it was because the swap partition was on a different device. in the end i found it easier to just leave it all in the softraid for other reasons in addition to that issue. as to swap encryption, i disabled it. no need to encrypt twice.
