From nobody Fri May 19 17:29:37 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QNDPH5lf7z4C9l5 for ; Fri, 19 May 2023 17:29:55 +0000 (UTC) (envelope-from jbo@insane.engineer) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QNDPG0Yyqz4K2g for ; Fri, 19 May 2023 17:29:53 +0000 (UTC) (envelope-from jbo@insane.engineer) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=insane.engineer header.s=protonmail header.b=Wwcrtufx; spf=pass (mx1.freebsd.org: domain of jbo@insane.engineer designates 185.70.43.23 as permitted sender) smtp.mailfrom=jbo@insane.engineer; dmarc=pass (policy=none) header.from=insane.engineer Date: Fri, 19 May 2023 17:29:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insane.engineer; s=protonmail; t=1684517391; x=1684776591; bh=/uaSobq16rCuVOG2HoaFncvYHXAjuCoW2gfEOkl7p+Q=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=WwcrtufxqM/Nm4l6TZCIzuXzCgmYgIBRWtlRDrvzaKwCdhHNyJ/bpbUEAHndxnJf8 baAjkRQ7LTtkpmmCWmf2TmHpSTXWl8F3iH/oiNczFtcE/hnokjsNBGf54fvtC/MGHC MzhxQ7jCPjg5pDkJt2qf745/zC8NxekD3g6C0gx8yRgXjkDs+N2kX62EO8WOm0hxKT t8faYBSeWHEg8Y+uU0UKYMaSo1/EfpGcvNEwd2VXQox88yTzU/Mvi1SlQ6x2Mfnjir Z/83T6YpIHHFuc5NgBHsCBoy6K5nPqMfR1orgR9XmU7GqbZs1RiGBb8juk3nOt9QLT /YQReVarP964g== To: "hackers@freebsd.org" From: jbo@insane.engineer Subject: Retrieving CPU steal time Message-ID: Feedback-ID: 40997969:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_QOlrGWWZC0PqkaJ44adpjzKwuOkYKb7WOZJkJ4990ks" X-Spamd-Result: default: False [-2.36 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[insane.engineer,none]; NEURAL_HAM_SHORT(-0.46)[-0.458]; R_DKIM_ALLOW(-0.20)[insane.engineer:s=protonmail]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[insane.engineer:+]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_NO_DN(0.00)[]; HAS_PHPMAILER_SIG(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.43.23:from] X-Rspamd-Queue-Id: 4QNDPG0Yyqz4K2g X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_QOlrGWWZC0PqkaJ44adpjzKwuOkYKb7WOZJkJ4990ks Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TW9pbiwKCkkgdG9vayBpdCB1cG9uIG15c2VsZiB0byBpbXByb3ZlIEZyZWVCU0Qgc3VwcG9ydCBm b3IgeDExL3BvbHliYXIgKGEgc3RhdHVzIGJhciB0aGluZ3kpLgpPdXQtb2YtdGhlLWJveCwgZGlz cGxheWluZyB0aGUgQ1BVIGxvYWQgaXMgbm90IHN1cHBvcnRlZCBvbiBGcmVlQlNELgoKVXBzdHJl YW0gZGVmaW5lcyB0aGlzIHN0cnVjdHVyZSBmb3IgcmVjb3JkaW5nIENQVSBsb2FkOiBodHRwczov L2dpdGh1Yi5jb20vcG9seWJhci9wb2x5YmFyL2Jsb2IvbWFzdGVyL2luY2x1ZGUvbW9kdWxlcy9j cHUuaHBwI0wxMQoKSSd2ZSB0dXJuZWQgdG8gdGhlIGtlcm4uY3BfdGltZShzKSBzeXNjdGwgdG8g cmV0cmlldmUgdGhlIENQVSBsb2FkLiBUaGlzIHByb3ZpZGVzIG1lIHdpdGggdGhlIGZpZWxkcyBm b3IgdXNlciwgbmljZSwgc3lzdGVtIGFuZCBpZGxlLiBIb3dldmVyLCBJJ20gbm90IHN1cmUgd2hh dCB0byBkbyBhYm91dCB0aGUgJ3N0ZWFsJyB0aW1lIHdoaWNoIExpbnV4IHVzZXMgdG8gcmVwb3J0 IENQVSB0aW1lIHNwZW50IGluIHZpcnR1YWwgZW52aXJvbm1lbnRzLgpJcyB0aGVyZSBhbiBlcXVp dmFsZW50IG9uIEZyZWVCU0Q/CgpCZXN0IHJlZ2FyZHMsCn4gamJv --b1_QOlrGWWZC0PqkaJ44adpjzKwuOkYKb7WOZJkJ4990ks Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5Nb2luLDwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+SSB0b29rIGl0IHVwb24gbXlzZWxm IHRvIGltcHJvdmUgRnJlZUJTRCBzdXBwb3J0IGZvciB4MTEvcG9seWJhciAoYSBzdGF0dXMgYmFy IHRoaW5neSkuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij5PdXQtb2YtdGhlLWJveCwgZGlzcGxheWluZyB0aGUgQ1BVIGxv YWQgaXMgbm90IHN1cHBvcnRlZCBvbiBGcmVlQlNELjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ VXBzdHJlYW0gZGVmaW5lcyB0aGlzIHN0cnVjdHVyZSBmb3IgcmVjb3JkaW5nIENQVSBsb2FkOiA8 c3Bhbj48YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVy IiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcG9seWJhci9wb2x5YmFyL2Jsb2IvbWFzdGVyL2lu Y2x1ZGUvbW9kdWxlcy9jcHUuaHBwI0wxMSI+aHR0cHM6Ly9naXRodWIuY29tL3BvbHliYXIvcG9s eWJhci9ibG9iL21hc3Rlci9pbmNsdWRlL21vZHVsZXMvY3B1LmhwcCNMMTE8L2E+PC9zcGFuPjxi cj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkkndmUgdHVybmVkIHRvIHRoZSBrZXJuLmNwX3Rp bWUocykgc3lzY3RsIHRvIHJldHJpZXZlIHRoZSBDUFUgbG9hZC4gVGhpcyBwcm92aWRlcyBtZSB3 aXRoIHRoZSBmaWVsZHMgZm9yIHVzZXIsIG5pY2UsIHN5c3RlbSBhbmQgaWRsZS4gSG93ZXZlciwg SSdtIG5vdCBzdXJlIHdoYXQgdG8gZG8gYWJvdXQgdGhlICdzdGVhbCcgdGltZSB3aGljaCBMaW51 eCB1c2VzIHRvIHJlcG9ydCBDUFUgdGltZSBzcGVudCBpbiB2aXJ0dWFsIGVudmlyb25tZW50cy48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPklzIHRoZXJlIGFuIGVxdWl2YWxlbnQgb24gRnJlZUJTRD88L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxi cj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkJlc3QgcmVnYXJkcyw8L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPn4gamJv PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg0KPGRpdiBjbGFzcz0icHJv dG9ubWFpbF9zaWduYXR1cmVfYmxvY2sgcHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHki IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pg0KICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXVzZXIgcHJvdG9u bWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiPg0KICAgICAgICANCiAgICAgICAgICAgIDwvZGl2 Pg0KICAgIA0KICAgICAgICAgICAgPGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxv Y2stcHJvdG9uIHByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLWVtcHR5Ij4NCiAgICAgICAgDQog ICAgICAgICAgICA8L2Rpdj4NCjwvZGl2Pg0K --b1_QOlrGWWZC0PqkaJ44adpjzKwuOkYKb7WOZJkJ4990ks-- From nobody Tue May 23 03:44:53 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQKvg20NDz4CrjH for ; Tue, 23 May 2023 03:45:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQKvf0D25z3lpr for ; Tue, 23 May 2023 03:45:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 34N3irHt033089 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 22 May 2023 20:44:53 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 34N3ir0B033088 for freebsd-hackers@freebsd.org; Mon, 22 May 2023 20:44:53 -0700 (PDT) (envelope-from sgk) Date: Mon, 22 May 2023 20:44:53 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: gpart destroy efi partition? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [1.82 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_LONG(0.99)[0.990]; NEURAL_SPAM_MEDIUM(0.83)[0.830]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu] X-Rspamd-Queue-Id: 4QQKvf0D25z3lpr X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N Is there a secret incantation for destroying an EFI partition on a USB memstick? After installing FreeBSD, I would like to re-use a memstick, but % gpart destroy da0 gpart: geom 'da0': Read-only file system % gpart destroy -F da0 gpart: geom 'da0': Read-only file system % gpart show da0 => 40 60063664 da0 GPT (29G) 40 60063664 1 ms-basic-data (29G) % gpart delete -i 1 da0 gpart: geom 'da0': Read-only file system % dd if=/dev/zero of=/dev/da0 bs=1m dd: /dev/da0: Read-only file system -- Steve From nobody Tue May 23 03:51:40 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQL3Z2SGdz4Crtt for ; Tue, 23 May 2023 03:51:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQL3Z0Hbgz3mx1 for ; Tue, 23 May 2023 03:51:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-510b6a24946so688035a12.0 for ; Mon, 22 May 2023 20:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1684813912; x=1687405912; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tkhLayRrNzMBDygsKqm1w8TVKRmfkcSDG5W36mPwDQI=; b=imkFs6XpruAQK9CtM7SfTBfm1XNjdUBY4sydkwLWYeaKD16GjQzJXX2+VleYaiEVmw ScTUqB2vFTqRPrL5FVW1ivUnMWDwutNuQKjfbHElsgV/wvPdDXHlZ12jqirgcbmj+d6H mnjkgR/PmyuwQNJ68YlhvmdF7H9rPgRXY6u1oOMK6gDr1F+ALMglyKezDenV5VUCKvAf qWx+eqsI5c/SVbKwLTxfoRBrlJZmmvCAdlgBeajAVJTaWoyiKferxbWBuf+ymaZocRJj G+SUb+NP34fjrwnfNTk1fJKV0nQRRmUQ7edun980e54mvXvvqW1aYSR6IcnAFvknEpwd orrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684813912; x=1687405912; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tkhLayRrNzMBDygsKqm1w8TVKRmfkcSDG5W36mPwDQI=; b=iUusUWXdvOhypzeFMw/0ZxOpvBAvT9SOA3U+8dbRvs2k6NcOj1DNMAHcE+Lkkzgj+J BNNc8YlDM1D62D4iqkD2vFDyUEjcCpc8C7Ap6YX27Qg0Yioi2t12UyAdSJGpPkXNCYgc Xwqf1GhxIbnEzv+tQbpSwE9pdXbI2cXsk+RX8b8Hvu3xxKhM4vCilc1r6aC3VTBelwPh XZNbNqmiMZldYtqHgK0lYgGbGr/IdV3UsIcC0i07rfzfSm0kLEkv36YJHIO/CrQo0C2u 8tL97M5W8xH3kK2RLjijgDGdeaJWVMdCIgvc39i3qU1p/JbAkCCKhiaCipM3FQopuUz0 eOQQ== X-Gm-Message-State: AC+VfDzVHjMfi1H9uZlOUgzyCgeHxy6LHuUVS32KaXeRpIq1KhxHJGUo FR+jhJCLbYXR0A+ZLceszrFPQ3YdH2vwB7plRXILcns6857mXnT6 X-Google-Smtp-Source: ACHHUZ5q2mKq48f4aGftHTsaj2cVOXvw2KHLQMzYzeezp4w757YLpJGuAh51qtTOEZGXGr4CC6zlXgd6Rla01JVGMkQ= X-Received: by 2002:a17:907:98e:b0:960:ddba:e5c3 with SMTP id bf14-20020a170907098e00b00960ddbae5c3mr12251487ejc.32.1684813911932; Mon, 22 May 2023 20:51:51 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 22 May 2023 21:51:40 -0600 Message-ID: Subject: Re: gpart destroy efi partition? To: Steve Kargl Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000bbd09605fc544e7a" X-Rspamd-Queue-Id: 4QQL3Z0Hbgz3mx1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000bbd09605fc544e7a Content-Type: text/plain; charset="UTF-8" On Mon, May 22, 2023, 9:45 PM Steve Kargl wrote: > Is there a secret incantation for destroying an EFI > partition on a USB memstick? After installing FreeBSD, > I would like to re-use a memstick, but > > % gpart destroy da0 > gpart: geom 'da0': Read-only file system > % gpart destroy -F da0 > gpart: geom 'da0': Read-only file system > % gpart show da0 > => 40 60063664 da0 GPT (29G) > 40 60063664 1 ms-basic-data (29G) > % gpart delete -i 1 da0 > gpart: geom 'da0': Read-only file system > % dd if=/dev/zero of=/dev/da0 bs=1m > dd: /dev/da0: Read-only file system > What's mounted? Warner -- > Steve > > --000000000000bbd09605fc544e7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 22, 2023, 9:45 PM Steve Kargl <sgk@troutmask.apl.washington.e= du> wrote:
Is there a secret= incantation for destroying an EFI
partition on a USB memstick?=C2=A0 After installing FreeBSD,
I would like to re-use a memstick, but

% gpart destroy da0
gpart: geom 'da0': Read-only file system
% gpart destroy -F da0
gpart: geom 'da0': Read-only file system
% gpart show da0
=3D>=C2=A0 =C2=A0 =C2=A0 40=C2=A0 60063664=C2=A0 da0=C2=A0 GPT=C2=A0 (29= G)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 40=C2=A0 60063664=C2=A0 =C2=A0 1=C2=A0 ms-basic= -data=C2=A0 (29G)
% gpart delete -i 1 da0
gpart: geom 'da0': Read-only file system
% dd if=3D/dev/zero of=3D/dev/da0 bs=3D1m
dd: /dev/da0: Read-only file system

What's mounted?

Warner=C2=A0

--
Steve

--000000000000bbd09605fc544e7a-- From nobody Tue May 23 04:35:13 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQM1d2g0Dz4T0Mw for ; Tue, 23 May 2023 04:35:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQM1d1Q5wz3qK8 for ; Tue, 23 May 2023 04:35:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 34N4ZEoF033272 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 22 May 2023 21:35:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 34N4ZDIR033271; Mon, 22 May 2023 21:35:13 -0700 (PDT) (envelope-from sgk) Date: Mon, 22 May 2023 21:35:13 -0700 From: Steve Kargl To: Warner Losh Cc: FreeBSD Hackers Subject: Re: gpart destroy efi partition? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4QQM1d1Q5wz3qK8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, May 22, 2023 at 09:51:40PM -0600, Warner Losh wrote: > On Mon, May 22, 2023, 9:45 PM Steve Kargl > wrote: > > > Is there a secret incantation for destroying an EFI > > partition on a USB memstick? After installing FreeBSD, > > I would like to re-use a memstick, but > > > > % gpart destroy da0 > > gpart: geom 'da0': Read-only file system > > % gpart destroy -F da0 > > gpart: geom 'da0': Read-only file system > > % gpart show da0 > > => 40 60063664 da0 GPT (29G) > > 40 60063664 1 ms-basic-data (29G) > > % gpart delete -i 1 da0 > > gpart: geom 'da0': Read-only file system > > % dd if=/dev/zero of=/dev/da0 bs=1m > > dd: /dev/da0: Read-only file system > > > > What's mounted? > Nothing mounted other than the boot partition on an internal hard drive. I plugged the memstick into a usb port, and use gpart to list disk info. % df Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ada0p2 458231 62032 359539 15% / devfs 0 0 0 0% /dev ada0p1 is the EFI boot partition on the internal drive. ada0p3 is swap. % gpart list da0 Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 60063703 first: 40 entries: 128 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 30752595968 (29G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r0w0e0 efimedia: HD(1,GPT,a2e07858-a4b6-11ec-ac6a-fcaa142bc587,0x28,0x3947fb0) rawuuid: a2e07858-a4b6-11ec-ac6a-fcaa142bc587 rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 label: (null) length: 30752595968 offset: 20480 type: ms-basic-data index: 1 end: 60063703 start: 40 Consumers: 1. Name: da0 Mediasize: 30752636928 (29G) Sectorsize: 512 Mode: r0w0e0 I did find % sysctl -a | grep da01 kern.geom.disk.da0.flags: 1a8 So, I suppose the question is how to clear WRITEPROTECT. -- Steve From nobody Tue May 23 10:43:52 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQWC92Nlgz4CK0X for ; Tue, 23 May 2023 10:44:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQWC91f6Pz3MKZ for ; Tue, 23 May 2023 10:44:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-9707313e32eso178172566b.2 for ; Tue, 23 May 2023 03:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1684838644; x=1687430644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R03MZ0gA7HzhkWoXbWAoK1OPmv5iOLrtobBAm0hIaos=; b=xUmOyeDruqfeq6bhyqdLt9f8CeoQkulPoXDP+Ymwq/LM4SbT0h/7OppBPoYDWaw7Ki rC1c6vQXoiA+07XJ1Qx/ZxSG84GHfsQwtylizEExvHoDC51vkuHFM6hwrCSvYq1hp5ze h0PVou3t5pS8ShZtq3bxKtw4MgPhulMGWZxILcSbUDjR2srnnB+VRrNgnRAKJzkCi1aG qe/ft7jzESWEirrfo67CYr9HanpuS+lGvYg/g5SmqRM0qgDxf6lyTWMDfG5LF85GJNt3 04Sg97GSD2SCoeAhjxDVVKM5Y+vzBCLncz890JAHHHjQnX6eSc7A/jtFI1D0AnPICU2W 3c9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684838644; x=1687430644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R03MZ0gA7HzhkWoXbWAoK1OPmv5iOLrtobBAm0hIaos=; b=a+9JprEHshWz/UHA1UZHFC7M/EF/27A3+C286J1Vvv/BaZRdGD5yyYmL1k0yOB5NBD J+tMr1GLlyu18z0JMvZqfSRe0Ff8u5sndp37k6QrpQgqsquTDwQTq5wBK/lrgzBh147v i8eIVWP1Y7ww8TYS7aPHWanNgmZXXohaDxCVIt7qtaoru1fh5kqkCsrSG1N728j+dc3C RIZfSyAAzDzMPiMRqEI36WMbMeDRT/J9nLpjuM1yHvWp9aW0z9mYDy4rDHiUeaxTQnvW EhGQmQCZAkPlKkOm8Dh5vqkXPAZMkGG+zvp8/P94dmLWx/WdUtbhegitiVrxJ4lewjaF wPOw== X-Gm-Message-State: AC+VfDwcrZ8Yg50wFoPZaKsIZrMSYTOBiKDd/7nSMQMAOO5h59WdXdaA d/0GfTFF4M4IDRkKszb08jhgKz4AhFciAJ+meP37lJXehefp4sRj X-Google-Smtp-Source: ACHHUZ6IAdwvIomdF0JJ/4m4AhVnmWepgLQSha+WZueg3LzHG+PBmLcsJ+HnifecHxNWkJAE44NLbf5XmR+Yf26WSnA= X-Received: by 2002:a17:907:1c1e:b0:96f:e080:4f56 with SMTP id nc30-20020a1709071c1e00b0096fe0804f56mr6607908ejc.31.1684838643757; Tue, 23 May 2023 03:44:03 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 23 May 2023 04:43:52 -0600 Message-ID: Subject: Re: gpart destroy efi partition? To: Steve Kargl Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000dd841805fc5a1027" X-Rspamd-Queue-Id: 4QQWC91f6Pz3MKZ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000dd841805fc5a1027 Content-Type: text/plain; charset="UTF-8" On Mon, May 22, 2023, 10:35 PM Steve Kargl wrote: > On Mon, May 22, 2023 at 09:51:40PM -0600, Warner Losh wrote: > > On Mon, May 22, 2023, 9:45 PM Steve Kargl < > sgk@troutmask.apl.washington.edu> > > wrote: > > > > > Is there a secret incantation for destroying an EFI > > > partition on a USB memstick? After installing FreeBSD, > > > I would like to re-use a memstick, but > > > > > > % gpart destroy da0 > > > gpart: geom 'da0': Read-only file system > > > % gpart destroy -F da0 > > > gpart: geom 'da0': Read-only file system > > > % gpart show da0 > > > => 40 60063664 da0 GPT (29G) > > > 40 60063664 1 ms-basic-data (29G) > > > % gpart delete -i 1 da0 > > > gpart: geom 'da0': Read-only file system > > > % dd if=/dev/zero of=/dev/da0 bs=1m > > > dd: /dev/da0: Read-only file system > > > > > > > What's mounted? > > > > Nothing mounted other than the boot partition on > an internal hard drive. I plugged the memstick into > a usb port, and use gpart to list disk info. > > % df > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ada0p2 458231 62032 359539 15% / > devfs 0 0 0 0% /dev > > ada0p1 is the EFI boot partition on the internal drive. > ada0p3 is swap. > > % gpart list da0 > Geom name: da0 > modified: false > state: OK > fwheads: 255 > fwsectors: 63 > last: 60063703 > first: 40 > entries: 128 > scheme: GPT > Providers: > 1. Name: da0p1 > Mediasize: 30752595968 (29G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 20480 > Mode: r0w0e0 > efimedia: HD(1,GPT,a2e07858-a4b6-11ec-ac6a-fcaa142bc587,0x28,0x3947fb0) > rawuuid: a2e07858-a4b6-11ec-ac6a-fcaa142bc587 > rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > label: (null) > length: 30752595968 > offset: 20480 > type: ms-basic-data > index: 1 > end: 60063703 > start: 40 > Consumers: > 1. Name: da0 > Mediasize: 30752636928 (29G) > Sectorsize: 512 > Mode: r0w0e0 > > I did find > > % sysctl -a | grep da01 > kern.geom.disk.da0.flags: > 1a8 > > So, I suppose the question is how to clear WRITEPROTECT. > Assuming you are running as root... WRITEPROTECT gets set when we do a MODE SENSE of the disk when we're probing it. That returns a status that indicates that the device is indicating it is write protected. So we set the write_protect flags in the disk structure which is what's reported above and used to generate the read only errors. if you are lucky, this is a software write protect. That's on mode page 0xa. camcontrol can read that: # camcontrol modepage da0 -m 0xa will report it. if SWP is 1, then it's a software lock. Add -e to the above to edit it and change the line with SWP on it from 1->0 and save. this will set the current value, turning it off temporarily. You can then proceed to write to the device, with luck. Without luck the drive encountered a condition that made it decide to lock you out forever from writing again. Warner --000000000000dd841805fc5a1027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 22, 2023, 10:35 PM Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
=
On Mon, May 22, 2023 at 09:51:40PM -0600, Wa= rner Losh wrote:
> On Mon, May 22, 2023, 9:45 PM Steve Kargl <sgk@troutmask.apl.washington.edu>
> wrote:
>
> > Is there a secret incantation for destroying an EFI
> > partition on a USB memstick?=C2=A0 After installing FreeBSD,
> > I would like to re-use a memstick, but
> >
> > % gpart destroy da0
> > gpart: geom 'da0': Read-only file system
> > % gpart destroy -F da0
> > gpart: geom 'da0': Read-only file system
> > % gpart show da0
> > =3D>=C2=A0 =C2=A0 =C2=A0 40=C2=A0 60063664=C2=A0 da0=C2=A0 GPT= =C2=A0 (29G)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A040=C2=A0 60063664=C2=A0 =C2=A0 1= =C2=A0 ms-basic-data=C2=A0 (29G)
> > % gpart delete -i 1 da0
> > gpart: geom 'da0': Read-only file system
> > % dd if=3D/dev/zero of=3D/dev/da0 bs=3D1m
> > dd: /dev/da0: Read-only file system
> >
>
> What's mounted?
>

Nothing mounted other than the boot partition on
an internal hard drive.=C2=A0 I plugged the memstick into
a usb port, and use gpart to list disk info.

% df
Filesystem=C2=A0 1M-blocks=C2=A0 Used=C2=A0 Avail Capacity=C2=A0 Mounted on=
/dev/ada0p2=C2=A0 =C2=A0 458231 62032 359539=C2=A0 =C2=A0 15%=C2=A0 =C2=A0 = /
devfs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 = =C2=A00=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A00%=C2=A0 =C2=A0 /dev

ada0p1 is the EFI boot partition on the internal drive.
ada0p3 is swap.

% gpart list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 60063703
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
=C2=A0 =C2=A0Mediasize: 30752595968 (29G)
=C2=A0 =C2=A0Sectorsize: 512
=C2=A0 =C2=A0Stripesize: 0
=C2=A0 =C2=A0Stripeoffset: 20480
=C2=A0 =C2=A0Mode: r0w0e0
=C2=A0 =C2=A0efimedia: HD(1,GPT,a2e07858-a4b6-11ec-ac6a-fcaa142bc587,0x28,0= x3947fb0)
=C2=A0 =C2=A0rawuuid: a2e07858-a4b6-11ec-ac6a-fcaa142bc587
=C2=A0 =C2=A0rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
=C2=A0 =C2=A0label: (null)
=C2=A0 =C2=A0length: 30752595968
=C2=A0 =C2=A0offset: 20480
=C2=A0 =C2=A0type: ms-basic-data
=C2=A0 =C2=A0index: 1
=C2=A0 =C2=A0end: 60063703
=C2=A0 =C2=A0start: 40
Consumers:
1. Name: da0
=C2=A0 =C2=A0Mediasize: 30752636928 (29G)
=C2=A0 =C2=A0Sectorsize: 512
=C2=A0 =C2=A0Mode: r0w0e0

I did find

% sysctl -a | grep da01
kern.geom.disk.da0.flags: 1a8<CANFLUSHCACHE,DIRECTCOMPLETION,CANZONE,WRI= TEPROTECT>

So, I suppose the question is how to clear WRITEPROTECT.

Assuming you are ru= nning as root...=C2=A0=C2=A0

WRITEPROTECT gets set when we do a MODE SENSE of the disk when we'= re probing it. That returns a status that indicates that the device is indi= cating it is write protected. So we set the write_protect flags in the disk= structure which is what's reported above and used to generate the read= only errors.

if you are= lucky, this is a software write protect. That's on mode page 0xa. camc= ontrol can read that:
# camcontrol modepage da0 -m 0= xa
will report it. if SWP is 1, then it's a soft= ware lock. Add -e to the=C2=A0 above to edit it and change the line with=C2= =A0 SWP on it from=C2=A0 1->0 and save. this will set the current value,= turning it off temporarily. You can then proceed to write to the device, w= ith luck.

Without=C2=A0 = luck the drive encountered a condition that made it decide to lock you out = forever from=C2=A0 writing again.

Warner


--000000000000dd841805fc5a1027-- From nobody Tue May 23 10:55:21 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQWSX6hkLz4CL1H for ; Tue, 23 May 2023 10:55:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQWSW5rQXz3N3c for ; Tue, 23 May 2023 10:55:39 +0000 (UTC) (envelope-from jhs@berklix.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com; dmarc=none Received: from dell.no.berklix.net (p4fe6de81.dip0.t-ipconnect.de [79.230.222.129]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 34NAtRNb050533 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Tue, 23 May 2023 10:55:28 GMT (envelope-from jhs@berklix.com) Received: from dell.no.berklix.net (localhost [127.0.0.1]) by dell.no.berklix.net (8.16.1/8.16.1) with ESMTPS id 34NAtMKf047128 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 23 May 2023 12:55:22 +0200 (CEST) (envelope-from jhs@dell.no.berklix.net) Received: (from jhs@localhost) by dell.no.berklix.net (8.16.1/8.16.1/Submit) id 34NAtLsE047127; Tue, 23 May 2023 12:55:21 +0200 (CEST) (envelope-from jhs) Message-Id: <202305231055.34NAtLsE047127@dell.no.berklix.net> To: sgk@troutmask.apl.washington.edu cc: Warner Losh , FreeBSD Hackers Subject: Re: gpart destroy efi partition? From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Mon, 22 May 2023 21:35:13 -0700." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <47125.1684839321.1@dell.no.berklix.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2023 12:55:21 +0200 X-Spamd-Result: default: False [-1.10 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; BLOCKLISTDE_FAIL(0.00)[144.76.10.75:server fail,79.230.222.129:server fail]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jhs]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[berklix.com]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[] X-Rspamd-Queue-Id: 4QQWSW5rQXz3N3c X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Steve Kargl wrote: > On Mon, May 22, 2023 at 09:51:40PM -0600, Warner Losh wrote: > > On Mon, May 22, 2023, 9:45 PM Steve Kargl > > wrote: > > = > > > Is there a secret incantation for destroying an EFI > > > partition on a USB memstick? After installing FreeBSD, > > > I would like to re-use a memstick, but > > > > > > % gpart destroy da0 > > > gpart: geom 'da0': Read-only file system > > > % gpart destroy -F da0 > > > gpart: geom 'da0': Read-only file system > > > % gpart show da0 > > > =3D> 40 60063664 da0 GPT (29G) > > > 40 60063664 1 ms-basic-data (29G) > > > % gpart delete -i 1 da0 > > > gpart: geom 'da0': Read-only file system > > > % dd if=3D/dev/zero of=3D/dev/da0 bs=3D1m > > > dd: /dev/da0: Read-only file system > > > > > = > > What's mounted? > > = > > Nothing mounted other than the boot partition on > an internal hard drive. I plugged the memstick into > a usb port, and use gpart to list disk info. > > % df > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ada0p2 458231 62032 359539 15% / > devfs 0 0 0 0% /dev > > ada0p1 is the EFI boot partition on the internal drive. > ada0p3 is swap. > > % gpart list da0 > Geom name: da0 > modified: false > state: OK > fwheads: 255 > fwsectors: 63 > last: 60063703 > first: 40 > entries: 128 > scheme: GPT > Providers: > 1. Name: da0p1 > Mediasize: 30752595968 (29G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 20480 > Mode: r0w0e0 > efimedia: HD(1,GPT,a2e07858-a4b6-11ec-ac6a-fcaa142bc587,0x28,0x3947fb= 0) > rawuuid: a2e07858-a4b6-11ec-ac6a-fcaa142bc587 > rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > label: (null) > length: 30752595968 > offset: 20480 > type: ms-basic-data > index: 1 > end: 60063703 > start: 40 > Consumers: > 1. Name: da0 > Mediasize: 30752636928 (29G) > Sectorsize: 512 > Mode: r0w0e0 > > I did find = > > % sysctl -a | grep da01 > kern.geom.disk.da0.flags: 1a8 > > So, I suppose the question is how to clear WRITEPROTECT. I dont use efi & gpart but some ideas: Why da01 not da0 ? What is da01 ? a typo, or pulling in some gpart kernel stuff ? Is an escalated security level catching you ? I stick to default, on 12.4-rel multi user thats: sysctl -a | grep level # kern.securelevel: -= 1 Try a fresh reboot, even staying single user, & before you touch it with any gpart invoking command, whack it with multiple dd if=3D/dev/zero of=3D/dev/zero count=3D5000 (multiple as sometimes Ive seen first attempt doesnt seem to clear my sticks, a 2nd reboot after dd will clear any false cached memories) If that doesnt work: Try an older BSD that does know about EFI & gpart ? Put it a Microsoft PC, or a USB to Go adapter on an android, that probbly will complain unknown & offer to bash it back to MBR ? Rumage around or ask friends, eg I have a tiny old match box size thing that clones sticks. Clone your stick from some other small stick, then repair the wrong sized MBR Cheers, -- = Julian Stacey www.StolenVotes.UK/jhs/ Arm Ukraine, Zap Putin. Brexit infl= ates http://berklix.org/ferries/#dover_solution From nobody Tue May 23 14:33:21 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQcJD4dYNz4CXLY for ; Tue, 23 May 2023 14:33:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQcJC0QmQz45sc for ; Tue, 23 May 2023 14:33:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=At454oDw; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il; dmarc=pass (policy=none) header.from=huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=mfJtorhzmoLJ46DlxSjpX57YKDgI2ScKmjYIOwDV2+M=; b=At454oDwEau5d4coqcZ791zz2QgtiSYEYPwktTJD4FPwb75ffQ+jhRdrLC5o/QYE7usZjgJdKBHoWGac3TlzBa+dd6F5gahn+plCX+W0FE2znhjgz0Q++J5Bo23H7L/rb1Cry6iCnJtrb/qbTMKljcyD5HkGItUMIqh7rncMyZ0wNh2HMEMalkRxKn/VYCCvrJ+P8qQAFBDwnA+q4xQM47GsrrGpbWC6xT57Z3R5KgkTsEMEMlHxDaKaFcg6hmdvnWKpYQiUciUN3+M8Ev1e4gO8v1VM8OeP+9vkhSdSDYLBtxWD3IV3w7rS87KuZiKvrubEtmvx6XSR5RFdPXJzkg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1q1T53-000DJV-Ne for hackers@freebsd.org; Tue, 23 May 2023 17:33:41 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: xdm and listen=tcp Message-Id: <255BDA89-2DD1-4805-95F1-5C01453A3E47@cs.huji.ac.il> Date: Tue, 23 May 2023 17:33:21 +0300 To: freebsd-hackers X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QQcJC0QmQz45sc X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N hi, the short version: i start the X11 via the following line in /etc/ttys: ttyv8 =E2=80=9C/usr/local/bin/xdm -nodaemon=E2=80=9D = xterm on secure this worked great since forever, but now(*) the default of Xorg is not = to accept tcp connection, is there a simple way to fix this, apart of recompiling Xorg and somehow = changing the default behavior? *: now probably is a few years, since i have not uograded my WS for a = while - why change if it=E2=80=99s working, but mow it just went belly up :-( thanks, danny From nobody Tue May 23 15:03:41 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQcys4Lwnz4CZQB for ; Tue, 23 May 2023 15:03:49 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQcyr5XdSz49fx for ; Tue, 23 May 2023 15:03:48 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=Jazbgeqd; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="j eEvBcO"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.21 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A29FA3200645 for ; Tue, 23 May 2023 11:03:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 23 May 2023 11:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1684854224; x=1684940624; bh=5tnpwCo0IYlBqxXkT4EXPpaoLrxuEaFdenq H3FLqhE4=; b=JazbgeqdVbCiYVkji7LsCzA7Hdy6yM8QpOpuR6b5gDyfH5VZxq7 378PdtM6c8kcRD7toG7TjcaAuRknj0pxdNzvPxTCWGEYq5CdZUPXrQqQFShaRYxK 2093UbBWN+K7UGYKDafgqMoSf/U9RSKthSv6xSSw5JSzkI4YiGrtSc4WONGWvdxA CyY3sUNtimnsDJpRkywFg9zLbCD0q1cg1dKB3pVz/GVLovwe+1eO+UG4Ag2e80K8 C6uKAP3cyPj/zWP7y6508kyh+OBedfpvlrlPxWNH8aXfSdylEOvuQsITBctZoFxq RfHqjCBx6o1z7wWK5tHXTwrUdV73Z7SPgiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1684854224; x= 1684940624; bh=5tnpwCo0IYlBqxXkT4EXPpaoLrxuEaFdenqH3FLqhE4=; b=j eEvBcObThd3Q8/kgF5ERSz3TQxxR79cnriq3oSLvLe0bVP65unYEw2GJ3tzcRFAJ OuMU1WHiwSVhOA4LsT35hxWN+qApz/Hxg4QeYbBhzI6VJYHSdmyR6CwcjukVer4O jIMXT1JUTjENEDyLY6pQz7EqHYYWEFIUtZv34nWM4OtXxoA5jStpEPHNlP+WL0cl suHuLpBxFcrbzk2ERvUYrXtiCCY3vW5A2cMvz9++jxkc71SFMvuNQZdFIxHdKsxV nDHHhcgh5k1z4CzYYga3Ls8UqOfaTuXCPnAfJTjGtjSObo/vE9vlUgAeV3+/15/1 9WYcG1at2U07ld6XQ3DPQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeejfedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtke ertddtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeen ucggtffrrghtthgvrhhnpeehtdekheefleeuhefgueetgeevueektddutdegfffhueeute elgeeiteevjeeuveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpeihuhhrihesrggvthgvrhhnrdhorhhg X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 23 May 2023 11:03:43 -0400 (EDT) Message-ID: Date: Tue, 23 May 2023 17:03:41 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: xdm and listen=tcp Content-Language: en-US To: hackers@freebsd.org References: <255BDA89-2DD1-4805-95F1-5C01453A3E47@cs.huji.ac.il> From: Yuri In-Reply-To: <255BDA89-2DD1-4805-95F1-5C01453A3E47@cs.huji.ac.il> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QQcyr5XdSz49fx X-Spamd-Bar: / X-Spamd-Result: default: False [-0.40 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm1]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; local_wl_from(0.00)[yuri@aetern.org] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-ThisMailContainsUnwantedMimeParts: N Daniel Braniss wrote: > hi, > the short version: > i start the X11 via the following line in /etc/ttys: > ttyv8 “/usr/local/bin/xdm -nodaemon” xterm on secure > > this worked great since forever, but now(*) the default of Xorg is not to accept tcp connection, > is there a simple way to fix this, apart of recompiling Xorg and somehow changing the default behavior? > > *: now probably is a few years, since i have not uograded my WS for a while - why change if it’s working, > but mow it just went belly up :-( You probably want /usr/local/etc/X11/xdm/Xservers. From nobody Tue May 23 15:19:24 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQdJw1ckkz4CbSj for ; Tue, 23 May 2023 15:19:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQdJv60gNz4Dc6 for ; Tue, 23 May 2023 15:19:27 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 34NFJODg036798 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 23 May 2023 08:19:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 34NFJOJw036797; Tue, 23 May 2023 08:19:24 -0700 (PDT) (envelope-from sgk) Date: Tue, 23 May 2023 08:19:24 -0700 From: Steve Kargl To: Warner Losh Cc: FreeBSD Hackers Subject: Re: gpart destroy efi partition? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4QQdJv60gNz4Dc6 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, May 23, 2023 at 04:43:52AM -0600, Warner Losh wrote: > On Mon, May 22, 2023, 10:35 PM Steve Kargl > wrote: > > > On Mon, May 22, 2023 at 09:51:40PM -0600, Warner Losh wrote: > > > On Mon, May 22, 2023, 9:45 PM Steve Kargl < > > sgk@troutmask.apl.washington.edu> > > > wrote: > > > > > > > Is there a secret incantation for destroying an EFI > > > > partition on a USB memstick? After installing FreeBSD, > > > > I would like to re-use a memstick, but > > > > > > > > % gpart destroy da0 > > > > gpart: geom 'da0': Read-only file system > > > > % gpart destroy -F da0 > > > > gpart: geom 'da0': Read-only file system > > > > % gpart show da0 > > > > => 40 60063664 da0 GPT (29G) > > > > 40 60063664 1 ms-basic-data (29G) > > > > % gpart delete -i 1 da0 > > > > gpart: geom 'da0': Read-only file system > > > > % dd if=/dev/zero of=/dev/da0 bs=1m > > > > dd: /dev/da0: Read-only file system > > > > > > > > > > What's mounted? > > > > > > > Nothing mounted other than the boot partition on > > an internal hard drive. I plugged the memstick into > > a usb port, and use gpart to list disk info. > > > > % df > > Filesystem 1M-blocks Used Avail Capacity Mounted on > > /dev/ada0p2 458231 62032 359539 15% / > > devfs 0 0 0 0% /dev > > > > ada0p1 is the EFI boot partition on the internal drive. > > ada0p3 is swap. > > > > % gpart list da0 > > Geom name: da0 > > modified: false > > state: OK > > fwheads: 255 > > fwsectors: 63 > > last: 60063703 > > first: 40 > > entries: 128 > > scheme: GPT > > Providers: > > 1. Name: da0p1 > > Mediasize: 30752595968 (29G) > > Sectorsize: 512 > > Stripesize: 0 > > Stripeoffset: 20480 > > Mode: r0w0e0 > > efimedia: HD(1,GPT,a2e07858-a4b6-11ec-ac6a-fcaa142bc587,0x28,0x3947fb0) > > rawuuid: a2e07858-a4b6-11ec-ac6a-fcaa142bc587 > > rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > label: (null) > > length: 30752595968 > > offset: 20480 > > type: ms-basic-data > > index: 1 > > end: 60063703 > > start: 40 > > Consumers: > > 1. Name: da0 > > Mediasize: 30752636928 (29G) > > Sectorsize: 512 > > Mode: r0w0e0 > > > > I did find > > > > % sysctl -a | grep da01 > > kern.geom.disk.da0.flags: > > 1a8 > > > > So, I suppose the question is how to clear WRITEPROTECT. > > > > Assuming you are running as root... > > WRITEPROTECT gets set when we do a MODE SENSE of the disk when we're > probing it. That returns a status that indicates that the device is > indicating it is write protected. So we set the write_protect flags in the > disk structure which is what's reported above and used to generate the read > only errors. > > if you are lucky, this is a software write protect. That's on mode page > 0xa. camcontrol can read that: > # camcontrol modepage da0 -m 0xa > will report it. if SWP is 1, then it's a software lock. Add -e to the > above to edit it and change the line with SWP on it from 1->0 and save. > this will set the current value, turning it off temporarily. You can then > proceed to write to the device, with luck. > > Without luck the drive encountered a condition that made it decide to lock > you out forever from writing again. Thanks for the advice, Warner. I thought about camcontrol last night, but it's been a long long time since I've had a need for it. % camcontrol modepage da0 -l 0x08 Caching 0x1c Informational Exceptions Control 0x05 Flexible Disk % camcontrol modepage da0 -m 0xa camcontrol: mode sense command returned error I suppose this is the end for that memstick. -- Steve From nobody Tue May 23 15:21:01 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQdM83Sr4z4CbZK for ; Tue, 23 May 2023 15:21:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQdM82PWbz4FpJ for ; Tue, 23 May 2023 15:21:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=VB8wax0xUuzDQ5qCjyTogFmntcQF6vBEJqqlH/p9Av4=; b=yJiBJhC8LAoY5+JWxdvznTdGo7qTKqdmUKLIjczqrvG2n9F53OiBLo2CDeliHbd10kzaGcTWkUFYWxLZrIvD5EXytOJ5xXDn5FCMhPqlKKHkS0/Xrcqm6Qd6sdC40UxX3euiL7JP8HPTbcKUJX7sRNkpIXeG9XlyYoyTIiZB1Ixmj6fx7wb6eKBDKX8c0C1zuRLR1dmr9rwp8dGgV38qWjOf2NxYxM0W2OFw92/5y3/5C1CqAz0blyNHKsViKD4tVA5DweB7Ct2IqZbQUgMKZwA72w6fIxQXJMaXogTBPO+QfH0J9s8ThhqycsgsZlVxnltYgdP7AOYse1t5LCIaIw==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1q1TpB-000FnN-Ju; Tue, 23 May 2023 18:21:21 +0300 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: xdm and listen=tcp From: Daniel Braniss In-Reply-To: Date: Tue, 23 May 2023 18:21:01 +0300 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <86C9CA1E-9790-4FFF-BFF6-8C22EE35CF9C@cs.huji.ac.il> References: <255BDA89-2DD1-4805-95F1-5C01453A3E47@cs.huji.ac.il> To: Yuri X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4QQdM82PWbz4FpJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 23 May 2023, at 18:03, Yuri wrote: >=20 > Daniel Braniss wrote: >> hi, >> the short version: >> i start the X11 via the following line in /etc/ttys: >> ttyv8 =E2=80=9C/usr/local/bin/xdm -nodaemon=E2=80=9D = xterm on secure >>=20 >> this worked great since forever, but now(*) the default of Xorg is = not to accept tcp connection, >> is there a simple way to fix this, apart of recompiling Xorg and = somehow changing the default behavior? >>=20 >> *: now probably is a few years, since i have not uograded my WS for a = while - why change if it=E2=80=99s working, >> but mow it just went belly up :-( >=20 > You probably want /usr/local/etc/X11/xdm/Xservers. >=20 i tried=20 ;0 local /usr/local/bin/X :0 -listen=3Dtcp but maybe it should be: :0 local /usr/local/bin/X -listen=3Dtcp :0 nay other hints? thanks, danny From nobody Tue May 23 15:23:14 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQdPP5239z4Cbqh for ; Tue, 23 May 2023 15:23:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQdPP2YwDz4HBT for ; Tue, 23 May 2023 15:23:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 34NFNF2N036884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 23 May 2023 08:23:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 34NFNEJ4036883; Tue, 23 May 2023 08:23:14 -0700 (PDT) (envelope-from sgk) Date: Tue, 23 May 2023 08:23:14 -0700 From: Steve Kargl To: "Julian H. Stacey" Cc: Warner Losh , FreeBSD Hackers Subject: Re: gpart destroy efi partition? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <202305231055.34NAtLsE047127@dell.no.berklix.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202305231055.34NAtLsE047127@dell.no.berklix.net> X-Rspamd-Queue-Id: 4QQdPP2YwDz4HBT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, May 23, 2023 at 12:55:21PM +0200, Julian H. Stacey wrote: > Steve Kargl wrote: > > I did find > > > > % sysctl -a | grep da01 > > kern.geom.disk.da0.flags: 1a8 > > > > So, I suppose the question is how to clear WRITEPROTECT. > > I dont use efi & gpart but some ideas: > > Why da01 not da0 ? What is da01 ? > a typo, or pulling in some gpart kernel stuff ? > Yes, a typo. I used da0. > Is an escalated security level catching you ? I stick to default, > on 12.4-rel multi user thats: sysctl -a | grep level # kern.securelevel: -1 securelevel is -1. > Try a fresh reboot, even staying single user, > & before you touch it with any gpart invoking command, > whack it with multiple dd if=/dev/zero of=/dev/zero count=5000 > > (multiple as sometimes Ive seen first attempt doesnt seem to clear > my sticks, a 2nd reboot after dd will clear any false cached memories) > > If that doesnt work: > Try an older BSD that does know about EFI & gpart ? > Put it a Microsoft PC, or a USB to Go adapter on an android, > that probbly will complain unknown & offer to bash it back to MBR ? > Rumage around or ask friends, eg I have a tiny old match box size thing > that clones sticks. Clone your stick from some other small stick, > then repair the wrong sized MBR Thanks for the suggestions. I spent sometime on a Windows 10 system trying yo convince windows to format/destory/read/write do whatever to the memstick. FreeBSD tools are so much easier to use! >From what Warner has written, I think I'll write off this memstick. It was the right size for what I needed to do, but it's now past diminishing returns to play with some more. -- Steve From nobody Tue May 23 15:23:42 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQdPv1Cwlz4CbPV for ; Tue, 23 May 2023 15:23:47 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQdPt5gW2z4J2J for ; Tue, 23 May 2023 15:23:46 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=rRvC7+RG; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="E glHCDw"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.21 as permitted sender) smtp.mailfrom=yuri@aetern.org; dmarc=none Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 91E043200805 for ; Tue, 23 May 2023 11:23:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 23 May 2023 11:23:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1684855425; x=1684941825; bh=p5SHj5URKB/g1GCt5T0ZqJ9Xk9F34b3Jbxc NbJz1de8=; b=rRvC7+RGzpy3RuRJ1VXa/jK+5D0tr9YqpRp9AjsywvkhTQyK7cV xz+sF+dgMw8vlhHftGSCM6LAB2eetUHdQP7pnMXW0wxlZfBYh3i2siwZ8wzSVpJ2 JhJ9J+L+HhMkShGkzYI2RLZniwfZMaQdAqBnqmlSuPkgmaPwotWhHr5mYiMrd/46 ZLST6cmF2P4Amij1m5Ndb96FkPNf1cu9n4vpU5VANbR0rOwDcVQme8PjF+b+5NNq aidBP24ppSNoxwGmnR48h4SAbVtVX1dUf1kBN3tNLnuiz3fmqdnTZ9TtT48lFMKu uheWpNSoxmr+NSs7aAcPLcMgIllcBj+BzhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1684855425; x= 1684941825; bh=p5SHj5URKB/g1GCt5T0ZqJ9Xk9F34b3JbxcNbJz1de8=; b=E glHCDwRwzpksYbEhDfdLoWGq6xJt3Nf5mUrUuUhv8RV7p3p9nhM7WJ4AJIuO08lw qtG4mcPwO0LICaEe5o12yRNBfDAoeV9kcvLDt4h2iAITxTUsMlczyc6RSECW31Kl kdii/pGEYWpiO3l5mCyyDRnQHJiZ3GIHz61ThStecH4k0moCEX9DwjKAb0qlX5m3 8WcExIj7VFVOoSvFRAH+yY2MAWwNFfyv0iKbbq0HJMA8TUc8ZC9oCUU0UyT3CzaX uw4rTF0OTs2pg5G58l37+vNQEHzcCM+DhkBj6FD9eDgbUHwWmcbY3V4BMUxUtwR+ DDZ6Liq74BG51FYqTDYuQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeejfedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtke ertddtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeen ucggtffrrghtthgvrhhnpeehtdekheefleeuhefgueetgeevueektddutdegfffhueeute elgeeiteevjeeuveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpeihuhhrihesrggvthgvrhhnrdhorhhg X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 23 May 2023 11:23:44 -0400 (EDT) Message-ID: <62873693-1afe-c5ca-1431-f5e1c8c1d8da@aetern.org> Date: Tue, 23 May 2023 17:23:42 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: xdm and listen=tcp Content-Language: en-US To: hackers@freebsd.org References: <255BDA89-2DD1-4805-95F1-5C01453A3E47@cs.huji.ac.il> <86C9CA1E-9790-4FFF-BFF6-8C22EE35CF9C@cs.huji.ac.il> From: Yuri In-Reply-To: <86C9CA1E-9790-4FFF-BFF6-8C22EE35CF9C@cs.huji.ac.il> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QQdPt5gW2z4J2J X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21:c]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.21:from]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; local_wl_from(0.00)[yuri@aetern.org]; DMARC_NA(0.00)[aetern.org] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-ThisMailContainsUnwantedMimeParts: N Daniel Braniss wrote: > > >> On 23 May 2023, at 18:03, Yuri wrote: >> >> Daniel Braniss wrote: >>> hi, >>> the short version: >>> i start the X11 via the following line in /etc/ttys: >>> ttyv8 “/usr/local/bin/xdm -nodaemon” xterm on secure >>> >>> this worked great since forever, but now(*) the default of Xorg is not to accept tcp connection, >>> is there a simple way to fix this, apart of recompiling Xorg and somehow changing the default behavior? >>> >>> *: now probably is a few years, since i have not uograded my WS for a while - why change if it’s working, >>> but mow it just went belly up :-( >> >> You probably want /usr/local/etc/X11/xdm/Xservers. >> > > i tried > ;0 local /usr/local/bin/X :0 -listen=tcp > but maybe it should be: > :0 local /usr/local/bin/X -listen=tcp :0 It's '-listen tcp' actually (just checked that it works) :-) sorry I didn't mention there's unneded '=' in your first post. :0 local /usr/local/bin/X -listen tcp :0 From nobody Tue May 23 16:05:31 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQfLL6j8bz4CdWY; Tue, 23 May 2023 16:05:46 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQfLK6kZmz4Nwf; Tue, 23 May 2023 16:05:45 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=N7L+vi5t; spf=pass (mx1.freebsd.org: domain of gusev.vitaliy@gmail.com designates 2a00:1450:4864:20::22b as permitted sender) smtp.mailfrom=gusev.vitaliy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2af29e51722so239631fa.1; Tue, 23 May 2023 09:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684857943; x=1687449943; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=b1A/pwsrBKPrpnOnXMwIjxXuyJjG5a3N5tKA4NqjFPQ=; b=N7L+vi5taGmxOj5jG7/O1uHMQfELuW/wFxufMcpBkonKduQpO8whXPRE3hn22ObW5k JXkBqNomIQxm2252iSo3XlM8FHNzyZtQIpZ3z4JHvcB6bYlyZraH4QWkbV4pyhw4BwU3 JtQma1/grVgnpkmGWBMSiTaGuWnErU7FlyetBwN57UFpPyBNMISWWWhRD0lEBD0707je ElUw57mig33AKaU5XTPoftZDhjXB/ekfATI/6ZxsBYagBRf+Xy+LpPVDFeq8CdRVmC1a V4o7RqDX+DDkxT8MHECol38JaR2x2XwGjTLk39xioXXfFREBA1HtpoH7FStnGvQ+Ovdc mRhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684857943; x=1687449943; h=to:cc:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=b1A/pwsrBKPrpnOnXMwIjxXuyJjG5a3N5tKA4NqjFPQ=; b=b9oRNixYJqKqQqwyHStWe/GbGm50U09CP7GP6aQvIt6oGYqdfrFoglVVQL2yJ+yezW bQ4kgB636Txp/nWAoAbZzs/r5FIPdMQ6vIue/SAfQ4Jobx0nGXH4OxZjzESyYskjL0CQ ocWsESPp3Tt6gjIM7b+xRy+fqu69AvEkg+9sXr0alrKhBtDMoEN9OWHR/z2UZY3/Zrl9 QKBzezVkelAN0itf2bZKe32HuYgFPmS+96x0L69KxMJfLiBs3VZTJEYUGRXUBLPr7G5D gsSzsJNq0bE4nmM/aEYPyx258MsJMymfpxk0RpSYN7GU5twoai4uAoOIi+9Dgo3Xbiry /HAQ== X-Gm-Message-State: AC+VfDy2oC69NAaN0MITqUach21OR41UbgAxl6fmPhGm0oCtJkW3pa1H zT4cRmxMVrEYpw6fiyhDU7UFiZzaBCA= X-Google-Smtp-Source: ACHHUZ7Ht9U8+nVs76wvqwgPUZr66GEma0XvKqoh13Sa+5eDUOrMjmxnF6bsoG8r1LYeSMmwyoLWRQ== X-Received: by 2002:a2e:a318:0:b0:2a8:a6a9:4303 with SMTP id l24-20020a2ea318000000b002a8a6a94303mr5184581lje.8.1684857942775; Tue, 23 May 2023 09:05:42 -0700 (PDT) Received: from smtpclient.apple ([78.140.234.98]) by smtp.gmail.com with ESMTPSA id l7-20020a2e3e07000000b002af25598f07sm1659025lja.78.2023.05.23.09.05.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2023 09:05:42 -0700 (PDT) From: Vitaliy Gusev Content-Type: multipart/alternative; boundary="Apple-Mail=_574E1CEA-F86F-46F0-AC0E-FD372008C2F5" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: BHYVE SNAPSHOT image format proposal Message-Id: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> Date: Tue, 23 May 2023 19:05:31 +0300 Cc: freebsd-hackers@freebsd.org To: virtualization@freebsd.org X-Mailer: Apple Mail (2.3731.500.231) X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.945]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; BLOCKLISTDE_FAIL(0.00)[2a00:1450:4864:20::22b:server fail,78.140.234.98:server fail]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22b:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[virtualization@freebsd.org,freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4QQfLK6kZmz4Nwf X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_574E1CEA-F86F-46F0-AC0E-FD372008C2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Here is a proposal for bhyve snapshot/checkpoint image format = improvements. It implies moving snapshot code to nvlist engine.=20 Current snapshot implementation has disadvantages: 3 files per snapshot: .meta, .kern, vram Binary Stream format of data. Adding optional variable - breaks resume Removing variable - breaks resume Changing saved order of variables - breaks resume Hard to get information about what is saved and decode. Hard to debug if somethings goes wrong No versions. If change code, resume of an old images can be passed, but with UB. New nvlist implementation should solve all things above. The first step = - improve snapshot/checkpoint saving format. It eliminates three files = usage per a snapshot. 1. BHYVE SNAPSHOT image format: =20 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ | HEADER PHYS - 4096 BYTES | = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ | | | DATA | | | = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ 2. HEADER PHYS format:=20 0 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+=20= | IDENT STRING - 64 BYTES | 64 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ =20= | NVLIST SIZE - 4 BYTES | NVLIST DATA | 72 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ | | | NVLIST DATA | | | 4096 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ IDENT STRING - Each producer can set its own value to specify image. NVLIST SIZE - The following packed header nvlist data size. NVLIST DATA - Packed nvlist header data. 4KB should be enough for the HEADER to keep basic information about = Sections. However, it can be enlarged lately, without breaking backward compatibility.=20 3. NVLIST HEADER consists of Sections in the following format: Name - string Type: string: =E2=80=9Ctext, - plain text, =E2=80=9Cnvlist=E2=80=9D - packed nvlist, =E2=80=9Cbinary=E2=80=9D - raw binary data. Size - Size of section - uint64 Offset - Offset in image format - uint64 Predefined sections: =E2=80=9Cconfig=E2=80=9D, =E2=80=9Cdevices=E2=80= =9D, =E2=80=9Ckernel=E2=80=9D, =E2=80=9Cmemory=E2=80=9D.=20 4. EXAMPLE: IDENT STRING: "BHYVE CHECKPOINT IMAGE VERSION 1" NVLIST HEADER:=20 [config] config.offset =3D 0x1000 (4096) config.size =3D 0x1f6 (502) config.type =3D "text" [kernel] kernel.offset =3D 0x11f6 (4598) kernel.size =3D 0x19a7 (6567) kernel.type =3D =E2=80=9Cnvlist" [devices] devices.offset =3D 0x2b9d (11165) devices.size =3D 0x10145ba (16860602) devices.type =3D "nvlist" [memory] memory.offset =3D 0x1200000 (18874368) memory.size =3D 0x3ce00000 (1021313024) memory.type =3D =E2=80=9Cbinary" SECTIONS: [section "config" size 0x1f6 offset 0x1000]: memory.size=3D1024M x86.strictmsr=3Dtrue x86.vmexit_on_hlt=3Dtrue cpus=3D2 acpi_tables=3Dtrue pci.0.0.0.device=3Dhostbridge pci.0.31.0.device=3Dlpc pci.0.4.0.device=3Dvirtio-net pci.0.4.0.backend=3Dtap0 pci.0.7.0.device=3Dfbuf pci.0.7.0.tcp=3D10.42.0.78:5900 pci.0.7.0.w=3D1024 pci.0.7.0.h=3D768 pci.0.5.0.device=3Dahci pci.0.5.0.port.0.type=3Dcd pci.0.5.0.port.0.path=3D/ISO/ubuntu-22.04.1-live-server-amd64.iso lpc.bootrom=3D/usr/local/share/uefi-firmware/BHYVE_UEFI.fd checkpoint.date=3D"Wed Jan 25 23:48:29 2023" name=3Dubuntu22 [section "kernel" size 0x19a7 offset 0x11f6]: [vm] vm.vds_version =3D 0x1 (1) vm.cpu0.data(BINARY): 00 00 00 00 0D 00 00 00 01 00 00 00 00 00 = 00 00 ... size=3D0x28 vm.cpu1.data(BINARY): 00 00 00 00 0D 00 00 00 01 00 00 00 00 00 = 00 00 ... size=3D0x28 vm.checkpoint_tsc =3D 0xe2e0ac6fbe456 (3991273496896598) [hpet] hpet.vds_version =3D 0x1 (1) hpet.data(BINARY): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 ... size=3D0x118 [vmx] vmx.vds_version =3D 0x1 (1) vmx.cpu_features =3D 0 (0) vmx.cpu0.vmx_data(BINARY): F0 CC 15 B8 FF FF FF FF 40 B4 21 B9 = FF FF FF FF ... size=3D0x288 vmx.cpu1.vmx_data(BINARY): F0 CC 15 B8 FF FF FF FF 00 00 67 41 = D8 9B FF FF ... size=3D0x288 [ioapic] ioapic.vds_version =3D 0x1 (1) ioapic.data(BINARY): 00 00 01 00 00 00 00 00 00 00 00 00 00 00 = 00 00 ... size=3D0x208 [lapic] lapic.vds_version =3D 0x1 (1) lapic.cpu0.data(BINARY): 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 ... size=3D0x460 lapic.cpu1.data(BINARY): 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 ... size=3D0x460 [atpit] atpit.vds_version =3D 0x1 (1) atpit.data(BINARY): 00 00 00 00 00 00 00 00 54 AD 51 97 0F 0E 00 = 00 ... size=3D0xa0 [atpic] atpic.vds_version =3D 0x1 (1) atpic.data(BINARY): 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 = 00 ... size=3D0x84 [pmtimer] pmtimer.vds_version =3D 0x1 (1) pmtimer.uptime =3D 0x26fd133e5cc (2679274464716) [rtc] rtc.vds_version =3D 0x1 (1) rtc.data(BINARY): 0A 00 00 00 00 FE FF FF 10 35 13 3D 40 F7 14 = 00 ... size=3D0x98 =E2=80=94 Thanks, Vitaliy Gusev --Apple-Mail=_574E1CEA-F86F-46F0-AC0E-FD372008C2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Here is a proposal for bhyve = snapshot/checkpoint image format = improvements.

It implies moving snapshot code = to nvlist engine. 

Current snapshot = implementation has disadvantages:

  • 3 files per snapshot: .meta, .kern, = vram
  • Binary Stream format of data.
  • Adding  optional = variable - breaks resume
  • Removing variable - breaks = resume
  • Changing saved order of variables - breaks = resume
  • Hard to get information about what is saved and = decode.
  • Hard to debug if somethings goes wrong
  • No = versions. If change code, resume of an old images can be
    passed, but = with UB.

New nvlist implementation = should solve all things above. The first step -
improve = snapshot/checkpoint saving format. It eliminates three files = usage
per a = snapshot.


1. BHYVE = SNAPSHOT image format:  

+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94+
| =      HEADER PHYS - 4096 BYTES         = |
+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+
|             =                     =       |
|=                DATA   =                 = |
|     =                     =               = |
+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+


2. HEADER PHYS = format: 

 0   =  +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= + 
    =   |        IDENT STRING  - 64 BYTES   =       |
 64   = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ =   
      | NVLIST SIZE  - 4 BYTES =   |  NVLIST DATA |
 72   = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+
      | =                     =                     = |
      = |               NVLIST DATA   =             |
      |       =                     =               = |
 4096 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+


IDENT STRING - Each producer = can set its own value to specify image.
NVLIST SIZE  - = The following packed header nvlist data size.
NVLIST DATA - = Packed nvlist header data.

4KB should be enough = for the HEADER to keep basic information about Sections. However, it = can
be enlarged lately, without breaking backward = compatibility. 

3. NVLIST = HEADER consists of Sections in the following = format:

  • Name - = string
  • Type:    string:
    • =E2=80=9Ctext, =   - plain text,
    • =E2=80=9Cnvlist=E2=80=9D - packed = nvlist,
    • =E2=80=9Cbinary=E2=80=9D - raw binary = data.
  • Size - Size of section - uint64
  • Offset - = Offset in image format - uint64

    Predefined sections: =  =E2=80=9Cconfig=E2=80=9D, =E2=80=9Cdevices=E2=80=9D, =E2=80=9Ckernel= =E2=80=9D, =E2=80=9Cmemory=E2=80=9D. 


= 4. EXAMPLE:


 IDENT = STRING:

  =      "BHYVE CHECKPOINT IMAGE VERSION = 1"

 NVLIST = HEADER: 

  = [config]

    =     config.offset =3D 0x1000 (4096)

    =     config.size =3D 0x1f6 (502)

    =     config.type =3D "text"

  = [kernel]

    =     kernel.offset =3D 0x11f6 (4598)

    =     kernel.size =3D 0x19a7 (6567)

    =     kernel.type =3D =E2=80=9Cnvlist"

  = [devices]

    =     devices.offset =3D 0x2b9d (11165)

    =     devices.size =3D 0x10145ba (16860602)

    =     devices.type =3D "nvlist"

  = [memory]

    =     memory.offset =3D 0x1200000 (18874368)

    =     memory.size =3D 0x3ce00000 (1021313024)

    =     memory.type =3D =E2=80=9Cbinary"


 SECTIONS:


 [section = "config" size 0x1f6 offset 0x1000]:

memory.size=3D1024M

x86.strictmsr=3Dtrue

x86.vmexit_on_hlt=3Dtrue

cpus=3D2

acpi_tables=3Dtrue

pci.0.0.0.device=3Dhostbridge

pci.0.31.0.device=3Dlpc

pci.0.4.0.device=3Dvirtio-net

pci.0.4.0.backend=3Dtap0

pci.0.7.0.device=3Dfbuf

pci.0.7.0.tcp=3D10.42.0.78:5900

pci.0.7.0.w=3D1024

pci.0.7.0.h=3D768

pci.0.5.0.device=3Dahci

pci.0.5.0.port.0.type=3Dcd

pci.0.5.0.port.0.path=3D/ISO/ubuntu-22.04.1-live-serv= er-amd64.iso

lpc.bootrom=3D/usr/local/share/uefi-firmware/BHYVE_UE= FI.fd

checkpoint.date=3D"Wed Jan 25 23:48:29 = 2023"

name=3Dubuntu22


 [section "kernel" size 0x19a7 offset = 0x11f6]:

  =  [vm]

    =     vm.vds_version =3D 0x1 (1)

    =     vm.cpu0.data(BINARY): 00 00 00 00 0D 00 00 00 01 00 00 00 = 00 00 00 00 ...  size=3D0x28

    =     vm.cpu1.data(BINARY): 00 00 00 00 0D 00 00 00 01 00 00 00 = 00 00 00 00 ...  size=3D0x28

    =     vm.checkpoint_tsc =3D 0xe2e0ac6fbe456 = (3991273496896598)

  =  [hpet]

    =     hpet.vds_version =3D 0x1 (1)

    =     hpet.data(BINARY): 01 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 ...  size=3D0x118

  =  [vmx]

    =     vmx.vds_version =3D 0x1 (1)

    =     vmx.cpu_features =3D 0 (0)

    =     vmx.cpu0.vmx_data(BINARY): F0 CC 15 B8 FF FF FF FF 40 B4 = 21 B9 FF FF FF FF ...  size=3D0x288

    =     vmx.cpu1.vmx_data(BINARY): F0 CC 15 B8 FF FF FF FF 00 00 = 67 41 D8 9B FF FF ...  size=3D0x288

  =  [ioapic]

    =     ioapic.vds_version =3D 0x1 (1)

    =     ioapic.data(BINARY): 00 00 01 00 00 00 00 00 00 00 00 00 = 00 00 00 00 ...  size=3D0x208

  =  [lapic]

    =     lapic.vds_version =3D 0x1 (1)

    =     lapic.cpu0.data(BINARY): 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 ...  size=3D0x460

    =     lapic.cpu1.data(BINARY): 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 ...  size=3D0x460

  =  [atpit]

    =     atpit.vds_version =3D 0x1 (1)

    =     atpit.data(BINARY): 00 00 00 00 00 00 00 00 54 AD 51 97 0F = 0E 00 00 ...  size=3D0xa0

  =  [atpic]

    =     atpic.vds_version =3D 0x1 (1)

    =     atpic.data(BINARY): 01 00 00 00 00 00 00 00 00 00 00 00 01 = 00 00 00 ...  size=3D0x84

  =  [pmtimer]

    =     pmtimer.vds_version =3D 0x1 (1)

    =     pmtimer.uptime =3D 0x26fd133e5cc = (2679274464716)

  =  [rtc]

    =     rtc.vds_version =3D 0x1 (1)

    =     rtc.data(BINARY): 0A 00 00 00 00 FE FF FF 10 35 13 3D 40 = F7 14 00 ...  = size=3D0x98


=E2=80=94
Thanks,
Vitaliy = Gusev



= --Apple-Mail=_574E1CEA-F86F-46F0-AC0E-FD372008C2F5-- From nobody Tue May 23 16:45:02 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQgCs1rsbz4Cgk9; Tue, 23 May 2023 16:45:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQgCq6WBGz4TRH; Tue, 23 May 2023 16:45:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk; dmarc=none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 5DFC789293; Tue, 23 May 2023 16:45:03 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.17.1/8.16.1) with ESMTPS id 34NGj27l081240 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 23 May 2023 16:45:03 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.17.1/8.16.1/Submit) id 34NGj2Bq081239; Tue, 23 May 2023 16:45:02 GMT (envelope-from phk) Message-Id: <202305231645.34NGj2Bq081239@critter.freebsd.dk> To: Vitaliy Gusev cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: BHYVE SNAPSHOT image format proposal In-reply-to: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> From: "Poul-Henning Kamp" References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81237.1684860302.1@critter.freebsd.dk> Date: Tue, 23 May 2023 16:45:02 +0000 X-Spamd-Result: default: False [-2.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; BLOCKLISTDE_FAIL(0.00)[130.225.244.222:server fail]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,virtualization@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[phk]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-Rspamd-Queue-Id: 4QQgCq6WBGz4TRH X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N -------- Vitaliy Gusev writes: > 1. BHYVE SNAPSHOT image format: Please do not invent Yet Another Format, please ? Why not make it a tar(5) file ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue May 23 17:26:27 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQh7k04WZz4CjvF; Tue, 23 May 2023 17:26:42 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQh7j4Z2Kz4Y7d; Tue, 23 May 2023 17:26:41 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2af2e1725bdso1509091fa.0; Tue, 23 May 2023 10:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684862799; x=1687454799; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=S/ZTmuVyoeziujL0N7pYts/kBHYF9tHqFLcN7FXr8vU=; b=nJ+4q9iZHWMWJkkggN/MPQY8GNZYDBJDnNWqK/eKOpMjstRl7uYljQRnr+c5ld6btZ X58e8V0pHllashGAj7buySXF+5649mB3wf05nwidswMHco4P9/4EpjI5c3kXuuQAjdBX z4M4KD0hZo2HDwF0YSthbMCTVye1fJwfZG6j7wfT8+vlZ1uaC0/wrxW9nUskZC/voLEM R95gIDl64rWep7ZgZXVl4XcoX5mPBh6tDmufZuwKzWNj7nMRiHpqGRJoayEae4pV4uhs a+GV/SWgrx9K4NXLHa1bMtvzIfGsXKOOp1/4cyK4hMjNpFqpq3bxVoF/IDM/sY26/bUn dfww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684862799; x=1687454799; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=S/ZTmuVyoeziujL0N7pYts/kBHYF9tHqFLcN7FXr8vU=; b=Gls7fgDEpL4DMWxLj8fFIN/RtBU6FTPV8S5yDdy4kTVFCfEMDZG/HyxLid45ajVvhw pfqzaYRAh8rBfOz0SB7BUjEg7hAC4cYMNlzvxnBjl31QZeC0E/nsK5bIwL/awG0q6QEG DE6+PXYsNtlNmFS7mJKic6ndM14ek+/G8oQs/l/bSdVNFFwoR3eMsXxUD3AdSjdQaMiS 33o4nf1Y/blEEo+mfs0KXzygBesvbHjHbho2Aq29kVYvQdHdJPLD0oHqvoddE8meigpq NCgdDwu8dI+0Uf7ovuePF2Aohecgw14/B0BOnj0tFnzSGueB1/L5XwZWndDqC1Y6BJTa TkpA== X-Gm-Message-State: AC+VfDxA4Tni3+OUzsUrBrX9wmaxgy8xm+LZQO8vA9SnA4fI+ZXmjhy4 qHIpTPUAGjY81X+cE7BgbHMyuhPt/78= X-Google-Smtp-Source: ACHHUZ78yzYis+Rr48+V4neR82NEcMTfJFgJBCwE7JG6uidgOpTb5w7PVZ/ewDsuW32fDM+CWauuIw== X-Received: by 2002:a2e:b907:0:b0:2ad:9edd:4e2 with SMTP id b7-20020a2eb907000000b002ad9edd04e2mr4875567ljb.20.1684862798504; Tue, 23 May 2023 10:26:38 -0700 (PDT) Received: from smtpclient.apple ([78.140.234.98]) by smtp.gmail.com with ESMTPSA id j21-20020a2e8015000000b002aeee2a093csm1697061ljg.59.2023.05.23.10.26.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2023 10:26:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal From: Vitaliy Gusev In-Reply-To: <202305231645.34NGj2Bq081239@critter.freebsd.dk> Date: Tue, 23 May 2023 20:26:27 +0300 Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5544A8DA-4E91-4384-B72D-8C91B32B6D69@gmail.com> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <202305231645.34NGj2Bq081239@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QQh7j4Z2Kz4Y7d X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Hi, > On 23 May 2023, at 19:45, Poul-Henning Kamp = wrote: >=20 >=20 >> 1. BHYVE SNAPSHOT image format: >=20 > Please do not invent Yet Another Format, please ? >=20 > Why not make it a tar(5) file ? >=20 Tar cannot solve issues mentioned in =E2=80=9Cdisadvantages=E2=80=9D. = Tar doesn=E2=80=99t have versions, it is just container for files that would introduce another level of indirection. Snapshot/resume = doesn=E2=80=99t need just container. It needs information what is saved and in what format. For example, virtual = memory can be saved in different ways: binary, diff pages, etc. Virtual memory of VM should be saved faster without additional cost. The = same for restore stage. Do you like an idea to have tar file with size 8 GB ? And how it can be saved = efficiently without double copying of data? Yes, tar is powerful and convenient for many purposes, but it is not so = suitable to suspend/resume process and would introduce just another level of complexity. =E2=80=94=E2=80=94 Vitaliy Gusev= From nobody Tue May 23 18:58:27 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQk9w6Ppyz4Cp9x for ; Tue, 23 May 2023 18:58:44 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQk9v6KsFz3L3m for ; Tue, 23 May 2023 18:58:43 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=B7uEzEwP; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::b36) smtp.mailfrom=tomek@cedro.info; dmarc=none Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-ba818eb96dcso69224276.0 for ; Tue, 23 May 2023 11:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1684868322; x=1687460322; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nB+KETuhNWgh2rcrgLzJEn5b97eKXdyGdxRX3fKaMCc=; b=B7uEzEwP8SQldtubkIrU6NtvitAadiDiEB685dR5n5F2HlelFlg7a4YpTR/WNDvp+D ESrK4fRWMXshH+b38oaZR4fOWAwF6lFNAJHyRONeImAO7FPuA10RI9LZ7xLQnPfT1DdN +rfjpfYy8FBLbF4qemBVRMYYyM1NblaYqOJJJJywuNXTd5BJjhesPO0crz4eRwpFqYtP wqZnNHD9UmsKU5jkKdOO2StwJdbV0qz9lQ2omlrilsODgT12mumvqx8Ene0vQ7hyAJBe JPCAF6Eo/LHOY4+o3P2RCUjXeSeUCBLmbj68ifuJecXSNTY/FYwIpxCluZ73yQBDC7sE a29w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684868322; x=1687460322; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nB+KETuhNWgh2rcrgLzJEn5b97eKXdyGdxRX3fKaMCc=; b=hze0VMoYIM5+LmpAVrX6oXcj8Xwxl7dJ6ABaVK6YveNFq7ZPoORkdxQjHdF+Bkkh/Z q1O/ONpUJGBsrK/lxveEuZvitZ3MuhcYwJP5V9/8ux8TunUGLh3fMZyzsHEJQZ1Uu11L cUaGR/AqTCvdAu71cH1l2yi8n9vn6lJYoAr59h+nZoi+y62O1QY0fWhP2qAcLpufk6wk ld9fl90S1JdL6C/tQQAGbLnvC2GFPERYRpncnqbqUXeVprlg40du/IzYX0mllRR2ppni g0epyv4s0J5myGBTZN3Qx76gclEEp4+Z5JCEGMh+YFHBa0zygB+C5lXBMkIdqaJpQ9yF E0eg== X-Gm-Message-State: AC+VfDym4lCe/r9C8OYjzvcM0V+W+6VU/cnjbaEYu/3MMX4eFI5vp6xn kA9O26KH3hTGjO5/0CdRCeEpncFz8bsWiw1Td5g= X-Google-Smtp-Source: ACHHUZ4LaXPVxWPuZHqIBC38l4A+rOX47kIxSJJIHSOA/49K+n6SJjMf6M0uBrGBl2RC8PDKmw4aNQ== X-Received: by 2002:a25:6ac2:0:b0:b72:4ca:b3ce with SMTP id f185-20020a256ac2000000b00b7204cab3cemr14863980ybc.16.1684868322509; Tue, 23 May 2023 11:58:42 -0700 (PDT) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id b185-20020a0df2c2000000b0056507de3d82sm1669836ywf.104.2023.05.23.11.58.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 May 2023 11:58:42 -0700 (PDT) Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-ba6d024a196so46993276.2; Tue, 23 May 2023 11:58:42 -0700 (PDT) X-Received: by 2002:a81:4e4a:0:b0:55a:985e:8ad1 with SMTP id c71-20020a814e4a000000b0055a985e8ad1mr16906355ywb.33.1684868321800; Tue, 23 May 2023 11:58:41 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> In-Reply-To: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> From: Tomek CEDRO Date: Tue, 23 May 2023 20:58:27 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; BLOCKLISTDE_FAIL(0.00)[209.85.219.171:server fail,2607:f8b0:4864:20::b36:server fail]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b36:from,209.85.219.171:received]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[cedro.info]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4QQk9v6KsFz3L3m X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Tue, May 23, 2023 at 6:06=E2=80=AFPM Vitaliy Gusev wrote: > Hi, > Here is a proposal for bhyve snapshot/checkpoint image format improvement= s. > It implies moving snapshot code to nvlist engine. Hey there Vitaliy :-) bhyve getting more and more traction, I am new user of bhyve and no expert, but new and missing features are welcome I guess.. there was a discussion on the mailing lists recently on better snapshots mechanism :-) > Current snapshot implementation has disadvantages: > 3 files per snapshot: .meta, .kern, vram No problem, unless new single file will be protected against corruption (filesystem, transfer, application crash) and possible to be easily and cheaply modified in place? > Binary Stream format of data. This is small and fast? Will new format too? > Adding optional variable - breaks resume > Removing variable - breaks resume > Changing saved order of variables - breaks resume Obviously need improvement :-) > Hard to get information about what is saved and decode. > Hard to debug if somethings goes wrong Additional tools missing? Will new format allow text editor interaction? > No versions. If change code, resume of an old images can be > passed, but with UB. Is new format future proof and provides backward compatibility? > New nvlist implementation should solve all things above. The first step - > improve snapshot/checkpoint saving format. It eliminates three files usag= e > per a snapshot. > > 1. BHYVE SNAPSHOT image format: > > +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ > | HEADER PHYS - 4096 BYTES | > +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ > | | > | DATA | > | | > +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ > (..) > Predefined sections: =E2=80=9Cconfig=E2=80=9D, =E2=80=9Cdevices=E2= =80=9D, =E2=80=9Ckernel=E2=80=9D, =E2=80=9Cmemory=E2=80=9D. > 4. EXAMPLE: > IDENT STRING: > "BHYVE CHECKPOINT IMAGE VERSION 1" > NVLIST HEADER: > [config] > config.offset =3D 0x1000 (4096) > config.size =3D 0x1f6 (502) > config.type =3D "text" > [kernel] > kernel.offset =3D 0x11f6 (4598) > kernel.size =3D 0x19a7 (6567) > kernel.type =3D =E2=80=9Cnvlist" > (..) So this will be new text config based format with variable =3D value and se= ctions? How much bigger will be the overal file size increase? How much longer it will take do decode/encode/process files? What is the possibility of format change and backward/foward compatibility? Have you considered efficiency comparison of current format, proposed format, and maybe using SQLITE or JSON storage/parsers? For instance sqlite would be blazingly fast but hard to migrate. json would be most versatile but more time/memory consuming? Maybe EFL approach of storing configuration files for limited resources embedded system storage that use binary storage data but can be decompressed in chunks that can be replaced in place? https://www.enlightenment.org/develop/efl/start Sorry for asking those questions but there may be already good and verified solutions out there not to reinvent the wheel? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Tue May 23 19:45:37 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQlQW6NXsz4Syd1 for ; Tue, 23 May 2023 19:54:43 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQlQV1XXPz3ktY for ; Tue, 23 May 2023 19:54:42 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of li-fbsd@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=li-fbsd@citylink.dinoex.sub.org; dmarc=none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 34NJs6mP076063 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 23 May 2023 21:54:06 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: (from uucp@localhost) by uucp.dinoex.org (8.17.1/8.17.1/Submit) with UUCP id 34NJs59a076062 for freebsd-hackers@freebsd.org; Tue, 23 May 2023 21:54:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from admn.intra.daemon.contact (localhost [127.0.0.1]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 34NJk56s031498 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 23 May 2023 21:46:06 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from intra.daemon.contact (news@localhost) by admn.intra.daemon.contact (8.17.1/8.17.1/Submit) with NNTP id 34NJjbmw031199 for freebsd-hackers@freebsd.org; Tue, 23 May 2023 21:45:37 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: admn.intra.daemon.contact: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: "Peter 'PMc' Much" X-Newsgroups: m2n.fbsd.hackers Subject: Re: gpart destroy efi partition? Date: Tue, 23 May 2023 19:45:37 -0000 (UTC) Message-ID: References: Injection-Date: Tue, 23 May 2023 19:45:37 -0000 (UTC) Injection-Info: admn.intra.daemon.contact; logging-data="22004"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: slrn/1.0.3 (FreeBSD) To: freebsd-hackers@freebsd.org X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Tue, 23 May 2023 21:54:08 +0200 (CEST) X-Spamd-Result: default: False [-0.97 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.67)[-0.669]; NEURAL_HAM_MEDIUM(-0.30)[-0.304]; FORGED_SENDER(0.30)[pmc@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sub.org]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[pmc@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org] X-Rspamd-Queue-Id: 4QQlQV1XXPz3ktY X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 2023-05-23, Warner Losh wrote: > > Without luck the drive encountered a condition that made it decide to lock > you out forever from writing again. As this was said to be an USB memstick... There are apparently problems with (some?) newer such memsticks: My old ones work fine with partitions of UFS or even ZFS. But my newer ones have horribly bad performance with UFS filesystems (and these are not the cheapest chinese pieces). It seems to me like they might have internal intelligence that optimizes for typical microsoft filesystems. So I once tried what would happen when I continue writing into an UFS filesystem on the stick no matter how long it takes - and what happened was exactly what Warner describes: after some time the thing switched itself to read-only. In fact I have a problem with this, because I need a means to store single files of 20+ GB on a stick. From nobody Wed May 24 00:25:16 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQsQj0HjXz4TFZm for ; Wed, 24 May 2023 00:25:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQsQh530Rz4Gw3 for ; Wed, 24 May 2023 00:25:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684887916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ivk7H9ERPckGn9dwfO0oZgxea6IKFR07N8yNnE84dCM=; b=lpihoVPzOasUjtVpmtztZ/hbslC4dtwOlQVQNNeUL5ymHZ25YWO+Hwx3X80C7ojleG4wft 5vD/kLvijazWTT+V76ZJfI3gxEkg/wdwYQzgkQudqzLWi9db+Z2YFNFdCZTWB5AQzhybiB iGHv3uMDNkk6btwnHrji3bKBLL5OPnlRAuX3V+l7vzdj/L/vDXt0FWUcXsizCffrSB3vTP ECaxq9o6WkjqHw5gFdxcL0MYeeT6OG7vDsQ3nmgmHSwwRPEV5UPMvJsjfJwr4C6+gZPslj FWiEvt5+iWby8P1VJI9u/DNcIbNoUwcp6D9EBq2GPLZ0ZygzVjjNFlG7uyM14g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684887916; a=rsa-sha256; cv=none; b=B4eVcsA9XMZ8PSX6mSDDaQpphKIkQDPAJ3KJwDTtXA3vdGHLlUkv7JgwL/X3Ytp2ftCLpW AYxNggo6NicwIqkXOrMG6GEy4nZeYGuatInRbigJ6okaNPzlaqTYk1NP2R1WljXHNhVKSC 4lxgkSmr9mB794/6BUYfwP+Hz0oEda8gqIPO90PbMnT8GdX9IKXHaBqmrCDCRXGCDU2Nzu YNELsZ9kLM0TcZ35d5qsAqwiQE6Mg2nwvNrIM7wF8vds0bstsuNAJBjBimD8F+wzF9o3Bj llGZ2r1nSS3M0mM8b2r9JjhYugMKQME80JL3aG7suTXyL5i/27Xw1/tyYwJO8g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QQsQh48DHzM7V for ; Wed, 24 May 2023 00:25:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 34O0PGh7063579 for ; Wed, 24 May 2023 00:25:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 34O0PGb3063578 for hackers@FreeBSD.org; Wed, 24 May 2023 00:25:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: hackers@FreeBSD.org Subject: [Bug 270601] freebsd-hackers and freebsd-stable list archives: for some messages, URLs have changed Date: Wed, 24 May 2023 00:25:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Services X-Bugzilla-Component: Mailing Lists X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: grahamperrin@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: postmaster@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270601 Graham Perrin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hackers@FreeBSD.org, | |stable@FreeBSD.org Summary|freebsd-stable list archive |freebsd-hackers and |presents the wrong email |freebsd-stable list | |archives: for some | |messages, URLs have changed --- Comment #2 from Graham Perrin --- Another example =E2=80=A6 Bug 260994 refers to (000741), which is currently:=20 > Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current =E2=80=93 that is unrelated to the bug.=20 At the time of me linking, it was probably this, from Warner:=20 > Re: 5.9 points Re: 7.0 points 5.1 points Re: Call for Foundation-supporte= d Project Ideas =E2=80=93 that is currently (000745). --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Wed May 24 00:27:57 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQsTn4drlz4TFPX for ; Wed, 24 May 2023 00:27:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQsTn2blhz4JwB for ; Wed, 24 May 2023 00:27:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684888077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rZJ4Wo6dsnhCyHC0Ct1COEXEmzBXWapn68mv1aRvTog=; b=ZMmxphjE++YnkMC+Z41sdTc+7lVIUIrmXi1wim3kPjwSOcBATloIUZfYffr4uzeXJHZVpj SnJOqbPXYZUGC/1pF5ovk1eXvcTV8l7qwb9GFpUic25hXe6K6wueZxLs7q40A9t7fPiAbj /V8aJdYKeyUbCmfFR00LbyYbsGxDzJeFue3JkI9eBl5Zak1SvPabLI1uzAebgD1f0/YCNG C3xltoGzAmSuY9RUkk1spXeiwS8Z8dg9SmLLLInbTLnLcwZ5XpVwa1ocVIhJPANEJYjUZD 3UnD9TOtuieAU5292otlas4fnCGL7pW/n3G1Ldgk7+N9QV4VJSkEx8zOAkJlvA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684888077; a=rsa-sha256; cv=none; b=S3hCwZqE7R8rJtRvhpwSlrhvVk/hGn6l/FwTpOjQ4D5wUXtvjk0aDUtqc88CHDrMvHpV7b RExeQstwDopYTk6t7VJA3AZObHQiqRoV+G9oMWDWn5HkpXv/xX+c1RjtwuUm4NaXzppPje Bv5ScwrVLl+BOpMX0KTYy6Z5BJNFMIMdD6lyzqoUzqaIBoDDjccYgXplgt3v3crT4i8Ipg v+gCAHgqntvdlJldQOEULANHO2hOmdD/3koBDWsIzuR0NlO4BgpSo4sxZ0xnelausSKzdH 3b2wVSTqZX2zUw0Q0nhf8UKQwktdb/t8/zF80e08KavjseAHhaMGQNHIUZijJQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QQsTn1hYSzMQW for ; Wed, 24 May 2023 00:27:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 34O0RvPg064296 for ; Wed, 24 May 2023 00:27:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 34O0Rv8Z064295 for hackers@FreeBSD.org; Wed, 24 May 2023 00:27:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: hackers@FreeBSD.org Subject: [Bug 270601] freebsd-hackers and freebsd-stable list archives: for some messages, URLs have changed Date: Wed, 24 May 2023 00:27:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Services X-Bugzilla-Component: Mailing Lists X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: grahamperrin@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: postmaster@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270601 --- Comment #3 from Graham Perrin --- (In reply to Graham Perrin from comment #2) Two more examples from the same period (January 2022).=20 A)=20 (000751) was:=20 > Debugging a (potentially?) ZFS-related panic, and discussion about large = patchsets is now:=20 > Re: Out-of-swap killer and SIGTERM signal B)=20 (000800) was:=20 > Re: Dragonfly Mail Agent (dma) in the base system is now:=20 > Re: Which disk is which? --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Wed May 24 01:04:13 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQtHd5jF0z4TGqC for ; Wed, 24 May 2023 01:04:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQtHd34sdz4Nnt for ; Wed, 24 May 2023 01:04:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684890253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LlW6xunAjbqmCFPkUOgyEDASMYMphxN+xZ5eKQtT8F8=; b=DoE8U5cKf9j9CMvDsSb6IVyP/bCzSRljnIsQWoChcyOUc/rRtkOlKe3GBCS1MrZVORY7cQ ElUMikBHUcaRbZDmZWyRf3RdGwVPFYwVUPCXq4oLDQRkaE/Kt1mfFkBejbIkXgOx118/MP TuuoEyBe+GyN8rf4M/Aio/iJMEIS3uXI7hYH9+TIZMCMSAPCJtpB0QHqczGA2NLuEmFLd4 UfDz2yG2V4xsyJIN7Q7Oc4doR/AkSvpqtyIFmBnfC8oCj5FsRYbnRYl6CqXO65vFZexPyJ NjztF/oc3V+8/F7bwKKTMPtIk4vMHKdniRcHMIjhW3rO+CMBwX8mT4Zf/ZxzAQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684890253; a=rsa-sha256; cv=none; b=LEuxKd1+21JtuWSw79W622r63hVQ/pvOSrjGcoN9Vy3FVuperwzvP8SAFJXBsmq5QJ3JRl Ld4cNaepEUNCrhjLwCYKZDKYfwNvbamPr5oArJfk6dg1lmIQCP38PcicpFEpid+NkB1MvL FRfvBERwARlFiPTy2zpQEEwk7F8g06J78bNXMXJcI5oM53hWfZe9gCe573zffr5LwkOKmJ d+hnM0m64siwi707OktBKThxjESCWALHgcqXpHdiPCq/oSS835bqsGGozbHS2Xa+tduVaW ealz6vyDvFA9jz8OLvloQXu8DApvKOH73IGRdWUQjQkLdx6vWixW1oNQA/cdtQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QQtHd291SzNM6 for ; Wed, 24 May 2023 01:04:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 34O14DKg020284 for ; Wed, 24 May 2023 01:04:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 34O14DZ3020283 for hackers@FreeBSD.org; Wed, 24 May 2023 01:04:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: hackers@FreeBSD.org Subject: [Bug 270601] freebsd-hackers and freebsd-stable list archives: for some messages, URLs have changed Date: Wed, 24 May 2023 01:04:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Services X-Bugzilla-Component: Mailing Lists X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vishwin@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: postmaster@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270601 Charlie Li changed: What |Removed |Added ---------------------------------------------------------------------------- CC|hackers@FreeBSD.org, | |stable@FreeBSD.org | --- Comment #4 from Charlie Li --- We don't need the mailing lists themselves as CCs; they have way too many subscribers between them, particularly for something that only postmaster@ = can do much about. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Wed May 24 04:08:30 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQyNN3YJRz4TS2q for ; Wed, 24 May 2023 04:08:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQyNN0hLVz3R99 for ; Wed, 24 May 2023 04:08:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=1H5bnU4tUORACrRuYGEqUyjZhjp3XjSfIi4EWxdRhhI=; b=wMM4vFYLvFqSyAw6BL1jxDOzLQsj/OPvV/kIteuoFPHNb8yDEgdFVEjbAthv5Dtc+EQvqpEo5hMSHLEQc+4txVYWorb/VrtJNv7k1r39adzTzDJ9VZNCs9kEY77p+ytknNuf7/9GL0vVBUNuLYH4n3QMj1ufrwucqq/3uIGWfxJ2ANjQjY2IA8FfIxDnPWXnyeae2KdD52gkXFp3GlXJBFvqv/4P4WXvMNuCuIMzipp3VUNMsCgNS7HnphNAMoN/WsEy7Bf9Rnh0DRWDLoHxFKT5qzkTFgtNE6rC70+Eyt+1G7w7sWQEnCvgue4iTtbD6ySUPoTllL7h/J6FWK/kkw==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1q1fna-000EeZ-SG; Wed, 24 May 2023 07:08:30 +0300 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: xdm and listen=tcp From: Daniel Braniss In-Reply-To: <62873693-1afe-c5ca-1431-f5e1c8c1d8da@aetern.org> Date: Wed, 24 May 2023 07:08:30 +0300 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <33376F0A-1722-4D7C-B793-65FD8044E28D@cs.huji.ac.il> References: <255BDA89-2DD1-4805-95F1-5C01453A3E47@cs.huji.ac.il> <86C9CA1E-9790-4FFF-BFF6-8C22EE35CF9C@cs.huji.ac.il> <62873693-1afe-c5ca-1431-f5e1c8c1d8da@aetern.org> To: Yuri X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Rspamd-Queue-Id: 4QQyNN0hLVz3R99 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 23 May 2023, at 18:23, Yuri wrote: >=20 > Daniel Braniss wrote: >>=20 >>=20 >>> On 23 May 2023, at 18:03, Yuri wrote: >>>=20 >>> Daniel Braniss wrote: >>>> hi, >>>> the short version: >>>> i start the X11 via the following line in /etc/ttys: >>>> ttyv8 =E2=80=9C/usr/local/bin/xdm -nodaemon=E2=80=9D = xterm on secure >>>>=20 >>>> this worked great since forever, but now(*) the default of Xorg is = not to accept tcp connection, >>>> is there a simple way to fix this, apart of recompiling Xorg and = somehow changing the default behavior? >>>>=20 >>>> *: now probably is a few years, since i have not uograded my WS for = a while - why change if it=E2=80=99s working, >>>> but mow it just went belly up :-( >>>=20 >>> You probably want /usr/local/etc/X11/xdm/Xservers. >>>=20 >>=20 >> i tried=20 >> ;0 local /usr/local/bin/X :0 -listen=3Dtcp >> but maybe it should be: >> :0 local /usr/local/bin/X -listen=3Dtcp :0 >=20 > It's '-listen tcp' actually (just checked that it works) :-) sorry I > didn't mention there's unneded '=3D' in your first post. >=20 > :0 local /usr/local/bin/X -listen tcp :0 >=20 bingo, that did it! maybe it should be added to the X11 section of the doc? thanks, danny From nobody Wed May 24 08:43:52 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QR4Vk1JbHz4CRM6 for ; Wed, 24 May 2023 08:44:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QR4Vj2wqCz44pD for ; Wed, 24 May 2023 08:44:29 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=evN9rWsn; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b33 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-ba8cf3cb34fso1269907276.1 for ; Wed, 24 May 2023 01:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684917868; x=1687509868; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=whu/GzXnQdUuoCAFj6ttZ5AB39zRaT/0EUYq2HoygCI=; b=evN9rWsnzo0422rQCtPVxbt3hZ6bubNqxzA9O0tsl6eFD0hUNoFqu3vl5vDZH74pBb MRO5YFHuQuN+zyo4CW6vESZoBE771rYPnVSxTMhXYRK/LSx0xjyeK+L2hBJEpy4cGaus gWsEg+DfzA8vpPmdEY2eu4CCTF/y9w6kKx+F8d57LX84uyS0OUaBQ9nOGKUoOjCqaZs4 Nnny5J2Z/HxK6N7YFCboWRKOOrXinw8eOTORTAKc83wFs84YsAMJmZAQ3Ph6lg9WTh4V duROhHvoUEgyhllhVn5PyP6yPj7owB/nloyMuT7+QT1t7Arltiv2EyaKRslsHOcfxrvC q/NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684917868; x=1687509868; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=whu/GzXnQdUuoCAFj6ttZ5AB39zRaT/0EUYq2HoygCI=; b=Bvqcv92qWerpaEMlE/9omy561PkgtSW5d8PBjx8A3yc95cndppc+eRbxghfyC6xty1 /MYdkAPEOy+wK2mRbEbQAtQ5KEKW4+jFSNMrqOzQabCxxnMK7iWr+jC0x1VBbMhxAHrf kAxQ/9OyTVLPqmFo4Mcy5J1fkL6ewTsouXUG+PaFJ6w+RtLAPVghQX1rZpJzlDhVrB+6 96HV9A2i84zuv8pWl3ZitySkVwxP1lcg1gUMvNkAD+gX7gbZtxFjcjn6CzeItbqm970C 7Jiha3U3NI2hLf8aMIs976SMkVjHDXKzLzkZpYqQ4VhUVuAMuEF9ImUHGFm/UPMMf+ve 5vHQ== X-Gm-Message-State: AC+VfDz79CJYYYbtIYFFPIxPPdM6qwCieq3aISTlqGYpUTxnfnMyFxtv vcx9qfqGtNqXDXJRCCmpt/d7FDPpU+dNB4LPA6HqxQLZhIE= X-Google-Smtp-Source: ACHHUZ7tpAVJAP5GWj+n6UFUGw0hqnnJO/cKYgO9cg7zXNbmclsLdAflV1h+f/EzkpaHOOVs1zAr2bQ83qlbKjXwb2Y= X-Received: by 2002:a25:1e09:0:b0:bac:46f2:8d0f with SMTP id e9-20020a251e09000000b00bac46f28d0fmr7567819ybe.3.1684917868209; Wed, 24 May 2023 01:44:28 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Wed, 24 May 2023 10:43:52 +0200 Message-ID: Subject: How to blacklist the nouveau driver on FreeBSD.... To: freebsd-hackers Content-Type: multipart/alternative; boundary="00000000000002a9a205fc6c8359" X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.97)[-0.970]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b33:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4QR4Vj2wqCz44pD X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --00000000000002a9a205fc6c8359 Content-Type: text/plain; charset="UTF-8" Hello. I wrote this tutorial some time ago because I wanted that Blender was able to recognize CUDA and the Nvidia driver directly within the linuxulator : https://www.reddit.com/r/freebsd/comments/1118eae/how_to_install_the_nvidia_driver_5257801_cuda_12/ (I was inspired by this tutorial : https://gist.github.com/Mostly-BSD/4d3cacc0ee2f045ed8505005fd664c6e) someone found my tutorial and created this github : https://github.com/spfcraze/Nvidia-Drivers-linux He says that he created a Python script for updating Nvidia drivers on CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please give a look to an old post created by me some time ago and you will see : https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_nouveau_driver_within_the/ since the nouveau driver can't be blacklisted within the Linuxulator because it's impossible to run "sudo update-initramfs -u" inside of it. For this reason,I would ask if in your opinion the nouveau driver can be blacklisted directly in FreeBSD or in some other way. Thanks. -- Mario. --00000000000002a9a205fc6c8359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I wrote this tut= orial some time ago because I wanted that Blender was able to recognize CUD= A and the Nvidia driver directly within the linuxulator :

(I was inspired by this tutor= ial :


someone foun= d my tutorial and created this github :


He says that he created a Python script for updating Nvidia drivers=20 on CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please= give a look to an old post created by me some time ago and you will see :


since the nouveau driver can= 't be blacklisted within the Linuxulator because it's impossible to= run "sudo=20 update-initramfs -u" inside of it. For this reason,I would ask if in y= our opinion the nouveau driver can be blacklisted directly in FreeBSD or in some other way. Thanks= .

--
Mari= o.
--00000000000002a9a205fc6c8359-- From nobody Wed May 24 15:10:49 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRF4l5BmPz4Cpqy; Wed, 24 May 2023 15:11:03 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRF4l11xkz3sk2; Wed, 24 May 2023 15:11:03 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-4f00d41df22so1050881e87.1; Wed, 24 May 2023 08:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684941061; x=1687533061; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=1yB/FsRx+5zL23ybcm4qwD8TsIzyLeLgWMfyeSKOMNQ=; b=W64aUx+oW8OFnUJF3wWuKRG1vTSmDPAiBXzEX0pM4LBBt2Tm4blg64TDToqpWfd4Q2 z/eDUpeY+uAbAqJUWQtsMBAWu5b1NAGjZts5hOzMEBVioi9WGqMccekwbq7xDf9k0k8B LyPhSpJTOLq/yYp1EXc1zNLxDRofWXdZ8XbC8Am5KNxQfRdv2rm+7BI7LEqDUn6Ocp98 M2IPQ42UAw2ysevxDxUOwsJhOfbwtd84MAOpy9kelpqAymCE4qscsHmD1rZgZJCmrV/E /tCibY/cecEeVWH0QAvvn4j2duzILlTEMwqLWFWggqnnwUB6gByukFyU2eABcvO84kaX fmOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684941061; x=1687533061; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1yB/FsRx+5zL23ybcm4qwD8TsIzyLeLgWMfyeSKOMNQ=; b=NfAeMxluefkN82EO7KJUgQu0ITu96TASE7JKZVK1AJZCtfza4rkHDzl4LSDoMeKhsp 9FnetyRFPiV3svd2n9sKFCOCcACN4iSWGUL9qQl0FJ7FTFWFMDAUA6VPXcP2/Lng0DEJ /l/9WlpSq1f0qYkl0p1pUYZCHZREb7lmjBLwaPoMpgH8uM0IMoRYMnEQF3vvrU3o1Fqi FuMu/oBHUpb/Y5bCGmpZelZUZbn9pJoEGv9wmw3t/DIajn4EERU6OMfFYxVuoRWklmpH IZkr5+q4wZDrJ3dSxByJnkHFq196r9fqgKnIjUzn2joHUCHCBKFN6fcTq6xaQpPD35dA mrqQ== X-Gm-Message-State: AC+VfDwFqVbeJhwSTUOWStmGdf6acNlWbbIs//5T7ujP5LtHBTmmgHuB qEokVUgZfL/eHVHe3VMA6BlgIDPuY3M= X-Google-Smtp-Source: ACHHUZ4Il2yAc46NVzC54B0e5E+NWEnNKOiuhzubO8uSZeDitSezIDGRNVlIBjMt1pgsw2jqmhQniQ== X-Received: by 2002:ac2:488b:0:b0:4f4:ca61:82b3 with SMTP id x11-20020ac2488b000000b004f4ca6182b3mr775605lfc.21.1684941060833; Wed, 24 May 2023 08:11:00 -0700 (PDT) Received: from smtpclient.apple ([188.187.60.230]) by smtp.gmail.com with ESMTPSA id b10-20020a056512024a00b004f13634da05sm1749710lfo.180.2023.05.24.08.11.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2023 08:11:00 -0700 (PDT) From: Vitaliy Gusev Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B2C31D91-4697-4C26-ADE9-9F456DBBFFC5" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Wed, 24 May 2023 18:10:49 +0300 In-Reply-To: Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org To: Tomek CEDRO References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRF4l11xkz3sk2 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_B2C31D91-4697-4C26-ADE9-9F456DBBFFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tomek, Try to answer to the all questions below, please let me know if I miss = some important. > On 23 May 2023, at 21:58, Tomek CEDRO wrote: >=20 > On Tue, May 23, 2023 at 6:06=E2=80=AFPM Vitaliy Gusev wrote: >> Hi, >> Here is a proposal for bhyve snapshot/checkpoint image format = improvements. >> It implies moving snapshot code to nvlist engine. >=20 > Hey there Vitaliy :-) bhyve getting more and more traction, I am new > user of bhyve and no expert, but new and missing features are welcome > I guess.. there was a discussion on the mailing lists recently on > better snapshots mechanism :-) >=20 >=20 >> Current snapshot implementation has disadvantages: >> 3 files per snapshot: .meta, .kern, vram >=20 > No problem, unless new single file will be protected against > corruption (filesystem, transfer, application crash) and possible to > be easily and cheaply modified in place? Current snapshot implementation doesn=E2=80=99t have it. I would say = more, current pkg implementation doesn=E2=80=99t track/notify if some of files are = changed. Binary files on a system can be changed, for example ELF files, without any notification. Tar doesn=E2=80=99t have protection for keeping data. Some filesystems = like ZFS guarantee that data is not modified by underlying disks. Protecting requires more efforts and it should be clearly defined: what = is purpose. If purpose is having checksum with 99.9% reliability, NVLIST HEADER can be = widen to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. If purpose is having crypto verification - I believe sha256 program = should be your choice. >=20 >> Binary Stream format of data. >=20 > This is small and fast? Will new format too? Small is not so perfect. As the first attempt snapshot code is good. But = if you want to get values related to some specific device, for example, for NIC or HPET, = you cannot get it easily. Please try :) Stream doesn=E2=80=99t have flexibility. It is good for well specified = and long long time discussed protocols like XDR (NFS), when it has RFC and each position in the stream is = described. Example: RFC1813. New format with NVLIST has flexibility and is fast enough. Note, ZFS = uses nvlist for keeping attributes=20 and more another things. >> Adding optional variable - breaks resume >> Removing variable - breaks resume >> Changing saved order of variables - breaks resume >=20 > Obviously need improvement :-) >=20 >> Hard to get information about what is saved and decode. >> Hard to debug if somethings goes wrong >=20 > Additional tools missing? Will new format allow text editor = interaction? Why do you need modify snapshot image ? Could you describe more? Do you modify current 3 snapshot files? >> No versions. If change code, resume of an old images can be >> passed, but with UB. >=20 > Is new format future proof and provides backward compatibility? Intention of moving to the new format - to have backward compatibility = if some code is changed: Adding optional variable=20 Removing variable that is not used anymore Change order of saving variables =E2=80=9CHot Fixes=E2=80=9D. If changes are critical and are incompatible, restore stage should have = clear information about incompatibility and break resume. Ideally it should be able to get = informed even before starting restore process. For this purpose, the new format introduce versions. >=20 >> New nvlist implementation should solve all things above. The first = step - >> improve snapshot/checkpoint saving format. It eliminates three files = usage >> per a snapshot. >>=20 >> (..) >=20 > So this will be new text config based format with variable =3D value = and sections? This is NVLIST approach with key=3Dvalue, where key is string, and value = can be Integer, array, string, etc. >=20 > How much bigger will be the overal file size increase? Not so huge. NVLIST internals is well specified. For example, for my VM [kernel] kernel.offset =3D 0x11f6 (4598) kernel.size =3D 0x19a7 (6567) kernel.type =3D =E2=80=9Cnvlist" [devices] devices.offset =3D 0x2b9d (11165) devices.size =3D 0x10145ba (16860602) devices.type =3D =E2=80=9Cnvlist=E2=80=9D So packed size for kernel is 6567 bytes, for devices is 16860602 = including framebuffer 16MB. If remove fbuf, packed nvlist devices Section has size = 83386 bytes. >=20 > How much longer it will take do decode/encode/process files? It is fast, just several milliseconds. NVLIST is very fast format. It is = already integrated into bhyve as Config engine. >=20 > What is the possibility of format change and backward/foward = compatibility? If you are talking about compatibility of a Image format - it should be = compatible in both directions, at least for not so big format changes. If consider overall snapshot/resume compatibility - I believe forward = compatibility is not case and target. Indeed, why do you need to resume an image = created by a higher version of a program?=20 The most important thing - backward compatibility, i.e. when an image is = created by an older version of a program, but should be resumed on a new one. This is target and and intention of this improvement. >=20 > Have you considered efficiency comparison of current format, proposed > format, and maybe using SQLITE or JSON storage/parsers? For instance > sqlite would be blazingly fast but hard to migrate. json would be most > versatile but more time/memory consuming? Yes, I know about another formats, like JSON or others. NVLIST is the = most effective and suitable for the current purposes. >=20 > Maybe EFL approach of storing configuration files for limited > resources embedded system storage that use binary storage data but can > be decompressed in chunks that can be replaced in place? > https://www.enlightenment.org/develop/efl/start There are many things that can be used, but it should be well known, = easy, stable, fast and supportable. I believe NVLIST is the best choice. >=20 > Sorry for asking those questions but there may be already good and > verified solutions out there not to reinvent the wheel? :-) Thank you for your questions. If you would like, you can try to test the = new implementation and give feedback. =E2=80=94=E2=80=94=E2=80=94 Vitaliy Gusev --Apple-Mail=_B2C31D91-4697-4C26-ADE9-9F456DBBFFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tomek,

Try to answer to the all questions below, = please let me know if I miss some = important.


On 23 May 2023, at 21:58, Tomek CEDRO = <tomek@cedro.info> wrote:

On Tue, May 23, 2023 at = 6:06=E2=80=AFPM Vitaliy Gusev wrote:
Hi,
Here is a proposal for bhyve snapshot/checkpoint = image format improvements.
It implies moving snapshot code to nvlist = engine.

Hey there Vitaliy :-) bhyve getting more and = more traction, I am new
user of bhyve and no expert, but new and = missing features are welcome
I guess.. there was a discussion on the = mailing lists recently on
better snapshots mechanism = :-)


Current snapshot implementation = has disadvantages:
3 files per snapshot: .meta, .kern, = vram

No problem, unless new single file will be = protected against
corruption (filesystem, transfer, application = crash) and possible to
be easily and cheaply modified in = place?

Current snapshot = implementation doesn=E2=80=99t have it. I would say more, = current
pkg implementation doesn=E2=80=99t track/notify if = some of files are changed.  Binary files on a
system can = be changed, for example ELF files, without any = notification.

Tar doesn=E2=80=99t have = protection for keeping data.  Some filesystems like = ZFS
guarantee that data is not modified by underlying = disks.

Protecting requires more efforts = and it should be clearly defined: what is purpose. If
purpose = is having checksum with 99.9% reliability, NVLIST HEADER can be = widen
to have =E2=80=9Cchecksum= =E2=80=9D key/value for a Section.

If = purpose is having crypto verification - I believe sha256 program = should be your = choice.


Binary Stream = format of data.

This is small and fast? Will new = format too?

Small is not so = perfect. As the first attempt snapshot code is good. But if you want to = get
values related to some specific device, for example, for = NIC or HPET, you cannot get it easily. Please
try = :)

Stream doesn=E2=80=99t have = flexibility. It is good for well specified  and long long time = discussed protocols
like XDR (NFS), when it has RFC and each = position in the stream is described. Example: = RFC1813.

New format with NVLIST has flexibility = and is fast enough. Note, ZFS uses nvlist for keeping = attributes 
and more another = things.


Adding  optional = variable - breaks resume
Removing variable - breaks = resume
Changing saved order of variables - breaks = resume

Obviously need improvement = :-)

Hard to get information about what = is saved and decode.
Hard to debug if somethings goes = wrong

Additional tools missing? Will new format = allow text editor = interaction?

Why do you need = modify snapshot image ? Could you describe more? Do you
modify = current 3 snapshot files?


No versions. If change = code, resume of an old images can be
passed, but with = UB.

Is new format future proof and provides backward = compatibility?

Intention of = moving to the new format - to have backward compatibility if some = code
is changed:
  • Adding optional = variable 
  • Removing variable that is not used = anymore
  • Change order of saving variables
  • =E2=80=9CHot = Fixes=E2=80=9D.

If = changes are critical and are incompatible, restore stage should have = clear information about
incompatibility and break resume. = Ideally it should be able to get informed even before = starting
restore process. For this purpose, the new format = introduce versions.



New nvlist = implementation should solve all things above. The first step = -
improve snapshot/checkpoint saving format. It eliminates three = files usage
per a snapshot.

(..)

So this = will be new text config based format with variable =3D value and = sections?

This is NVLIST = approach with key=3Dvalue, where key is string, and value can = be
Integer, array, string, etc.


How much bigger will be the overal file size = increase?

Not so huge. NVLIST = internals is well specified. For example, for my = VM

  [kernel]

    =     kernel.offset =3D 0x11f6 (4598)

        kernel.size =3D 0x19a7 = (6567)

        kernel.type =3D = =E2=80=9Cnvlist"

  [devices]

    =     devices.offset =3D 0x2b9d (11165)

        devices.size =3D = 0x10145ba (16860602)

        devices.type =3D = =E2=80=9Cnvlist=E2=80=9D


So packed size for = kernel  is 6567 = bytes, for devices  is 16860602 = including
framebuffer 16MB. If remove fbuf, packed nvlist = devices Section has size 83386 bytes.



How much longer it will = take do decode/encode/process = files?

It is fast, just = several milliseconds. NVLIST is very fast format. It is already = integrated
into bhyve as Config = engine.



What is the possibility of format change and = backward/foward = compatibility?

If you = are talking about compatibility of a Image format - it should be = compatible in
both directions, at least for not so big format = changes.

If consider overall = snapshot/resume compatibility - I believe  forward = compatibility
is not case and target. Indeed, why do you need =  to resume an image created by
a higher version of a = program? 

The most important thing - = backward compatibility, i.e. when an image is created
by an = older version of a program, but should be resumed on a new = one.

This is target and and intention of = this improvement.


Have you considered efficiency comparison of = current format, proposed
format, and maybe using SQLITE or JSON = storage/parsers?  For instance
sqlite would be blazingly fast = but hard to migrate. json would be most
versatile but more = time/memory = consuming?

Yes, I know = about another formats, like JSON or others. NVLIST is the = most
effective and suitable for the current = purposes.


Maybe EFL approach of storing configuration = files for limited
resources embedded system storage that use binary = storage data but can
be decompressed in chunks that can be replaced = in = place?
https://www.enlightenment.org/develop/efl/start
<= /blockquote>

There are many things that can be used, = but it should be well known, easy, stable,
fast and = supportable. I believe NVLIST is the best choice.


Sorry for asking those questions but there = may be already good and
verified solutions out there not to reinvent = the wheel? :-)

Thank you for = your questions. If you would like, you can try to test the new = implementation and give = feedback.

=E2=80=94=E2=80=94=E2=80=94
V= italiy Gusev

= --Apple-Mail=_B2C31D91-4697-4C26-ADE9-9F456DBBFFC5-- From nobody Wed May 24 17:33:48 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRJGB2MMVz4TJyg; Wed, 24 May 2023 17:34:26 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRJG946Pcz4FFD; Wed, 24 May 2023 17:34:25 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=IIFeit2R; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b2f as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-ba81deea9c2so1137434276.2; Wed, 24 May 2023 10:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684949664; x=1687541664; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=daVIsXoWCxfEdp0Yy3GFJd1A7zl9NWnIHW82T+Gn7hU=; b=IIFeit2Roa2ZjoByscqIlT4bIzJoSA8fkM4ggPvIFCXKEY8uFM2DpB7PgfOdLDUIPN fQyc6C6Eu1mYDHaQosld2Gm9nnWk2NxTM/eU2a4jS0g/GJbtX+8Rq028unIRSR+5kED3 ItBDZHazs0D3jGXb8Vp/XdlZ8XXWDvAtDiwBEOoCda5b5XVJe8VqFM3tOIjWkbq3IAGI B16Y5CyPtnhFBNexmW/bYFXLbj8tsKW7PInhsxy6u825tr0K9e8cE0Uxg5SXFBhXPB5m WCD+jwpkj9Pna8UW8IDL1W0iPvFJ3eRId3IwZHzQitogC7LQLBPJrw2JjbiNpucSELax tYdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684949664; x=1687541664; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=daVIsXoWCxfEdp0Yy3GFJd1A7zl9NWnIHW82T+Gn7hU=; b=XoMcSgRu7iRw67oJnUMTaLLfgnLmyog7RdzZbBSxxC+cfnyoqGJgSFlIOyROtGAx/G hkgO5iNwNJ8tOgGuj4KcWNzbBCaHWWJARb+7mT/y60NorykP4A2eWrwoBF7JwzPFIPP4 a1MLpm1lKqSS//35oIoqYTZoVRaCyy1INwKkNAudh77u18k1LnCZEDRrDWGVG0oSYoIL dQejlyn2CRHtQPO2Bb9ClTiMF8/9Akarc3fzTYs8uEz8GLfzHmT4Jo3f567X9EiFQcfO OVk7RABW0BdbGfQ8bJgaXOck4mKWVT79eYTtvCFQFAAUT5ge/Jb4l3ZU9mjFrr+XKZtq H1Aw== X-Gm-Message-State: AC+VfDyJ0fRMLgjJm1N2HSWHfteg2WR+TTJoa3PMafvi/J/VDgbE3jup UwY3etnadc+ivOW7LycAFTDQcOao1PemI0ucDyGMHVf4GlI= X-Google-Smtp-Source: ACHHUZ6HWOttZ4LOsdCm4nxrJ/jdkpiVh2dlOq9tibJEWmGZbAAWsFlg7xmregcGiSCTYsSXc2WxSp2ikFTLq56R0UY= X-Received: by 2002:a25:bc9:0:b0:bac:6114:7376 with SMTP id 192-20020a250bc9000000b00bac61147376mr636720ybl.15.1684949664566; Wed, 24 May 2023 10:34:24 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> In-Reply-To: From: Mario Marietto Date: Wed, 24 May 2023 19:33:48 +0200 Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000038930005fc73ea5e" X-Spamd-Result: default: False [-2.44 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.935]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[virtualization@freebsd.org,freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2f:from]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4QRJG946Pcz4FFD X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000038930005fc73ea5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @gusev.vitaliy@gmail.com : Do you want to explain to me how to test the new "snapshot" feature ? I'm interested to test and stress it on my system. Is it ready to be used ? On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: > Hi Tomek, > > Try to answer to the all questions below, please let me know if I miss > some important. > > > On 23 May 2023, at 21:58, Tomek CEDRO wrote: > > On Tue, May 23, 2023 at 6:06=E2=80=AFPM Vitaliy Gusev wrote: > > Hi, > Here is a proposal for bhyve snapshot/checkpoint image format improvement= s. > It implies moving snapshot code to nvlist engine. > > > Hey there Vitaliy :-) bhyve getting more and more traction, I am new > user of bhyve and no expert, but new and missing features are welcome > I guess.. there was a discussion on the mailing lists recently on > better snapshots mechanism :-) > > > Current snapshot implementation has disadvantages: > 3 files per snapshot: .meta, .kern, vram > > > No problem, unless new single file will be protected against > corruption (filesystem, transfer, application crash) and possible to > be easily and cheaply modified in place? > > > Current snapshot implementation doesn=E2=80=99t have it. I would say more= , current > pkg implementation doesn=E2=80=99t track/notify if some of files are chan= ged. > Binary files on a > system can be changed, for example ELF files, without any notification. > > Tar doesn=E2=80=99t have protection for keeping data. Some filesystems l= ike ZFS > guarantee that data is not modified by underlying disks. > > Protecting requires more efforts and it should be clearly defined: what i= s > purpose. If > purpose is having checksum with 99.9% reliability, NVLIST HEADER can be > widen > to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. > > If purpose is having crypto verification - I believe sha256 program shoul= d > be your choice. > > > Binary Stream format of data. > > > This is small and fast? Will new format too? > > > Small is not so perfect. As the first attempt snapshot code is good. But > if you want to get > values related to some specific device, for example, for NIC or HPET, you > cannot get it easily. Please > try :) > > Stream doesn=E2=80=99t have flexibility. It is good for well specified a= nd long > long time discussed protocols > like XDR (NFS), when it has RFC and each position in the stream is > described. Example: RFC1813. > > New format with NVLIST has flexibility and is fast enough. Note, ZFS uses > nvlist for keeping attributes > and more another things. > > > Adding optional variable - breaks resume > Removing variable - breaks resume > Changing saved order of variables - breaks resume > > > Obviously need improvement :-) > > Hard to get information about what is saved and decode. > Hard to debug if somethings goes wrong > > > Additional tools missing? Will new format allow text editor interaction? > > > Why do you need modify snapshot image ? Could you describe more? Do you > modify current 3 snapshot files? > > > No versions. If change code, resume of an old images can be > passed, but with UB. > > > Is new format future proof and provides backward compatibility? > > > Intention of moving to the new format - to have backward compatibility if > some code > is changed: > > > - Adding optional variable > - Removing variable that is not used anymore > - Change order of saving variables > - =E2=80=9CHot Fixes=E2=80=9D. > > > If changes are critical and are incompatible, restore stage should have > clear information about > incompatibility and break resume. Ideally it should be able to get > informed even before starting > restore process. For this purpose, the new format introduce versions. > > > > New nvlist implementation should solve all things above. The first step - > improve snapshot/checkpoint saving format. It eliminates three files usag= e > per a snapshot. > > (..) > > > So this will be new text config based format with variable =3D value and > sections? > > > This is NVLIST approach with key=3Dvalue, where key is string, and value = can > be > Integer, array, string, etc. > > > How much bigger will be the overal file size increase? > > > Not so huge. NVLIST internals is well specified. For example, for my VM > > [kernel] > > kernel.offset =3D 0x11f6 (4598) > > kernel.size =3D 0x19a7 (6567) > > kernel.type =3D =E2=80=9Cnvlist" > > [devices] > > devices.offset =3D 0x2b9d (11165) > > devices.size =3D 0x10145ba (16860602) > > devices.type =3D =E2=80=9Cnvlist=E2=80=9D > > So packed size for *kernel* is 6567 bytes, for *devices* is 16860602 > including > framebuffer 16MB. If remove fbuf, packed nvlist devices Section has size > 83386 bytes. > > > > How much longer it will take do decode/encode/process files? > > > It is fast, just several milliseconds. NVLIST is very fast format. It is > already integrated > into bhyve as Config engine. > > > > What is the possibility of format change and backward/foward compatibilit= y? > > > If you are talking about compatibility of a Image format - it should be > compatible in > both directions, at least for not so big format changes. > > If consider overall snapshot/resume compatibility - I believe forward > compatibility > is not case and target. Indeed, why do you need to resume an image > created by > a higher version of a program? > > The most important thing - backward compatibility, i.e. when an image is > created > by an older version of a program, but should be resumed on a new one. > > This is target and and intention of this improvement. > > > Have you considered efficiency comparison of current format, proposed > format, and maybe using SQLITE or JSON storage/parsers? For instance > sqlite would be blazingly fast but hard to migrate. json would be most > versatile but more time/memory consuming? > > > Yes, I know about another formats, like JSON or others. NVLIST is the mos= t > effective and suitable for the current purposes. > > > Maybe EFL approach of storing configuration files for limited > resources embedded system storage that use binary storage data but can > be decompressed in chunks that can be replaced in place? > https://www.enlightenment.org/develop/efl/start > > > There are many things that can be used, but it should be well known, easy= , > stable, > fast and supportable. I believe NVLIST is the best choice. > > > Sorry for asking those questions but there may be already good and > verified solutions out there not to reinvent the wheel? :-) > > > Thank you for your questions. If you would like, you can try to test the > new implementation and give feedback. > > =E2=80=94=E2=80=94=E2=80=94 > Vitaliy Gusev > > --=20 Mario. --00000000000038930005fc73ea5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@gusev.vitaliy@gmail= .com : Do you want to explain to me how to test the new "snapshot&= quot; feature ? I'm interested to test and stress it on my system. Is i= t ready to be used ?

On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy G= usev <gusev= .vitaliy@gmail.com> wrote:
Hi Tomek,

Try to answer to the al= l questions below, please let me know if I miss some important.
<= br>

On 23 May 2023, at 21= :58, Tomek CEDRO <= tomek@cedro.info> wrote:

On Tue, May 23, 2023 at = 6:06=E2=80=AFPM Vitaliy Gusev wrote:
Hi,
He= re is a proposal for bhyve snapshot/checkpoint image format improvements.It implies moving snapshot code to nvlist engine.

Hey= there Vitaliy :-) bhyve getting more and more traction, I am new
user o= f bhyve and no expert, but new and missing features are welcome
I guess.= . there was a discussion on the mailing lists recently on
better snapsho= ts mechanism :-)


Current snapshot impl= ementation has disadvantages:
3 files per snapshot: .meta, .kern, vram

No problem, unless new single file will be protected aga= inst
corruption (filesystem, transfer, application crash) and possible t= o
be easily and cheaply modified in place?
<= div>
Current snapshot implementation doesn=E2=80=99t have it.= I would say more, current
pkg implementation doesn=E2=80=99t tra= ck/notify if some of files are changed.=C2=A0 Binary files on a
s= ystem can be changed, for example ELF files, without any notification.

Tar doesn=E2=80=99t have protection for keeping d= ata.=C2=A0 Some filesystems like ZFS
guarantee that data is not m= odified by underlying disks.

Protecting requ= ires more efforts and it should be clearly defined: what is purpose. If
purpose is having checksum with 99.9%=C2=A0reliability, NVLIST HEADER can be widen=
to have =E2=80=9Cchecksum=E2=80=9D key/value for a Sectio= n.

If purpose=C2=A0is having crypto = verification - I believe sha256 program should be your choice.


Binary Stream format of data.

This = is small and fast? Will new format too?
Small is not so perfect. As the first attempt snapshot code is good= . But if you want to get
values related to some specific device, = for example, for NIC or HPET, you cannot get it easily. Please
tr= y :)

Stream doesn=E2=80=99t have flexibility.= It is good for well specified =C2=A0and long long time discussed protocols=
like XDR (NFS), when it has RFC and each position in the stream = is described. Example: RFC1813.

New format with NV= LIST has flexibility and is fast enough. Note, ZFS uses nvlist for keeping = attributes=C2=A0
and more another things.


A= dding =C2=A0optional variable - breaks resume
Removing variable - breaks= resume
Changing saved order of variables - breaks resume

Obviously need improvement :-)

Hard = to get information about what is saved and decode.
Hard to debug if some= things goes wrong

Additional tools missing? Will new fo= rmat allow text editor interaction?

Why do you need modify snapshot image ? Could you describe more? Do you=
modify current 3 snapshot files?


No versions. If change cod= e, resume of an old images can be
passed, but with UB.
<= br>Is new format future proof and provides backward compatibility?

Intention of moving to the new format - = to have backward compatibility if some code
is changed:
  • Adding optional variable=C2=A0
  • Removing variable t= hat is not used anymore
  • Change order of saving variables
  • = =E2=80=9CHot Fixes=E2=80=9D.

If changes are critical and are incompatible, restore stage should h= ave clear information about
incompatibility and break resume. Ide= ally it should be able to get informed even before starting
resto= re process. For this purpose, the new format introduce versions.
=



New nvlist implementation should solve all things above. The firs= t step -
improve snapshot/checkpoint saving format. It eliminates three = files usage
per a snapshot.

(..)

So this will= be new text config based format with variable =3D value and sections?
<= /div>

This is NVLIST approach with key=3Dv= alue, where key is string, and value can be
Integer, array, strin= g, etc.


How much bigg= er will be the overal file size increase?
=
Not so huge. NVLIST internals is well specified. For example, for= my VM

=C2=A0 [kernel]

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 kernel.offset =3D 0x11f6 (4598)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 kernel.size= =3D 0x19a7 (6567)

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 kernel.type =3D =E2=80=9Cnvlist"

=C2=A0 [devices]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 device= s.offset =3D 0x2b9d (11165)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 devices.size =3D 0x10145ba (16860602)

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 devices.type =3D =E2=80=9Cnvlist=E2=80=9D


S= o packed size for kernel=C2=A0 is 65= 67 bytes, for devices=C2=A0 is=C2=A016860602 including
frameb= uffer 16MB. If remove fbuf, packed nvlist devices Section has size=C2=A083386=C2=A0by= tes.



How much longer it will take do decode/encode/process files?
<= /div>

It is fast, just several millis= econds. NVLIST is very fast format. It is already integrated
into= bhyve as Config engine.


=

What is the possibility of format change and backward/foward = compatibility?

If you are t= alking about compatibility of a Image format - it should be compatible in
both directions, at least for not so big format changes.

If consider overall snapshot/resume compatibility - I = believe =C2=A0forward compatibility
is not case and target. Indee= d, why do you need =C2=A0to resume an image created by
a higher v= ersion of a program?=C2=A0

The most important thin= g - backward compatibility, i.e. when an image is created
by an o= lder version of a program, but should be resumed on a new one.
<= div>
This is target and and intention of this improvement.


Have you consider= ed efficiency comparison of current format, proposed
format, and maybe u= sing SQLITE or JSON storage/parsers?=C2=A0 For instance
sqlite would be = blazingly fast but hard to migrate. json would be most
versatile but mor= e time/memory consuming?

Ye= s, I know about another formats, like JSON or others. NVLIST is the most
effective and suitable for the current purposes.


Maybe EFL approach of storing con= figuration files for limited
resources embedded system storage that use = binary storage data but can
be decompressed in chunks that can be replac= ed in place?
https://www.enlightenment.org/develop/efl/start
<= /div>

There are many things that can = be used, but it should be well known, easy, stable,
fast and supp= ortable. I believe NVLIST is the best choice.


Sorry for asking those questions but there may be alrea= dy good and
verified solutions out there not to reinvent the wheel? :-)<= br>

Thank you for your questions. If= you would like, you can try to test the new implementation and give feedba= ck.

=E2=80=94=E2=80=94=E2=80=94
Vitaliy = Gusev


=
--
Mario.
--00000000000038930005fc73ea5e-- From nobody Wed May 24 17:38:50 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRJMW2zcjz4TK3W; Wed, 24 May 2023 17:39:03 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRJMW1228z4Gfn; Wed, 24 May 2023 17:39:03 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4eed764a10cso1250619e87.0; Wed, 24 May 2023 10:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684949941; x=1687541941; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=eGFUaUP6pqdLyTrDBgb8y5Us42JMSTCQV6+Q03LsqPA=; b=C7PXn+PUZcLBLQV6UOn51DKvrbgJnaUeK5LBmqS6J1WMa/0HE0wMb7ojFZwI2ghenB h1DPrDlVLHkAQPk/Ru6Dvllc0duQaSukQizsmIz/ok43PLVypbpctCGfvjOLOFN6VgfQ Aj8Q/mGuSickPPMMcPfum8SOLSoCtjlbObA5hwkGTK22uDMEZ0PZ1NvA1mCKIDynpzL0 dqhpyHCuuiqzkNFFJ9g3hbE9ufkAEvGsC+wXj/zk4HeT472KP6ztRhmabwzZ2uR/Ele5 Lvc96/mWdG472/QOF+oFGNQPXVaQzCP0ObViNQZxht27eSzU/Vl13Eu6UtfZD6AV3Qr2 1Cnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684949941; x=1687541941; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eGFUaUP6pqdLyTrDBgb8y5Us42JMSTCQV6+Q03LsqPA=; b=g0YqJBSDzZczaMsKOs/akEmIw+wM7rIaL1Fj2tV/8hSa2P3UzFD1vAJg4iFATY3lQa Lgn74DNoM65zSbXmqegYmdvSyKvhyRugPjVVIv97Fmmdx9oHdJNCJQzmBJEFndBXcSnS 0iM0VXXPPW7DIMV+eBKKFnSU3zjzX/Dtg+UfEUJvjDnGZuCjrUh1rAIfthVx4wH+OBLC vEunCEm9BF18PUt4OcFWrNhuZ1AHoHloO3YeJ2h1Daf+FDd4fA+YGw5i2ly0vljNf5dz R5qJdoPLeIiquOAhz77rtbZugGA1WZKRYp53bhLAMJza3LjnrSg39bBcshqdrcR2qYdK c7Rg== X-Gm-Message-State: AC+VfDz9dAb9tkwDsYuYstBcDNtkImw1dvy8Y19KIVk2O8Yq+wZDPwi1 0Sb9wQBm2jsqDlwCLOpokMmgHFgeltQ= X-Google-Smtp-Source: ACHHUZ4SCY+shpDGBTbmFSKpPC5OSpC7Kpomskqz1p80uGYgtQOUGNFSyVwY81KJbTOKPHmuzEgQgg== X-Received: by 2002:ac2:5544:0:b0:4f3:8260:f18c with SMTP id l4-20020ac25544000000b004f38260f18cmr5396965lfk.57.1684949941218; Wed, 24 May 2023 10:39:01 -0700 (PDT) Received: from smtpclient.apple ([188.187.60.230]) by smtp.gmail.com with ESMTPSA id b1-20020a056512024100b004b4cbc942a3sm1811551lfo.127.2023.05.24.10.39.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2023 10:39:00 -0700 (PDT) From: Vitaliy Gusev Message-Id: <3054B6FB-8408-492C-9F18-91A61516D0EF@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3D732BA7-A8EF-4056-A822-0ECD52A24FF2" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Wed, 24 May 2023 20:38:50 +0300 In-Reply-To: Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers@freebsd.org To: Mario Marietto References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRJMW1228z4Gfn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3D732BA7-A8EF-4056-A822-0ECD52A24FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is ready but in internal git repo, and it needs time to port it to = CURRENT version. Probably week or so. When I create review, I will notify you. Thanks, Vitaliy Gusev > On 24 May 2023, at 20:33, Mario Marietto = wrote: >=20 > @gusev.vitaliy@gmail.com : Do you = want to explain to me how to test the new "snapshot" feature ? I'm = interested to test and stress it on my system. Is it ready to be used ? >=20 >>=20 >> Thank you for your questions. If you would like, you can try to test = the new implementation and give feedback. >>=20 >> =E2=80=94=E2=80=94=E2=80=94 >> Vitaliy Gusev >>=20 >=20 >=20 > --=20 > Mario. --Apple-Mail=_3D732BA7-A8EF-4056-A822-0ECD52A24FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It is ready = but in internal git repo, and it needs time to port it to CURRENT = version. Probably week or so.

When I create review, I = will notify you.

Thanks,
Vitaliy = Gusev


On 24 May = 2023, at 20:33, Mario Marietto <marietto2008@gmail.com> = wrote:

@gusev.vitaliy@gmail.com : Do you want to explain to = me how to test the new "snapshot" feature ? I'm interested to test and = stress it on my system. Is it ready to be used ?


Thank you for your = questions. If you would like, you can try to test the new implementation = and give feedback.

=E2=80=94=E2=80=94=E2=80=94
Vitaliy Gusev



--
Mario.

= --Apple-Mail=_3D732BA7-A8EF-4056-A822-0ECD52A24FF2-- From nobody Wed May 24 17:46:13 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRJWv1YhBz4TKTY; Wed, 24 May 2023 17:46:19 +0000 (UTC) (envelope-from SRS0=9ZGR=BN=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRJWt0Qsbz4JF1; Wed, 24 May 2023 17:46:18 +0000 (UTC) (envelope-from SRS0=9ZGR=BN=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of "SRS0=9ZGR=BN=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=9ZGR=BN=quip.cz=000.fbsd@elsa.codelab.cz"; dmarc=none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id AD7E0D7899; Wed, 24 May 2023 19:46:14 +0200 (CEST) Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id E2D06D7891; Wed, 24 May 2023 19:46:13 +0200 (CEST) Message-ID: Date: Wed, 24 May 2023 19:46:13 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: BHYVE SNAPSHOT image format proposal Content-Language: cs-Cestina To: Vitaliy Gusev Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.79 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=9ZGR=BN=quip.cz=000.fbsd@elsa.codelab.cz]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,virtualization@freebsd.org]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=9ZGR=BN=quip.cz=000.fbsd@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[quip.cz]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QRJWt0Qsbz4JF1 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On 24/05/2023 17:10, Vitaliy Gusev wrote: >>> Current snapshot implementation has disadvantages: >>> 3 files per snapshot: .meta, .kern, vram >> >> No problem, unless new single file will be protected against >> corruption (filesystem, transfer, application crash) and possible to >> be easily and cheaply modified in place? > > Current snapshot implementation doesn’t have it. I would say more, current > pkg implementation doesn’t track/notify if some of files are changed. >  Binary files on a > system can be changed, for example ELF files, without any notification. pkg stores checksums for installed files. You can check them with pkg check -s -a or pkg check --checksums -a. Changes are reported by daily periodic script. Kind regards Miroslav Lachman From nobody Wed May 24 17:47:42 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRJYm3jtWz4TKYD; Wed, 24 May 2023 17:47:56 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRJYl1kLpz4KKK; Wed, 24 May 2023 17:47:55 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=m5SEENiR; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-ba1815e12efso1127614276.3; Wed, 24 May 2023 10:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684950474; x=1687542474; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JchYAiXV43rmVn9K0gGeJrAwEh7reGDM2znr87FB/Pk=; b=m5SEENiRKE6l5SqKSfONZ+VrXE0su4MCFGrF2enh0+qp+YPY83f45ihL308tcy8MjX Zf3kuOrMeNOnBD34+u8RoejiBkFcIst57cYrv/6ZZFDHxvX7s0PYCf9BiXSK8xl76F8R px102xCNF+Zd+PZLUUtVzqQ6GHxw0ukRqKzUANZVov++qe6sRiZAKXNiadkNY6bVeNgO +vxd6YVm3dP1Vjy50m9f/+cSNoVLa9RcsLIpWnRl5KiOZRhcENQ98vXEPcDwUhkMbUAP bfdD6YPueqSOAcpOgroG4NtrxhaSqfsRRppNZDVZT5pr2WstnYTRmpBYoiIbU09t32KP S+gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684950474; x=1687542474; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JchYAiXV43rmVn9K0gGeJrAwEh7reGDM2znr87FB/Pk=; b=L+Pj51pUKvx046+hhD7BbZ0dLG2RcEauRhp29suKYKaJ9FLNQSpH38urQT2fhsuSAN cechAiHd935jZHrGqd+ll5aXndAW3D1RzmDlxour2ZHPC8A02tEBHnK/4J2LPOP7duEB kh4mMnZonmLLtHBgQipyVc+W1QcA9aqtKgg2BG1ZBR0TRIl65hWXAuZS6uHhxHx5pk73 aOzQrR2F2tTnR5KcaaSkyko4we9yUOMHEfl6erDbMMAU0IRCDqU0Obp3CxRclhUR/ZUA 3D7VjGqUX5PwvXBlp4PEJamvBXjW3FEZGpmBaKgTqDf+iscWVy7f0Ungywdv/uPmw0Cb fw2g== X-Gm-Message-State: AC+VfDxjXVj9cssxcwy7R2oUbDiBhVkFUivfU/dASgvwCygwW87AWnRx 1akEuo6w8OoTiNKwQDjulalVl0ms3POzuax4SOo= X-Google-Smtp-Source: ACHHUZ4+6neEUWFW3hFExorhD9Pj2IVcebu/TRpwTk4PYIRV7R/wVe91Nlf7sXR9tEJ13wzy+aVtv2eRJQS9E96fEdI= X-Received: by 2002:a25:aa2b:0:b0:bac:6d5a:f6af with SMTP id s40-20020a25aa2b000000b00bac6d5af6afmr695372ybi.35.1684950474289; Wed, 24 May 2023 10:47:54 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <3054B6FB-8408-492C-9F18-91A61516D0EF@gmail.com> In-Reply-To: <3054B6FB-8408-492C-9F18-91A61516D0EF@gmail.com> From: Mario Marietto Date: Wed, 24 May 2023 19:47:42 +0200 Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000007bf70505fc741ae9" X-Spamd-Result: default: False [-2.44 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[virtualization@freebsd.org,freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b34:from]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4QRJYl1kLpz4KKK X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000007bf70505fc741ae9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Give me the internal git. I want to test it asap :) Il mer 24 mag 2023, 19:39 Vitaliy Gusev ha scritto: > It is ready but in internal git repo, and it needs time to port it to > CURRENT version. Probably week or so. > > When I create review, I will notify you. > > Thanks, > Vitaliy Gusev > > > On 24 May 2023, at 20:33, Mario Marietto wrote: > > @gusev.vitaliy@gmail.com : Do you want to > explain to me how to test the new "snapshot" feature ? I'm interested to > test and stress it on my system. Is it ready to be used ? > > >> Thank you for your questions. If you would like, you can try to test the >> new implementation and give feedback. >> >> =E2=80=94=E2=80=94=E2=80=94 >> Vitaliy Gusev >> >> > > -- > Mario. > > > --0000000000007bf70505fc741ae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Give me the internal git. I want to test it asap :)
=
Il mer= 24 mag 2023, 19:39 Vitaliy Gusev <gusev.vitaliy@gmail.com> ha scritto:
It is ready but = in internal git repo, and it needs time to port it to CURRENT version. Prob= ably week or so.

When I create review, I will notify you= .

Thanks,
Vitaliy Gusev


On 24 May 2023, at 20:33, Mario Marie= tto <marietto2008@gmail.com> wrote:

@gusev.vitaliy@gmail.com : Do you want to explain to me how= to test the new "snapshot" feature ? I'm interested to test = and stress it on my system. Is it ready to be used ?

=
Thank you for your questions. If you would like, you can try to test th= e new implementation and give feedback.

=E2=80=94= =E2=80=94=E2=80=94
Vitaliy Gusev



--
Mario.

--0000000000007bf70505fc741ae9-- From nobody Wed May 24 18:16:27 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRKBw2ymtz4TLxq; Wed, 24 May 2023 18:16:40 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRKBw0xLyz4MkC; Wed, 24 May 2023 18:16:40 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-4f3b337e842so1278211e87.3; Wed, 24 May 2023 11:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684952198; x=1687544198; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=c97IKDb8B7IJ+wq3pHrDHqdGy0JjQu5fvMbgBY5XtaI=; b=k7/X4IUHNBSQqWTA6u73OAQKngCrTtF51iJpVh1gkeYu8XpUw5EPBBAX0Sc8HoXaAl cqLsbGCeXvgDiiWIlkp7pMEa92awqngyLqeZDOjXyaVbgKLZlzz0ecb8ITcO1xmtvWSW C6qHk44wrvFyXGtOPw7ZUdyYRT6sB2rWbi+QjZwVKRmw7jTTTGhFiYfdF1QEYy2JgJTQ ntLPoILxcJbXxq9JCSU2k4hCdMNaa+uM9wb6VuqGTrDqUYoIeVmIxkDFBwaEWo26SlHp v0222ZJ0FuUQ/tGJxDNffWto9Qyx8ox1KO0mEyldHj3BNv2Ry1Z/yQ1s6Pyxb472t0Vk ab/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684952198; x=1687544198; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c97IKDb8B7IJ+wq3pHrDHqdGy0JjQu5fvMbgBY5XtaI=; b=YoBtffFHx3lb6VMSmEnD0IvewCqMU+kbQQ/9W3jK/Ge6gppxfVtJvv6LMgsV2IzWD9 F5SnS730FH7KLxCUxEYlS4O20IyYyppmQU6VleEeEmawqM0fqeLdVXy+BRehqfsDQOTQ FlVJEA+jH74nsueR8O+qTQ2Ppzz+t90jeMft0LQg9mu3NqlLx0ERoLUXldoTak1PTDO7 TOh96hdvL7gQ8zYcWk2ro27A/b3XGT25KZ7wFMgZentS9BmY0ovsGQThWVzX33yNME// KH2CNgWBZNkgjdiFnHvOTht+URg2oftFp6ZP0hKfGpiniBBHt+L3hoGMPLaRRvoAP8l9 uiAA== X-Gm-Message-State: AC+VfDzxXGn9rB2mGcOu+rmIjajxVvVn8xT9cxjUB/eJEYsV/4oUWd9E FBzM7QOt5trCx9+yhRT+s/U= X-Google-Smtp-Source: ACHHUZ7Bj4CXEDY6e7q6r7inG7OG1Y5EHg0SzQRw/F/OUXrsXBjbZkkSpQT3Ji8hu8KV+IcAlOUDxw== X-Received: by 2002:ac2:5298:0:b0:4ef:f725:ae2f with SMTP id q24-20020ac25298000000b004eff725ae2fmr5625196lfm.37.1684952198299; Wed, 24 May 2023 11:16:38 -0700 (PDT) Received: from smtpclient.apple ([188.187.60.230]) by smtp.gmail.com with ESMTPSA id u22-20020ac243d6000000b004f021ce4c68sm1815719lfl.80.2023.05.24.11.16.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2023 11:16:37 -0700 (PDT) From: Vitaliy Gusev Message-Id: <91DBA80E-C6DD-4394-B69B-3B6BB63BE726@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5729E1B5-200B-4960-B4A9-D1B168D9AB80" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Wed, 24 May 2023 21:16:27 +0300 In-Reply-To: Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org To: Miroslav Lachman <000.fbsd@quip.cz> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRKBw0xLyz4MkC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_5729E1B5-200B-4960-B4A9-D1B168D9AB80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 > On 24 May 2023, at 20:46, Miroslav Lachman <000.fbsd@quip.cz> wrote: >=20 > On 24/05/2023 17:10, Vitaliy Gusev wrote: >=20 >>>> Current snapshot implementation has disadvantages: >>>> 3 files per snapshot: .meta, .kern, vram >>>=20 >>> No problem, unless new single file will be protected against >>> corruption (filesystem, transfer, application crash) and possible to >>> be easily and cheaply modified in place? >> Current snapshot implementation doesn=E2=80=99t have it. I would say = more, current >> pkg implementation doesn=E2=80=99t track/notify if some of files are = changed. Binary files on a >> system can be changed, for example ELF files, without any = notification. >=20 > pkg stores checksums for installed files. You can check them with pkg = check -s -a or pkg check --checksums -a. Changes are reported by daily = periodic script. Yep, my fault. However, I found it doesn=E2=80=99t track sticky bit = setting: # chmod u+t /usr/local/bin/vim # pkg check -s vim Checking vim: 100% My point was that if snapshot image needs checksum verification it could = be done by another program, because there are many purposes (plain integrity, security, etc) and = having it in place in snapshot image could be doing double of work. And additionally note, that NVLIST Header can be widen to have a = checksum for Section data. Thanks, Vitaliy Gusev > Kind regards > Miroslav Lachman >=20 --Apple-Mail=_5729E1B5-200B-4960-B4A9-D1B168D9AB80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, 

On 24 May 2023, at 20:46, Miroslav Lachman = <000.fbsd@quip.cz> wrote:

On 24/05/2023 17:10, = Vitaliy Gusev wrote:

Current snapshot implementation = has disadvantages:
3 files per snapshot: .meta, .kern, = vram

No problem, unless new single file will be = protected against
corruption (filesystem, transfer, application = crash) and possible to
be easily and cheaply modified in = place?
Current snapshot implementation doesn=E2=80=99t = have it. I would say more, current
pkg implementation doesn=E2=80=99t = track/notify if some of files are changed.   Binary files on = a
system can be changed, for example ELF files, without any = notification.

pkg stores checksums for installed = files. You can check them with pkg check -s -a or pkg check --checksums = -a. Changes are reported by daily periodic = script.


Yep, = my fault. However, I found it doesn=E2=80=99t track sticky bit = setting:

# = chmod u+t /usr/local/bin/vim


# pkg = check -s vim

Checking vim: = 100%


My point was that if snapshot = image needs checksum verification it could be done by another = program,
because there are many purposes (plain integrity, = security, etc) and having it in place in snapshot image
could = be doing double of work.

And additionally note, = that NVLIST Header can be widen to have a  checksum for Section = data.

Thanks,
Vitaliy = Gusev

Kind regards
Miroslav = Lachman


= --Apple-Mail=_5729E1B5-200B-4960-B4A9-D1B168D9AB80-- From nobody Wed May 24 18:44:34 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRKqL6pp5z4TNQD; Wed, 24 May 2023 18:44:46 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRKqL6FvXz4Sgr; Wed, 24 May 2023 18:44:46 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4effb818c37so1327398e87.3; Wed, 24 May 2023 11:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684953885; x=1687545885; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=BhglgsPDhDMkvFy5HHyCJo+/I/zn6luCz3jk0H2OX74=; b=df9l9dGWf2SXuMSJ1dcoRBqHsoWepdV3Ag56M8bijLmpTp7CkvHOqLyxuXz3omEE4r RTokLlsiOtCiROS5RjlTGJywj0efHXpoeq/Be++hSLgTl8W6otVmSt6ZYLWJY2PVds7h vLGcw5wXV0pSEHHeut6ZNwYyqzidnHiT3eCf6hoy+ZtD3+ykTCfNrw5efuIjSI1+X+5D i93D7q87D2Itn/1W9zflbA3n6Kk29kgVXP6cptPTl2gyDsns1Pq/2rJp/6EI5q5fnmzK Aifqs6iEMolCJbLeIkm5DNy30jHUQQ2ppXVIiAErtwA6M+I/LPP81A1NQF9S7LAbpNKm 5qXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684953885; x=1687545885; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BhglgsPDhDMkvFy5HHyCJo+/I/zn6luCz3jk0H2OX74=; b=BDOPH8Yt5Lh811u6K3nZMxlfPjD6x2lWTR5EgObahlNaRuujSJfyKuDm/hDqOyNHSm cOjh/deB+Cjl9bBXsyZEKjRCM/vgW0fqOl7jQR+dXMJ30T2lq2qiLe2EcEfEs+wr3YW9 jPkQuPPJ115uO5hwJYOt3ftsDJ9720I+qtmk5AhWYe0zOKrUgL1tqXvOobFSlZFesL+6 r+nKHRFaiunsKPgyaNz/e7aeEaJMSUDl+kEBpwU89YX2xGeAbcuguBKockk1Py7COUM4 GvGmSYjyJgyoHalc2BXNl7rZp+7De4zJUCsSs4qvd6scVFwHBranocGfI0JvxQgnOWYr rC7w== X-Gm-Message-State: AC+VfDxjDFzywO9RZ+2YvNODksBSyqTC7GHLIic2YgkUiHzHk6nIoD2i G+wXtILYTokQElFWA0mKLgg= X-Google-Smtp-Source: ACHHUZ6oEQDl8OReKOmfoTcDPTo25UwtFVLPGozXlG+B8hlA/DtCx1NZNGBZAwMdtcJP7TmjyRvJQA== X-Received: by 2002:ac2:5217:0:b0:4f1:2f5d:8679 with SMTP id a23-20020ac25217000000b004f12f5d8679mr5691286lfl.22.1684953884961; Wed, 24 May 2023 11:44:44 -0700 (PDT) Received: from smtpclient.apple ([188.187.60.230]) by smtp.gmail.com with ESMTPSA id v3-20020ac25603000000b004f387d97dafsm1814640lfd.147.2023.05.24.11.44.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2023 11:44:44 -0700 (PDT) From: Vitaliy Gusev Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9FA25D1E-D3F5-4B0F-A1FC-15622586B073" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Wed, 24 May 2023 21:44:34 +0300 In-Reply-To: Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers To: Mario Marietto References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <3054B6FB-8408-492C-9F18-91A61516D0EF@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRKqL6FvXz4Sgr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9FA25D1E-D3F5-4B0F-A1FC-15622586B073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is impossible. However, as first attempt you can verify that multidev = branch works fine for you. https://github.com/gusev-vitaliy/freebsd/tree/dev/D35590 =E2=80=94=E2=80=94 Vitaliy Gusev > On 24 May 2023, at 20:47, Mario Marietto = wrote: >=20 > Give me the internal git. I want to test it asap :) >=20 > Il mer 24 mag 2023, 19:39 Vitaliy Gusev > ha scritto: >> It is ready but in internal git repo, and it needs time to port it to = CURRENT version. Probably week or so. >>=20 >> When I create review, I will notify you. >>=20 >> Thanks, >> Vitaliy Gusev >>=20 >>=20 >>> On 24 May 2023, at 20:33, Mario Marietto > wrote: >>>=20 >>> @gusev.vitaliy@gmail.com : Do you = want to explain to me how to test the new "snapshot" feature ? I'm = interested to test and stress it on my system. Is it ready to be used ? >>>=20 >>>>=20 >>>> Thank you for your questions. If you would like, you can try to = test the new implementation and give feedback. >>>>=20 >>>> =E2=80=94=E2=80=94=E2=80=94 >>>> Vitaliy Gusev >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Mario. >>=20 --Apple-Mail=_9FA25D1E-D3F5-4B0F-A1FC-15622586B073 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It is = impossible. However, as first attempt you can verify that multidev = branch works fine for you.


=E2=80=94=E2=80=94
Vitali= y Gusev

On 24 May 2023, at = 20:47, Mario Marietto <marietto2008@gmail.com> wrote:

Give me the = internal git. I want to test it asap :)

Il mer 24 = mag 2023, 19:39 Vitaliy Gusev <gusev.vitaliy@gmail.com> = ha scritto:
It is ready but in internal git = repo, and it needs time to port it to CURRENT version. Probably week or = so.

When I create review, I will notify = you.

Thanks,
Vitaliy = Gusev


On 24 May = 2023, at 20:33, Mario Marietto <marietto2008@gmail.com> = wrote:

@gusev.vitaliy@gmail.com : Do you want to explain = to me how to test the new "snapshot" feature ? I'm interested to test = and stress it on my system. Is it ready to be used ?


Thank you for your = questions. If you would like, you can try to test the new implementation = and give feedback.

=E2=80=94=E2=80=94=E2=80=94
Vitaliy Gusev



--
Mario.


= --Apple-Mail=_9FA25D1E-D3F5-4B0F-A1FC-15622586B073-- From nobody Thu May 25 00:57:39 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRV4j1MKFz4CPXP for ; Thu, 25 May 2023 00:56:53 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRV4j0qKdz3p67 for ; Thu, 25 May 2023 00:56:53 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-3f6c2f2de19so3674071cf.0 for ; Wed, 24 May 2023 17:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684976212; x=1687568212; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=qNV3j8Xshj37jqXvnC/RqnvWSvgnyWGwTFZ6aQsejAM=; b=fZqFYnkyeg95Me3mYDxM3Y2a7Cv4weixdVAomeS5guT9ukO1hxkD9oGqCz0IEM1Tvl DIc6UZ5NA2Dj37//+Q7/5a5147TEG9rgtk/GPcczpgmpkDSeAyG/x06JaWoKBkqywSMo 8Ah7Yup/VdqSgUQE4HHPh9ye1kcOqS2Kr9VUDNZ4K1AwgCxxqx+cw/twffOQEwZo/T+d FwQ6UWrEMFQngsvahclopo04faEdT8kDJoCey3TTrOUHSFgy8f43lX/0tPh7QicHo6rh 6d7CXTrzhvIGpv1p1h3AsKvUxwwGFmM7+1rmxCy6ZTXRLx40qs0cctx5nqNMTasqyE+p 9Zrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684976212; x=1687568212; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qNV3j8Xshj37jqXvnC/RqnvWSvgnyWGwTFZ6aQsejAM=; b=P7qaEjVvpUrLF8EKRgfP7hIv12GlbsSer87oHsqRR67YHVSvvKa3OxrOn07u85Fnob gOIZUB4nMiSpOkMfWdLrFS2PwePbJp9Fj7u9T6ZrVoCDUY23Mzpgei9lyUTbyqYRM9Tm 9LqcpzWaFvvHMPAn0wLDjV6dy4wHwK/ljWTKbrUCc2uETY0cY/oSIoGwAzrQ5HPuBw97 Dzf/B8zLXNgh33UZ9c1DZG8pFQ+0DGHLX5IWzCTdmDtzFWlZOdXLM6dnQNYohRwmlmWP XNN34sD71quRfw0s85sdP72g57Bs8Ezp+PftOP5k+FADcvZ/S038QKhbYGbr5L4CzOXN UVRw== X-Gm-Message-State: AC+VfDzJraeWTm5kQ1zylLUTrMwSdVx56rVh9ltuS2GhNnrluWfC1YzD PVVLFAZMnrztoqVPwA9kA+L44NlQ7XM= X-Google-Smtp-Source: ACHHUZ7ZOx87ynMfPbqDeweExkP60wOgePEjgcjBoaoelwLji0L7jWpFxbTYTlUUDJEa0eLjEUaUzw== X-Received: by 2002:a05:622a:11cc:b0:3f5:2faf:7917 with SMTP id n12-20020a05622a11cc00b003f52faf7917mr29587034qtk.9.1684976212353; Wed, 24 May 2023 17:56:52 -0700 (PDT) Received: from [192.168.2.18] ([71.173.77.129]) by smtp.gmail.com with ESMTPSA id u22-20020a05622a199600b003f6bc367ee3sm1708378qtc.36.2023.05.24.17.56.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 May 2023 17:56:51 -0700 (PDT) Message-ID: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> Date: Wed, 24 May 2023 20:57:39 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: How to blacklist the nouveau driver on FreeBSD.... Content-Language: en-US To: Mario Marietto , freebsd-hackers References: From: Theron In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4QRV4j0qKdz3p67 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5/24/23 04:43, Mario Marietto wrote: > since the nouveau driver can't be blacklisted within the Linuxulator > because it's impossible to run "sudo update-initramfs -u" inside of > it. For this reason,I would ask if in your opinion the nouveau driver > can be blacklisted directly in FreeBSD or in some other way. Thanks. > FreeBSD does not contain the nouveau kernel module so there is nothing to blacklist. > He says that he created a Python script for updating Nvidia drivers on > CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please give > a look to an old post created by me some time ago and you will see : > > https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_nouveau_driver_within_the/ > These libGL errors are from Mesa libGL, which is trying to use the userspace part of nouveau (which is part of the Mesa project), presumably based on Nvidia GPU's PCI ID being known to Mesa, despite there being no nouveau kernel interface available. Since you are trying to use Nvidia's binary driver (the only one which works on FreeBSD), Blender should have never loaded Mesa's libGL in the first place - there is most likely a configuration problem here with libglvnd, the component responsible for choosing the correct libGL implementation. When Blender fails to detect CUDA this has nothing to do with libGL and absolutely nothing to do with nouveau - have you found any other CUDA program to work in linux compat? Theron From nobody Thu May 25 01:30:18 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRVqZ3QBxz4CRRv for ; Thu, 25 May 2023 01:30:34 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRVqX4b6Lz3srC for ; Thu, 25 May 2023 01:30:32 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=K34LfFlX; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::112b) smtp.mailfrom=tomek@cedro.info; dmarc=none Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-55db055b412so7220247b3.0 for ; Wed, 24 May 2023 18:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1684978231; x=1687570231; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RUGK9CXZZGThSQNZt+5FalMrWwsvK+w2j4g94Ic1xao=; b=K34LfFlX9OrVdNkeY7CTCkX3afIIRd2RXPmiSXCyQkkIkVOdQpJRDpcSq7xqfWBL49 i7d4Gox9k0qsvEEw2t4IomU6DpqDRcQjH9N+7TSYcYhNHJxWwyGKKPM2tALoXUch+9YV wICw5/3tbf7d7vCtEgR+dngtAZ8TIuV9CLuw4FlzTHrIFdHHUJJQKNGXQdBSmFhR/o8e PH7xV1BIuN009ChXym54U0j8CtusATbSml32ttEfPYRr9YAfAa0PyEs4/97KDalanlO6 lfsvoZgFgCqOdH0Y4V6lSJJiXWc2w+4qrtcrOoWptYy33nCi0uzMw+WkNZntSgD5+M5e 1kEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684978231; x=1687570231; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RUGK9CXZZGThSQNZt+5FalMrWwsvK+w2j4g94Ic1xao=; b=DriMSCS7yBxGhJMrPDfx2whT/mLOyF6NAUFADZ4uIuE2SYAqp914PdBRIujTAaGu5U Rb2vAEP/Dmvx6+4qc5mz834qLp3Kve6KQOagSLFOTL96YVYM7UaADijK8A3cATm9iBsJ cN66k6XboPmSjqTTABnm5xRjby8jcAQ35Dn7B808I+S4DICYcR0tNv2n4R4/jqxvkHBq 9EjeAT4+HoNYnmfjMqmVpB8NyF7FUynbI1ua8+YGmzGBSH8Nogs4xIHCDovCdmRmaBP8 YTZ4JsAXcOmWM1qprEAKtlmHzjjEfZCh9/Rk/T9si1pDSM7rRZ6HYfW+uCIxyOVc4RPf lbXA== X-Gm-Message-State: AC+VfDwC/imq19SKxT6NooYYDNT4HDBDFKfS0PjUhKfNx52qGAOUv1Nv uvPeKx9UaCdhMdoN2WIqpjWoZw== X-Google-Smtp-Source: ACHHUZ7mT4Xm+4nD8ZWFyjfYPxJGyB7k9r4WaqOh1QJbQ88NJLa4oQGqSMyeZdYktXeJeJxzYvm2QA== X-Received: by 2002:a81:9b56:0:b0:55a:776e:95f3 with SMTP id s83-20020a819b56000000b0055a776e95f3mr997101ywg.25.1684978231218; Wed, 24 May 2023 18:30:31 -0700 (PDT) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com. [209.85.128.178]) by smtp.gmail.com with ESMTPSA id g4-20020a0ddd04000000b00545a08184b1sm4124776ywe.65.2023.05.24.18.30.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 May 2023 18:30:30 -0700 (PDT) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-55db055b412so7220137b3.0; Wed, 24 May 2023 18:30:30 -0700 (PDT) X-Received: by 2002:a0d:ea05:0:b0:561:9bcc:6c81 with SMTP id t5-20020a0dea05000000b005619bcc6c81mr1402634ywe.24.1684978230412; Wed, 24 May 2023 18:30:30 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> In-Reply-To: From: Tomek CEDRO Date: Thu, 25 May 2023 03:30:18 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112b:from,209.85.128.178:received]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[cedro.info]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4QRVqX4b6Lz3srC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: > Protecting requires more efforts and it should be clearly defined: what i= s purpose. If > purpose is having checksum with 99.9% reliability, NVLIST HEADER can be w= iden > to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. Well, this could be optional but useful to make sure snapshot did not break somehow for instance backup medium error or something like that.. even more maybe a way to fix it.. just a design stage idea :-) > If purpose is having crypto verification - I believe sha256 program shoul= d be your choice. My question was more specific to availability of that feature (integrity + repair) rather than specific format :-) The use case here is having a virtual machine (it was VirtualBox) with a bare os installed, plus some common applications, that is snapshoted at some point in time, then experimented a lot, restored from snapshot, etc. I had a backup of such vm + snapshot backed up that got broken somehow. It would be nice to know that something is broken, what is broken, maybe a way to fix :-) > Small is not so perfect. As the first attempt snapshot code is good. But = if you want to get > values related to some specific device, for example, for NIC or HPET, you= cannot get it easily. Please > try :) > > Stream doesn=E2=80=99t have flexibility. It is good for well specified a= nd long long time discussed protocols > like XDR (NFS), when it has RFC and each position in the stream is descri= bed. Example: RFC1813. > > New format with NVLIST has flexibility and is fast enough. Note, ZFS uses= nvlist for keeping attributes > and more another things. Sorry, I was not really aware of that format!! This looks really solid :-) https://github.com/fudosecurity/nvlist https://man.freebsd.org/cgi/man.cgi?query=3Dnvlist > Why do you need modify snapshot image ? Could you describe more? Do you > modify current 3 snapshot files? Analysis that require ram / nvram modification? Not sure if this is already possible, but may come handy for experimenting with uefi and maybe some OS (features) that will not run with unmodified nvram :-P > If you are talking about compatibility of a Image format - it should be c= ompatible in > both directions, at least for not so big format changes. > > If consider overall snapshot/resume compatibility - I believe forward co= mpatibility > is not case and target. Indeed, why do you need to resume an image creat= ed by > a higher version of a program? This happens quite often. For instance there is a bug in application and I need to revert to (at least) one step older version. Then I am unable to work on a file that I just saved (or was autosaved for me). Firefox profile settings let be the first example. KiCAD file format is another example (sometimes I need to switch to a devel build to evade a nasty blocker bug then anyone else that uses a release is blocked for some months including me myself). > The most important thing - backward compatibility, i.e. when an image is = created > by an older version of a program, but should be resumed on a new one. > > This is target and and intention of this improvement. Thank you, this looks promising :-) Just another design stage idea to keep the formats forward and backward compatible at least for some time and/or have an option to skip unknown feature :-) > Yes, I know about another formats, like JSON or others. NVLIST is the mos= t > effective and suitable for the current purposes. Thank you I know that now :-) I have switched to bhyve recently and for my use I prefer it now over virtualbox :-) Thanks again Vitaliy and good luck with the updates :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu May 25 09:10:23 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRj2x3dJCz4TF0Y for ; Thu, 25 May 2023 09:11:05 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRj2v3PjHz3Pkw for ; Thu, 25 May 2023 09:11:03 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=Rg3jjYqR; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-561a33b6d63so4496277b3.1 for ; Thu, 25 May 2023 02:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685005859; x=1687597859; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zybTs2kjbtP0wcSGRJqlVIemHiTQNpjfeb2bnjkMyNo=; b=Rg3jjYqRB271XEHSBfnY4GF46jgEBSbuk5TmJE/tXTWbBXEqG7Ste+1SIhkIwEvyXe vluKKDmuDEtxG3xjE4YDr8SbKBpDkq32QBp0RyOxpKugUysKRjN+DA2t9FE/3vlfRXIS QomfduH78irW+K8e0ets8Zy3USKxd5/VAUF3XN5yRduGy+crgqyUg3kka5zj/dAf7E/7 uqF+j70OgiNBjRMxV8zjXQ2Ejni7BoFFzako7atf+2wBfrpKYD/52/LJz5uL2cW3eHOy xk6d7qr0CEGgsDaxtVi3Oq8avIES5OTnCBhBei+fsZcoC8bTTp5kz2QUP2XGelbxIuim 2uXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685005859; x=1687597859; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zybTs2kjbtP0wcSGRJqlVIemHiTQNpjfeb2bnjkMyNo=; b=cQSEpkHMnxBZnfLaLqS7x1Z+ScFC1JXamEe0vZybxuDAWyhuZGjRG55Ed4ediNM4J4 4gMgdYy6fgOedRbN5Z5kJXRsquuUQGXyQ9elAWR5+CKYm9wX3yNJIb9i8bqwVPh6V2IM ohOqQTjBOhOAtzSKuW1zu4zH1U5fEsG7Odopbf0DT4aNlbkgJBJjXKA2LuEZ0sSA5kS8 yWGR1UrjNfp+v/yo+21C6VY9Wxx6jzioK8Wzz+grHxL1pghidIZP8IeIj3KVUCF/HMFe V8I3yn6y4JEFZ5kHousRUaqntoTezWAgo3xw0B61XFwXxzb0acdnTYfkeAqCBuH6Swdc +Jog== X-Gm-Message-State: AC+VfDxIYONVXPgRdmVarIPvWNrPUsnXdaxhTQGLH8OmfEfFAY204uxS V6SHphaRM/RKxSTsdI7Waa5HA22JP00/KRmyqH6K1NZ1oX7ZWQ== X-Google-Smtp-Source: ACHHUZ56nVEoAZzuGCEryB7w3b5bwwkpxFvWV4V4iRRnaznpeFYfAXQBoYu4sw+OB9foXfBOYtumneYJVuIOtW+Kzj0= X-Received: by 2002:a81:60c1:0:b0:565:798b:949e with SMTP id u184-20020a8160c1000000b00565798b949emr3984177ywb.20.1685005859557; Thu, 25 May 2023 02:10:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> In-Reply-To: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> From: Mario Marietto Date: Thu, 25 May 2023 11:10:23 +0200 Message-ID: Subject: Re: How to blacklist the nouveau driver on FreeBSD.... To: Theron Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000b4157f05fc80fffc" X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QRj2v3PjHz3Pkw X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --000000000000b4157f05fc80fffc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Smplayer behaves the same as blender. I think this is a general behavior. Check below what happens when I run it within the linuxulator : root@marietto:/mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash root@marietto:/# smplayer QStandardPaths: error creating runtime directory '/var/run/user/1001' (No such file or directory) This is SMPlayer v. 22.7.0 (revision 10091) running on Linux libGL error: glx: failed to create dri2 screen *libGL error: failed to load driver: nouveau* On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron wr= ote: > On 5/24/23 04:43, Mario Marietto wrote: > > since the nouveau driver can't be blacklisted within the Linuxulator > > because it's impossible to run "sudo update-initramfs -u" inside of > > it. For this reason,I would ask if in your opinion the nouveau driver > > can be blacklisted directly in FreeBSD or in some other way. Thanks. > > > FreeBSD does not contain the nouveau kernel module so there is nothing > to blacklist. > > > He says that he created a Python script for updating Nvidia drivers on > > CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please give > > a look to an old post created by me some time ago and you will see : > > > > > https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_no= uveau_driver_within_the/ > > > These libGL errors are from Mesa libGL, which is trying to use the > userspace part of nouveau (which is part of the Mesa project), > presumably based on Nvidia GPU's PCI ID being known to Mesa, despite > there being no nouveau kernel interface available. > > Since you are trying to use Nvidia's binary driver (the only one which > works on FreeBSD), Blender should have never loaded Mesa's libGL in the > first place - there is most likely a configuration problem here with > libglvnd, the component responsible for choosing the correct libGL > implementation. > > When Blender fails to detect CUDA this has nothing to do with libGL and > absolutely nothing to do with nouveau - have you found any other CUDA > program to work in linux compat? > > Theron > --=20 Mario. --000000000000b4157f05fc80fffc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Smplayer behaves the same as blender. I think this is= a general behavior. Check below what happens when I run it within the linu= xulator :

root@marietto:/= mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash
<= span style=3D"font-family:arial,sans-serif">
root@marietto:/# smplayer= =C2=A0

QStandardPaths= : error creating runtime directory '/var/run/user/1001' (No such fi= le or directory)
This is SMPlayer v. 22.7.0 (revision 10091) running on Linux
libGL error: glx: failed to create dri2 screen
libGL error: failed to load driver: nouveau



On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron <theron.tarigo@gmail.com> wrote:
On 5/24/23 04:43, Mari= o Marietto wrote:
> since the nouveau driver can't be blacklisted within the Linuxulat= or
> because it's impossible to run "sudo update-initramfs -u"= ; inside of
> it. For this reason,I would ask if in your opinion the nouveau driver =
> can be blacklisted directly in FreeBSD or in some other way. Thanks. >
FreeBSD does not contain the nouveau kernel module so there is nothing
to blacklist.

> He says that he created a Python script for updating Nvidia drivers on=
> CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? plea= se give
> a look to an old post created by me some time ago and you will see : >
> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_no= uveau_driver_within_the/
>
These libGL errors are from Mesa libGL, which is trying to use the
userspace part of nouveau (which is part of the Mesa project),
presumably based on Nvidia GPU's PCI ID being known to Mesa, despite there being no nouveau kernel interface available.

Since you are trying to use Nvidia's binary driver (the only one which =
works on FreeBSD), Blender should have never loaded Mesa's libGL in the=
first place - there is most likely a configuration problem here with
libglvnd, the component responsible for choosing the correct libGL
implementation.

When Blender fails to detect CUDA this has nothing to do with libGL and absolutely nothing to do with nouveau - have you found any other CUDA
program to work in linux compat?

Theron


--
Mario.
--000000000000b4157f05fc80fffc-- From nobody Thu May 25 09:47:06 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRjsG4dfxz4THFq for ; Thu, 25 May 2023 09:47:46 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRjsC5Rq4z3m4Y for ; Thu, 25 May 2023 09:47:43 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=V7pXxzbS; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::112d as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-562108900acso4771297b3.2 for ; Thu, 25 May 2023 02:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685008063; x=1687600063; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YIV29emyHwKPgNGTsz4qiqTBcdzMx03LdAETjZossZI=; b=V7pXxzbSepXbNGR+yx3KuRy8dLu66NDjcex/4yGBK+Sx3tF7TksmQomOC30lZm+KDM TU5Fs1KAlcCB6NlaXK3qWIqTVL5X4FCvUoFfH/lQG9JUvVKH1uGfce5mhcTZxAImB709 +d/Gqv/aeSXAQm0s+g/aW6SDwrFS6bMAkcZ8Uh1X6jUQpx8q1tCz3Co8tuQhFZFjdLU1 kyqVPODTvNmrL4Sk8k99udxQw42usrbnXuYua7d3qLkH6LgLKDGFTx+KgyjT7YOHmr34 XOf8LIbGZW5psZCl4Wi6aoi3pp2nZ8OGwGm16jsW5wxcBBqrN/6j2tW/2OCoHFUMhfGC rwvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685008063; x=1687600063; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YIV29emyHwKPgNGTsz4qiqTBcdzMx03LdAETjZossZI=; b=PgHgJ/cV8dWVtBNMa1bhX7igr9OeJSK8qO4NRUJZtK6CGW78uJPAbIM5Cm0+9i4rlL mMKPbfMCNnEEKY+RWUrRUpu+C9mBCk/Y3B5+5WCiiSpthhTcJYK7Y4TGXRMYOYpnH2bK 6nt7HCa44/eNxSteyKJ09uFi7DStdqloyBFpbQz7BGT7gxeof5CrYksCeWotIK+naLqA 7PxnHn967oMydU4bgO8Gr6RT4RH47Sj6dKCbvMveiiv33gRWchh2j+hkM1ZGqt1SpYO/ 1kWZsGI8IldzSPvxwe6y4Uk+x9WXJK54JAdQjxcG15WdmUKDO7gEDOL1f6fl9PN3GtDC TCmw== X-Gm-Message-State: AC+VfDyrmUAwJPcrLrgKSc/q/Skr17rsZqB3+hPSvWrNqeNSX7yxA3Hp aK06AGiI4R5grtK5rz2DVWfyU8891VqUviZr13tdknWE6Ng= X-Google-Smtp-Source: ACHHUZ4nPC45ZWZ1zUTGk/LlbaLlkIq7nqXAeSf/PZFnZ8aW5WtT31qiTb9hAZ9zIvWwYVjwdV21m/yrVsTXGjh6aW4= X-Received: by 2002:a0d:ccd3:0:b0:562:7f3:beee with SMTP id o202-20020a0dccd3000000b0056207f3beeemr23364247ywd.45.1685008062834; Thu, 25 May 2023 02:47:42 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> In-Reply-To: From: Mario Marietto Date: Thu, 25 May 2023 11:47:06 +0200 Message-ID: Subject: Re: How to blacklist the nouveau driver on FreeBSD.... To: Theron Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000076d0e05fc81832d" X-Spamd-Result: default: False [-3.81 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.81)[-0.815]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112d:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QRjsC5Rq4z3m4Y X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --000000000000076d0e05fc81832d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you figure out a method to do what I want to do ? If we are able to "connect" the nVidia driver to the CG / graphic tool instead of the nouveau one,a lot of cool features will be unfrozen. For example we could try to run Unreal Engine 5 within the linuxulator,Davinci Resolve,Maya 3d,a lot of cool stuff will use the nvidia driver and it will work great. On Thu, May 25, 2023 at 11:10=E2=80=AFAM Mario Marietto wrote: > Smplayer behaves the same as blender. I think this is a general behavior. > Check below what happens when I run it within the linuxulator : > > root@marietto:/mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash > > root@marietto:/# smplayer > > QStandardPaths: error creating runtime directory '/var/run/user/1001' (No > such file or directory) > This is SMPlayer v. 22.7.0 (revision 10091) running on Linux > libGL error: glx: failed to create dri2 screen > *libGL error: failed to load driver: nouveau* > > > > On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron = wrote: > >> On 5/24/23 04:43, Mario Marietto wrote: >> > since the nouveau driver can't be blacklisted within the Linuxulator >> > because it's impossible to run "sudo update-initramfs -u" inside of >> > it. For this reason,I would ask if in your opinion the nouveau driver >> > can be blacklisted directly in FreeBSD or in some other way. Thanks. >> > >> FreeBSD does not contain the nouveau kernel module so there is nothing >> to blacklist. >> >> > He says that he created a Python script for updating Nvidia drivers on >> > CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please give >> > a look to an old post created by me some time ago and you will see : >> > >> > >> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_n= ouveau_driver_within_the/ >> > >> These libGL errors are from Mesa libGL, which is trying to use the >> userspace part of nouveau (which is part of the Mesa project), >> presumably based on Nvidia GPU's PCI ID being known to Mesa, despite >> there being no nouveau kernel interface available. >> >> Since you are trying to use Nvidia's binary driver (the only one which >> works on FreeBSD), Blender should have never loaded Mesa's libGL in the >> first place - there is most likely a configuration problem here with >> libglvnd, the component responsible for choosing the correct libGL >> implementation. >> >> When Blender fails to detect CUDA this has nothing to do with libGL and >> absolutely nothing to do with nouveau - have you found any other CUDA >> program to work in linux compat? >> >> Theron >> > > > -- > Mario. > --=20 Mario. --000000000000076d0e05fc81832d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you figure out a method to do what I want to do ? If w= e are able to "connect" the nVidia driver to the CG / graphic too= l instead of the nouveau one,a lot of cool features will be unfrozen. For e= xample we could try to run Unreal Engine 5 within the linuxulator,Davinci R= esolve,Maya 3d,a lot of cool stuff will use the nvidia driver and it will w= ork great.

On Thu, May 25, 2023 at 11:10=E2=80=AFAM Mario Marietto <= ;marietto2008@g= mail.com> wrote:
Smplayer behaves the same as blender. I think= this is a general behavior. Check below what happens when I run it within = the linuxulator :

root@ma= rietto:/mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash

root@marietto:/# sm= player=C2=A0
=
QStandar= dPaths: error creating runtime directory '/var/run/user/1001' (No s= uch file or directory)
This is SMPlayer v. 22.7.0 (revision 10091) running on Linux
libGL error: glx: failed to create dri2 screen
libGL error: failed to load driver: nouveau



On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron <theron.tarigo@gmail.com= > wrote:
On 5= /24/23 04:43, Mario Marietto wrote:
> since the nouveau driver can't be blacklisted within the Linuxulat= or
> because it's impossible to run "sudo update-initramfs -u"= ; inside of
> it. For this reason,I would ask if in your opinion the nouveau driver =
> can be blacklisted directly in FreeBSD or in some other way. Thanks. >
FreeBSD does not contain the nouveau kernel module so there is nothing
to blacklist.

> He says that he created a Python script for updating Nvidia drivers on=
> CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? plea= se give
> a look to an old post created by me some time ago and you will see : >
> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_no= uveau_driver_within_the/
>
These libGL errors are from Mesa libGL, which is trying to use the
userspace part of nouveau (which is part of the Mesa project),
presumably based on Nvidia GPU's PCI ID being known to Mesa, despite there being no nouveau kernel interface available.

Since you are trying to use Nvidia's binary driver (the only one which =
works on FreeBSD), Blender should have never loaded Mesa's libGL in the=
first place - there is most likely a configuration problem here with
libglvnd, the component responsible for choosing the correct libGL
implementation.

When Blender fails to detect CUDA this has nothing to do with libGL and absolutely nothing to do with nouveau - have you found any other CUDA
program to work in linux compat?

Theron


--
Mario.


--
Mario.
--000000000000076d0e05fc81832d-- From nobody Thu May 25 13:33:04 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRpsy3pnLz4V1CB for ; Thu, 25 May 2023 13:33:42 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRpsx2B3bz46ys for ; Thu, 25 May 2023 13:33:41 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=ClbZReAQ; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-56190515833so8053847b3.0 for ; Thu, 25 May 2023 06:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685021620; x=1687613620; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IT4yBCTjP3qP3rBPGmGrEMkmXIgYBq77hrlNpAa5qF8=; b=ClbZReAQIoB61mhnsj27pN+9Sc+IQE7GHWW+Akh1Csw8wv7shE00bbnWgHA0mTX8Nu UxZlnDH2IRKUpCprHn3Gn22qgaJXACig2rrYC3+Ywu+wX9YQEPkYvbhgOlZVD6FBTz0b Zo2mZDOE2OsXqzZDTDp3PCxVW/arqls01MGEPXrzizY+ey4mWcliRbM3UZxIjVwN6Emf jYnhKtm00MSgslCmXEV/K0Vkk4OSczypcNrh9HZtdiUavNcxOJ4e7Pt8yagslcODnOO3 VL2z5mUEtuxNYa7WSyZPI4o63gaw/5CWBZAnPn5YSbCDQyKkNi80T5w+IbW1JZ5Oax5z QpEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685021620; x=1687613620; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IT4yBCTjP3qP3rBPGmGrEMkmXIgYBq77hrlNpAa5qF8=; b=GXd1wSMQQ6aZP/E3LLwQJxrCBatouZaku6A3cwJkduRWnCH7VcsNUg/pNrvmMB/oir 1ipMwW5Gd1ShLfPVUnnHjssxhsJ8eJQFVeRjIBzSGReaHXdRdhl/46/stJB2z/xi8Kdn vaGL9tOFwz+kW2SskFNdJw131FeqcUYOwRZghLFXY+awADlGxaZxhww2lip8RfSrnUP9 1m0VAB2KbsoNC0t5bVk759eHbvkLrmLuYxv1XnGqYzLZbrxL5iiNVNzvO2iqJZYE/HvB NkEjEH1vLUWtEgLQxJOdW5HRf6dfMOaumojmBIrSypti6fQtHQp4u280cpMy+64L2h9j 7pKQ== X-Gm-Message-State: AC+VfDwMfsL61WOjtT2iikLdsrKyAJtsniro4Qxyw1Wo2sKteNP1aT4t 4lEtrRD61I1vz7U+cfp+jpcVXcwh1F29CGXboVhEQkOIP0xW9g== X-Google-Smtp-Source: ACHHUZ5XbkttK8Z3iRl95k7Gs/gFE7YWQOZl1cD1A/Y5AC/Sk49eOq/6IC7UwtMqIurOGMJrdzh2RIDUu6LPM/7ZkcM= X-Received: by 2002:a81:4f91:0:b0:561:8c00:a644 with SMTP id d139-20020a814f91000000b005618c00a644mr3046849ywb.5.1685021620396; Thu, 25 May 2023 06:33:40 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Thu, 25 May 2023 15:33:04 +0200 Message-ID: Subject: mount_fusefs: /dev/fuse on /mnt/zroot2/zroot2: Operation not permitted To: freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000001f656d05fc84abc2" X-Spamd-Result: default: False [-2.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; NEURAL_SPAM_SHORT(0.12)[0.122]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::1134:server fail]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1134:from]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QRpsx2B3bz46ys X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000001f656d05fc84abc2 Content-Type: text/plain; charset="UTF-8" Hello to everyone. Actually I've installed FreeBSD 14.0-CURRENT on my old PC and I'm trying to mount the folder that I have shared on the main PC via sshfs. This is the command that usually I give : sshfs marietto@192.168.1.2:/mnt/zroot2/zroot2 /mnt/zroot2/zroot2 where 192.168.1.2 is the IP of the main PC (where I'm running FreeBSD 13.2-RELEASE). What happens ? that sometimes it works,sometimes not. Below you see that today it does not work. I would like to know the reason of this behavior,taking in consideration that I don't change anything in the configuration from one day to another. $ ./monta-server mount_fusefs: /dev/fuse on /mnt/zroot2/zroot2: Operation not permitted The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established. ED25519 key fingerprint is SHA256: This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes (marietto@192.168.1.2) Password for marietto@marietto: marietto@marietto:/mnt/zroot2 $ cd zroot2 marietto@marietto:/mnt/zroot2/zroot2 $ ls nothing. it seems the error is connected to fusefs. It may be affected by some kind of bug ? Because on the main PC I have mounted the resource and I can see correctly the content of the shared folder. It is a zpool storage,so I do something like this : # zpool import -f -R /mnt/zroot2 zroot2 # cd /mnt/zroot2/zroot2 # ls ChatGPT Files OS bhyve -- Mario. --0000000000001f656d05fc84abc2 Content-Type: text/html; charset="UTF-8"
Hello to everyone.

Actually I've installed FreeBSD 14.0-CURRENT on my old PC and I'm trying to mount the folder that I have shared on the main PC via sshfs.
This is the command that usually I give :

sshfs marietto@192.168.1.2:/mnt/zroot2/zroot2 /mnt/zroot2/zroot2

where 192.168.1.2 is the IP of the main PC (where I'm running FreeBSD 13.2-RELEASE). What happens ? that sometimes it works,sometimes not. Below you see that today it does not work. I would like to know the reason of this behavior,taking in consideration that I don't change anything in the configuration from one day to another.


$ ./monta-server
mount_fusefs: /dev/fuse on /mnt/zroot2/zroot2: Operation not permitted
The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
ED25519 key fingerprint is SHA256:
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
(marietto@192.168.1.2) Password for marietto@marietto:
marietto@marietto:/mnt/zroot2 $ cd zroot2
marietto@marietto:/mnt/zroot2/zroot2 $ ls
nothing.

it seems the error is connected to fusefs. It may be affected by some kind of bug ? Because on the main PC I have mounted the resource and I can see correctly the content of the shared folder. It is a zpool storage,so I do something like this :

# zpool import -f -R /mnt/zroot2 zroot2
# cd /mnt/zroot2/zroot2
# ls
ChatGPT Files   OS      bhyve

--
Mario.
--0000000000001f656d05fc84abc2-- From nobody Thu May 25 13:40:06 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRq1d73RVz4V1KC; Thu, 25 May 2023 13:40:21 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRq1d6XChz49Wg; Thu, 25 May 2023 13:40:21 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4f3baf04f0cso2393521e87.1; Thu, 25 May 2023 06:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685022018; x=1687614018; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=SgjAC+kTpUWPKowBxrOZR11GblLebEpUF0Yh32dQoN0=; b=OOrtFCtBF3CUSJz0Oav2DCrXZDn0dVZ3B7FXn4I6tj0HVpfgfe9lGu3yehtTYktO1C rfwVnUHaNxEZihY7Lx7k37Qs730NyTwq4Y8+MZHzsuRW1DC4ouryls0uA6pWACfto+TT apZvRvS/yh/7VxJmq7+bbJ71tgVqNfHk/jZ9pGIZ1k1H7MHbtNzrXc+g5Z5BHARH1piS G8Qpo+qPOsdrjvxF9gd9kunj4cpZcL11cO2TO4t9mZmBPXC5ZMbnce9FEpAiHxvW9WUM r1vcJPagCbTvnkcT90OlsYcRzVxRteQD+nTadmnfXxL77V0yZOnskxZHfH3tMf7TphDF +Tbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685022018; x=1687614018; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SgjAC+kTpUWPKowBxrOZR11GblLebEpUF0Yh32dQoN0=; b=iBydoYMu9B69yETrS7gr0ARop2gBAzKTDT1vz94QoVsEbX38m+RnOgTmSZnzp89x3e oLl+EJLkYiSJdIKwkcnw4hawqzmPuvFGzIWWb/dWyHgoyNsGYJXgEh8+EOm+SkcvRaL4 vXhGGW6YMIWwwX/XsHs7IrE4iTWuyFBgLGAwScxRdpIQJStPetpr7Y9OndnM5Kk1nyCi M3bifPNLIp2Wj/0xQWEP1H2SLAiYAqwCKLkrpqXgmCrRXrVnY/dP5BCKgr0y8gDWuXIc nqRO/Yw18vr3Kvc/TX06a22cathx50mjbIbJogcDsq79Y9PBD8aLVkwc0EkoL5QjuKXa PfJQ== X-Gm-Message-State: AC+VfDxsLBp7WNLhH2RJ5lh5arAMy2o+U4+X+PHJRRmJInqlXs2Vrzjo 3QbPWZT6ERGTRhjdCqM1sQpkrKl+1FnI3A== X-Google-Smtp-Source: ACHHUZ4oqGuVc3USY0dp5vYvS11tt0n5YNEj5pBwJk+SUiLwxMKm5qdw/+Mn1TvBB01vT419klJovw== X-Received: by 2002:ac2:5991:0:b0:4f3:940d:abc with SMTP id w17-20020ac25991000000b004f3940d0abcmr5796153lfn.0.1685022017615; Thu, 25 May 2023 06:40:17 -0700 (PDT) Received: from smtpclient.apple ([78.140.234.98]) by smtp.gmail.com with ESMTPSA id p21-20020ac246d5000000b004f3ba3b948dsm210729lfo.284.2023.05.25.06.40.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2023 06:40:17 -0700 (PDT) From: Vitaliy Gusev Message-Id: <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Thu, 25 May 2023 16:40:06 +0300 In-Reply-To: Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org To: Tomek CEDRO References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRq1d6XChz49Wg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 May 2023, at 04:30, Tomek CEDRO wrote: >=20 > On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: >> Protecting requires more efforts and it should be clearly defined: = what is purpose. If >> purpose is having checksum with 99.9% reliability, NVLIST HEADER can = be widen >> to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. >=20 > Well, this could be optional but useful to make sure snapshot did not > break somehow for instance backup medium error or something like > that.. even more maybe a way to fix it.. just a design stage idea :- Yes, new format can have checksum of a Section data if implemented. >=20 >=20 >> If purpose is having crypto verification - I believe sha256 program = should be your choice. >=20 > My question was more specific to availability of that feature > (integrity + repair) rather than specific format :-) >=20 > The use case here is having a virtual machine (it was VirtualBox) with > a bare os installed, plus some common applications, that is snapshoted > at some point in time, then experimented a lot, restored from > snapshot, etc. I had a backup of such vm + snapshot backed up that got > broken somehow. It would be nice to know that something is broken, > what is broken, maybe a way to fix :-) =E2=80=9CIntegrity" is a very broad term. What checksum algorithm is = fine enough? =20 For the instance, ZFS has several options for checksum: checksum=3Don|off|fletcher2|fletcher4|sha256|noparity|sha512|skein|edonr =20 Having checksum for a filesystem is strongly recommended. However, If = consider image format, it doesn=E2=80=99t need to care about consistency in a file itself. As = example (!) - binary files in a system. They don=E2=80=99t have checksum integrated, validation is done by = another program - pkg or another. >=20 >=20 >> Why do you need modify snapshot image ? Could you describe more? Do = you >> modify current 3 snapshot files? >=20 > Analysis that require ram / nvram modification? Not sure if this is > already possible, but may come handy for experimenting with uefi and > maybe some OS (features) that will not run with unmodified nvram :-P Sorry I don=E2=80=99t get, why do you need to modify snapshot image, but = not directly vmem on the running VM? Another question, checksum and modifying image - two mutual exclusive = things.=20 >=20 >=20 >> If you are talking about compatibility of a Image format - it should = be compatible in >> both directions, at least for not so big format changes. >>=20 >> If consider overall snapshot/resume compatibility - I believe = forward compatibility >> is not case and target. Indeed, why do you need to resume an image = created by >> a higher version of a program? >=20 > This happens quite often. For instance there is a bug in application > and I need to revert to (at least) one step older version. Then I am > unable to work on a file that I just saved (or was autosaved for me). > Firefox profile settings let be the first example. KiCAD file format > is another example (sometimes I need to switch to a devel build to > evade a nasty blocker bug then anyone else that uses a release is > blocked for some months including me myself). Any additional thing has a cost of development, testing and support. = Current Implementation doesn=E2=80=99t support compatibility at all. Having = compatibility in both directions can be hard. For example, if some variable is removed in bhyve, backward = compatibility is fine, but forward compatibly is not possible unless that removed variable is = being saved into a snapshot image just for forward compatibility. And of course, it = should be tested and verified as worked. Do you like that approach? I don=E2=80=99t think so. So I guess only = backward compatibility should be supported to make the snapshot code simple and robust. Thanks, Vitaliy Gusev --Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25 = May 2023, at 04:30, Tomek CEDRO <tomek@cedro.info> wrote:

On Wed, May 24, 2023 at = 5:11=E2=80=AFPM Vitaliy Gusev wrote:
Protecting requires more efforts and it should be clearly = defined: what is purpose. If
purpose is having checksum with 99.9% = reliability, NVLIST HEADER can be widen
to have =E2=80=9Cchecksum=E2=80= =9D key/value for a Section.

Well, this could be = optional but useful to make sure snapshot did not
break somehow for = instance backup medium error or something like
that.. even more maybe = a way to fix it.. just a design stage idea = :-

Yes, new format can have checksum of a = Section data if implemented.



If purpose is = having crypto verification - I believe sha256 program should be your = choice.

My question was more specific to = availability of that feature
(integrity + repair) rather than = specific format :-)

The use case here is having a virtual machine = (it was VirtualBox) with
a bare os installed, plus some common = applications, that is snapshoted
at some point in time, then = experimented a lot, restored from
snapshot, etc. I had a backup of = such vm + snapshot backed up that got
broken somehow. It would be = nice to know that something is broken,
what is broken, maybe a way to = fix = :-)


 =E2= =80=9CIntegrity" is a very broad term. What checksum algorithm is fine = enough?
 
For the instance,  ZFS has = several options for checksum:

checksum=3Don|off|fletcher2|fletcher4= |sha256|noparity|sha512|skein|edonr=

      =  


Having = checksum for a filesystem is strongly recommended. However, If consider = image format,
it  doesn=E2=80=99t need to care about = consistency in a file itself. As example (!)  - binary files in a = system.
They don=E2=80=99t have checksum integrated, = validation is done by another program  - pkg or = another.




Why do you = need modify snapshot image ? Could you describe more? Do you
modify = current 3 snapshot files?

Analysis that require ram = / nvram modification? Not sure if this is
already possible, but may = come handy for experimenting with uefi and
maybe some OS (features) = that will not run with unmodified nvram = :-P


Sorry I = don=E2=80=99t get, why do you need to modify snapshot image, but not = directly vmem on the = running
VM?

Another question, = checksum and modifying image - two mutual exclusive = things. 



If you are = talking about compatibility of a Image format - it should be compatible = in
both directions, at least for not so big format changes.

If = consider overall snapshot/resume compatibility - I believe  forward = compatibility
is not case and target. Indeed, why do you need =  to resume an image created by
a higher version of a = program?

This happens quite often. For instance = there is a bug in application
and I need to revert to (at least) one = step older version. Then I am
unable to work on a file that I just = saved (or was autosaved for me).
Firefox profile settings let be the = first example. KiCAD file format
is another example (sometimes I need = to switch to a devel build to
evade a nasty blocker bug then anyone = else that uses a release is
blocked for some months including me = myself).

Any additional = thing has a cost of development, testing and support. = Current
Implementation doesn=E2=80=99t support compatibility = at all. Having compatibility in both
directions can be = hard.

For example, if some variable is removed = in bhyve, backward compatibility is fine,
but forward = compatibly is not possible unless that removed variable is being = saved
into a snapshot image just for forward compatibility. = And of course, it should be tested
and verified as = worked.

Do you like that approach? I don=E2=80=99= t think so. So I guess only backward compatibility
should be = supported to make the snapshot code simple and = robust.

Thanks,
Vitaliy = Gusev


= --Apple-Mail=_CD459CBE-FE38-45F5-8B0C-D194440D4C9B-- From nobody Thu May 25 13:51:22 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRqGj0Dpmz4V1s4 for ; Thu, 25 May 2023 13:51:41 +0000 (UTC) (envelope-from cglogic@protonmail.com) Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRqGh5M7Cz4FSY for ; Thu, 25 May 2023 13:51:40 +0000 (UTC) (envelope-from cglogic@protonmail.com) Authentication-Results: mx1.freebsd.org; none Date: Thu, 25 May 2023 13:51:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1685022697; x=1685281897; bh=puHf2Y0Yqs/YYPg8IwgaVyYbmHTnodcN1o5pW1029hU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hGQUidvWy9p+2QTmDi7qkafh70r43HEWgOzqLMkDLNIvRMAQy6o6BxrVAWKtTKKLU KTdeCqaNGCP5vPVMzEFo0+iFUYgakawXms4rEDJG5cLtUeYeYeulmQsLg2E0YModzV /UQ4IfIVebrpqQX4e5h6xCGvJNqB/D495AFD9JmAcLv/kMQb5Cc2QTS/Cmf8GqMfgo WxhSWE8EjWtg5Oa2JgXclXO9E/Q2a7mm4acbgMieO78qtGivNXKsyu8vPzBSPKeHZT BhLSgWMcDt7jBwsCv+5B5odECXRdnpFKT8FY1rPWiM5OWYpjAZPlgTw6FAqy3DVYIZ mB1qPFF0SOgFA== To: Mario Marietto From: cglogic Cc: freebsd-hackers Subject: Re: mount_fusefs: /dev/fuse on /mnt/zroot2/zroot2: Operation not permitted Message-ID: In-Reply-To: References: Feedback-ID: 25313618:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_qxNJCNgeTmSxpzT1R2rTYuo4ethYovANvinbT8vSQ" X-Rspamd-Queue-Id: 4QRqGh5M7Cz4FSY X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_qxNJCNgeTmSxpzT1R2rTYuo4ethYovANvinbT8vSQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RGVhciBNYXJpbywKClRoZSBmcmVlYnNkLWhhY2tlcnMgaXMgbm90IHJpZ2h0IHBsYWNlIGZvciBz dWNoIHF1ZXN0aW9ucy4KUGxlYXNlIHVzZSBmcmVlYnNkLXF1ZXN0aW9ucyBvciBmb3J1bXMuCgpU aGFuayB5b3UuCi0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tCk9uIFRodXJzZGF5LCBN YXkgMjV0aCwgMjAyMyBhdCA0OjMzIFBNLCBNYXJpbyBNYXJpZXR0byA8bWFyaWV0dG8yMDA4QGdt YWlsLmNvbT4gd3JvdGU6Cgo+IEhlbGxvIHRvIGV2ZXJ5b25lLgo+Cj4gQWN0dWFsbHkgSSd2ZSBp bnN0YWxsZWQgRnJlZUJTRCAxNC4wLUNVUlJFTlQgb24gbXkgb2xkIFBDIGFuZCBJJ20gdHJ5aW5n IHRvIG1vdW50IHRoZSBmb2xkZXIgdGhhdCBJIGhhdmUgc2hhcmVkIG9uIHRoZSBtYWluIFBDIHZp YSBzc2hmcy4KPiBUaGlzIGlzIHRoZSBjb21tYW5kIHRoYXQgdXN1YWxseSBJIGdpdmUgOgo+Cj4g c3NoZnMgbWFyaWV0dG9AMTkyLjE2OC4xLjI6L21udC96cm9vdDIvenJvb3QyIC9tbnQvenJvb3Qy L3pyb290Mgo+Cj4gd2hlcmUgMTkyLjE2OC4xLjIgaXMgdGhlIElQIG9mIHRoZSBtYWluIFBDICh3 aGVyZSBJJ20gcnVubmluZyBGcmVlQlNEIDEzLjItUkVMRUFTRSkuIFdoYXQgaGFwcGVucyA/IHRo YXQgc29tZXRpbWVzIGl0IHdvcmtzLHNvbWV0aW1lcyBub3QuIEJlbG93IHlvdSBzZWUgdGhhdCB0 b2RheSBpdCBkb2VzIG5vdCB3b3JrLiBJIHdvdWxkIGxpa2UgdG8ga25vdyB0aGUgcmVhc29uIG9m IHRoaXMgYmVoYXZpb3IsdGFraW5nIGluIGNvbnNpZGVyYXRpb24gdGhhdCBJIGRvbid0IGNoYW5n ZSBhbnl0aGluZyBpbiB0aGUgY29uZmlndXJhdGlvbiBmcm9tIG9uZSBkYXkgdG8gYW5vdGhlci4K Pgo+ICQgLi9tb250YS1zZXJ2ZXIKPiBtb3VudF9mdXNlZnM6IC9kZXYvZnVzZSBvbiAvbW50L3py b290Mi96cm9vdDI6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVkCj4gVGhlIGF1dGhlbnRpY2l0eSBv ZiBob3N0ICcxOTIuMTY4LjEuMiAoMTkyLjE2OC4xLjIpJyBjYW4ndCBiZSBlc3RhYmxpc2hlZC4K PiBFRDI1NTE5IGtleSBmaW5nZXJwcmludCBpcyBTSEEyNTY6Cj4gVGhpcyBrZXkgaXMgbm90IGtu b3duIGJ5IGFueSBvdGhlciBuYW1lcy4KPiBBcmUgeW91IHN1cmUgeW91IHdhbnQgdG8gY29udGlu dWUgY29ubmVjdGluZyAoeWVzL25vL1tmaW5nZXJwcmludF0pPyB5ZXMKPiAoCj4gbWFyaWV0dG9A MTkyLjE2OC4xLjIKPiApIFBhc3N3b3JkIGZvciBtYXJpZXR0b0BtYXJpZXR0bzoKPiBtYXJpZXR0 b0BtYXJpZXR0bzovbW50L3pyb290MiAkIGNkIHpyb290Mgo+IG1hcmlldHRvQG1hcmlldHRvOi9t bnQvenJvb3QyL3pyb290MiAkIGxzCj4gbm90aGluZy4KPgo+IGl0IHNlZW1zIHRoZSBlcnJvciBp cyBjb25uZWN0ZWQgdG8gZnVzZWZzLiBJdCBtYXkgYmUgYWZmZWN0ZWQgYnkgc29tZSBraW5kIG9m IGJ1ZyA/IEJlY2F1c2Ugb24gdGhlIG1haW4gUEMgSSBoYXZlIG1vdW50ZWQgdGhlIHJlc291cmNl IGFuZCBJIGNhbiBzZWUgY29ycmVjdGx5IHRoZSBjb250ZW50IG9mIHRoZSBzaGFyZWQgZm9sZGVy LiBJdCBpcyBhIHpwb29sIHN0b3JhZ2Usc28gSSBkbyBzb21ldGhpbmcgbGlrZSB0aGlzIDoKPgo+ ICMgenBvb2wgaW1wb3J0IC1mIC1SIC9tbnQvenJvb3QyIHpyb290Mgo+ICMgY2QgL21udC96cm9v dDIvenJvb3QyCj4gIyBscwo+IENoYXRHUFQgRmlsZXMgICBPUyAgICAgIGJoeXZlCj4KPiAtLQo+ IE1hcmlvLg== --b1_qxNJCNgeTmSxpzT1R2rTYuo4ethYovANvinbT8vSQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5EZWFyIE1hcmlvLDwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+VGhlIGZyZWVic2QtaGFj a2VycyBpcyBub3QgcmlnaHQgcGxhY2UgZm9yIHN1Y2ggcXVlc3Rpb25zLjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+UGxl YXNlIHVzZSZuYnNwOzxzcGFuPmZyZWVic2QtcXVlc3Rpb25zIG9yIGZvcnVtcy48L3NwYW4+PC9k aXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij48c3Bhbj48YnI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4+VGhhbmsgeW91Ljwvc3Bh bj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj4NCiAgICAgICAgLS0tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tLS08YnI+DQogICAgICAgIE9uIFRodXJzZGF5LCBNYXkgMjV0 aCwgMjAyMyBhdCA0OjMzIFBNLCBNYXJpbyBNYXJpZXR0byAmbHQ7bWFyaWV0dG8yMDA4QGdtYWls LmNvbSZndDsgd3JvdGU6PGJyPjxicj4NCiAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9InByb3Rv bm1haWxfcXVvdGUiIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+SGVs bG8gdG8gZXZlcnlvbmUuPGJyPg0KPGJyPjxkaXY+DQpBY3R1YWxseSBJJ3ZlIGluc3RhbGxlZCBG cmVlQlNEIDE0LjAtQ1VSUkVOVCBvbiBteSBvbGQgUEMgYW5kIEknbSB0cnlpbmcNCiB0byBtb3Vu dCB0aGUgZm9sZGVyIHRoYXQgSSBoYXZlIHNoYXJlZCBvbiB0aGUgbWFpbiBQQyB2aWEgc3NoZnMu IDxicj48L2Rpdj48ZGl2PlRoaXMNCmlzIHRoZSBjb21tYW5kIHRoYXQgdXN1YWxseSBJIGdpdmUg OjwvZGl2Pg0KPGJyPg0KDQoNCg0KDQoNCjxkaXYgY2xhc3M9ImdtYWlsLWJiQ29kZUJsb2NrIGdt YWlsLWJiQ29kZUJsb2NrLS1zY3JlZW5MaW1pdGVkIGdtYWlsLWJiQ29kZUJsb2NrLS1jb2RlIj4N Cg0KCTxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbC1iYkNvZGVCbG9jay1jb250ZW50Ij4NCgkJ PHByZSBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsLWJiQ29kZUNvZGUiPjxjb2RlIHN0eWxlPSJmb250 LWZhbWlseTp0aW1lcyBuZXcgcm9tYW4sc2VyaWYiPnNzaGZzIG1hcmlldHRvQDE5Mi4xNjguMS4y Oi9tbnQvenJvb3QyL3pyb290MiAvbW50L3pyb290Mi96cm9vdDI8L2NvZGU+PC9wcmU+DQoJPC9k aXY+DQo8L2Rpdj48YnI+DQp3aGVyZSAxOTIuMTY4LjEuMiBpcyB0aGUgSVAgb2YgdGhlIG1haW4g UEMgKHdoZXJlIEknbSBydW5uaW5nIEZyZWVCU0QNCjEzLjItUkVMRUFTRSkuIFdoYXQgaGFwcGVu cyA/IHRoYXQgc29tZXRpbWVzIGl0IHdvcmtzLHNvbWV0aW1lcyBub3QuDQpCZWxvdyB5b3Ugc2Vl IHRoYXQgdG9kYXkgaXQgZG9lcyBub3Qgd29yay4gSSB3b3VsZCBsaWtlIHRvIGtub3cgdGhlDQpy ZWFzb24gb2YgdGhpcyBiZWhhdmlvcix0YWtpbmcgaW4gY29uc2lkZXJhdGlvbiB0aGF0IEkgZG9u J3QgY2hhbmdlDQphbnl0aGluZyBpbiB0aGUgY29uZmlndXJhdGlvbiBmcm9tIG9uZSBkYXkgdG8g YW5vdGhlci48YnI+DQo8YnI+DQoNCg0KDQoNCg0KPGRpdiBjbGFzcz0iZ21haWwtYmJDb2RlQmxv Y2sgZ21haWwtYmJDb2RlQmxvY2stLXNjcmVlbkxpbWl0ZWQgZ21haWwtYmJDb2RlQmxvY2stLWNv ZGUiPg0KCTxkaXYgY2xhc3M9ImdtYWlsLWJiQ29kZUJsb2NrLXRpdGxlIj48Zm9udCBzaXplPSIy Ij48YnI+PC9mb250PjwvZGl2Pg0KCTxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbC1iYkNvZGVC bG9jay1jb250ZW50Ij4NCgkJPHByZSBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsLWJiQ29kZUNvZGUi Pjxmb250IHNpemU9IjIiPjxjb2RlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTp0aW1lcyBuZXcg cm9tYW4sc2VyaWYiPiQgLi9tb250YS1zZXJ2ZXINCm1vdW50X2Z1c2VmczogL2Rldi9mdXNlIG9u IC9tbnQvenJvb3QyL3pyb290MjogT3BlcmF0aW9uIG5vdCBwZXJtaXR0ZWQNClRoZSBhdXRoZW50 aWNpdHkgb2YgaG9zdCAnMTkyLjE2OC4xLjIgKDE5Mi4xNjguMS4yKScgY2FuJ3QgYmUgZXN0YWJs aXNoZWQuDQpFRDI1NTE5IGtleSBmaW5nZXJwcmludCBpcyBTSEEyNTY6DQpUaGlzIGtleSBpcyBu b3Qga25vd24gYnkgYW55IG90aGVyIG5hbWVzLg0KQXJlIHlvdSBzdXJlIHlvdSB3YW50IHRvIGNv bnRpbnVlIGNvbm5lY3RpbmcgKHllcy9uby9bZmluZ2VycHJpbnRdKT8geWVzDQooPGEgaHJlZj0i bWFpbHRvOm1hcmlldHRvQDE5Mi4xNjguMS4yIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9v cGVuZXIiIHRhcmdldD0iX2JsYW5rIj5tYXJpZXR0b0AxOTIuMTY4LjEuMjwvYT4pIFBhc3N3b3Jk IGZvciBtYXJpZXR0b0BtYXJpZXR0bzoNCm1hcmlldHRvQG1hcmlldHRvOi9tbnQvenJvb3QyICQg Y2QgenJvb3QyDQptYXJpZXR0b0BtYXJpZXR0bzovbW50L3pyb290Mi96cm9vdDIgJCBscw0Kbm90 aGluZy48L3NwYW4+PC9jb2RlPjwvZm9udD48L3ByZT4NCgk8L2Rpdj4NCjwvZGl2Pjxicj4NCml0 IHNlZW1zIHRoZSBlcnJvciBpcyBjb25uZWN0ZWQgdG8gZnVzZWZzLiBJdCBtYXkgYmUgYWZmZWN0 ZWQgYnkgc29tZQ0Ka2luZCBvZiBidWcgPyBCZWNhdXNlIG9uIHRoZSBtYWluIFBDIEkgaGF2ZSBt b3VudGVkIHRoZSByZXNvdXJjZSBhbmQgSQ0KY2FuIHNlZSBjb3JyZWN0bHkgdGhlIGNvbnRlbnQg b2YgdGhlIHNoYXJlZCBmb2xkZXIuIEl0IGlzIGEgenBvb2wNCnN0b3JhZ2Usc28gSSBkbyBzb21l dGhpbmcgbGlrZSB0aGlzIDo8YnI+DQo8YnI+DQoNCg0KDQoNCg0KPGRpdiBjbGFzcz0iZ21haWwt YmJDb2RlQmxvY2sgZ21haWwtYmJDb2RlQmxvY2stLXNjcmVlbkxpbWl0ZWQgZ21haWwtYmJDb2Rl QmxvY2stLWNvZGUiPg0KCTxkaXYgY2xhc3M9ImdtYWlsLWJiQ29kZUJsb2NrLXRpdGxlIj48L2Rp dj4NCgk8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWwtYmJDb2RlQmxvY2stY29udGVudCI+DQoJ CTxwcmUgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbC1iYkNvZGVDb2RlIj48Y29kZSBzdHlsZT0iZm9u dC1mYW1pbHk6dGltZXMgbmV3IHJvbWFuLHNlcmlmIj4jIHpwb29sIGltcG9ydCAtZiAtUiAvbW50 L3pyb290MiB6cm9vdDINCiMgY2QgL21udC96cm9vdDIvenJvb3QyDQojIGxzDQpDaGF0R1BUIEZp bGVzICAgT1MgICAgICBiaHl2ZTwvY29kZT48L3ByZT4NCgk8L2Rpdj4NCjwvZGl2Pjxicj48ZGl2 PjxzcGFuIGNsYXNzPSJnbWFpbF9zaWduYXR1cmVfcHJlZml4Ij4tLSA8L3NwYW4+PC9kaXY+PGRp diBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIiBjbGFzcz0iZ21haWxfc2lnbmF0dXJl IiBkaXI9Imx0ciI+TWFyaW8uPGJyPjwvZGl2PjwvZGl2Pg0KDQogICAgICAgIDwvYmxvY2txdW90 ZT48YnI+DQogICAgPC9kaXY+ --b1_qxNJCNgeTmSxpzT1R2rTYuo4ethYovANvinbT8vSQ-- From nobody Thu May 25 16:22:10 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRtd85PzBz4V9qf; Thu, 25 May 2023 16:22:52 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRtd35nxjz3MQ8; Thu, 25 May 2023 16:22:47 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=JrGIqHKf; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::112d as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-561e5014336so6763057b3.1; Thu, 25 May 2023 09:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685031767; x=1687623767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r9YI6+hMcd7OV+oac4bpou6A/Jq22N9AbSDYtZeLido=; b=JrGIqHKffw9TPA6Sj+XsLlfkTTM7xrEKCUW/IzFwghJYqqyMS+0K7QyRMY6nH4diW/ YKKrkFKgoVkUGe7Fu4UFdh6AmrS5p1UZ37f4W2tGR4rOaxgozmdOElQ5OpMupfc46zjv OzNVIhJfZgwpsiZ1kkpwBoFRrJ2K9EYwYbxKzC8KtGIYLC3a+HP6YM3Ar6zFVHxYCX77 S3SK4vwfyZ2LLLAPtHQJSGA1pu4hMu5nH5YDYw0gu+NuwbFsv3/rS+AQL/Y+cLwyyZOJ f234oUdyxfMI33as39TQuJl15P8PsiatZt3OphGbME8bXf3a0KsfVE7tS8rIilukmeKh uKDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685031767; x=1687623767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r9YI6+hMcd7OV+oac4bpou6A/Jq22N9AbSDYtZeLido=; b=QGWvkSOpbYT3uYEJxUroy0OW97Ylc84IXmtVJqbcA+VA4gchkh1/y35dbdQDa9B1el aHIpwQF8box+LYB2Z7fNp5oxAN3H2po/ENO5ZkYc0cwvi7LNuzHdwG3xmpbmGSQT+bSq riZKz0d+f8ba7WsWtLtSFVe3CG/XMipDAxbMuUwlOtR2LB8SXpPg5kCOTJiZuVuWqqIz orCIsKTUwEpUUXvE04MMftgmzOWHF4NdYpqf3nVFb7DgADT/A8n5crWhHwvD1sXK7CpY fJQ05+pYuJgdFw88G5yvUOPJdBtwTyHiGbg91chue4NUbAYQxgQd1NOjrOJTpLNmLwLW J3Aw== X-Gm-Message-State: AC+VfDz3GfN/HwfKegkhaJWu6PyDiBkrWHH2v1MxDjh6Qb/Rl5rDFMRL 0h+/Kzsuygj00rcGcBb5Sti/EeD+6Kv52nlB7GdOeCWSyxE= X-Google-Smtp-Source: ACHHUZ5C8uWknnhVdFFjNyRwVoLr5IYLumB1Luk0/Cw1GDXjZpjxG0bsGJ2ihhEHiSC5CfS2Yn+mgy0XQ/lBr4lwh5g= X-Received: by 2002:a25:dcd3:0:b0:ba8:364b:8f3c with SMTP id y202-20020a25dcd3000000b00ba8364b8f3cmr3962142ybe.53.1685031766639; Thu, 25 May 2023 09:22:46 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> In-Reply-To: <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> From: Mario Marietto Date: Thu, 25 May 2023 18:22:10 +0200 Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e2ca2a05fc8707fc" X-Spamd-Result: default: False [-2.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[virtualization@freebsd.org,freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112d:from]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4QRtd35nxjz3MQ8 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000e2ca2a05fc8707fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vitaliy, what happens if I clone your repo as source code on my FreeBSD system. Can I test your code directly or not ? Anyway,I think that,before doing this,I need to follow some kind of tutorial,to understand how the workflow is. Otherwise I will be not able to test and stress it. On Thu, May 25, 2023 at 3:40=E2=80=AFPM Vitaliy Gusev wrote: > > > On 25 May 2023, at 04:30, Tomek CEDRO wrote: > > On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: > > Protecting requires more efforts and it should be clearly defined: what i= s > purpose. If > purpose is having checksum with 99.9% reliability, NVLIST HEADER can be > widen > to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. > > > Well, this could be optional but useful to make sure snapshot did not > break somehow for instance backup medium error or something like > that.. even more maybe a way to fix it.. just a design stage idea :- > > > Yes, new format can have checksum of a Section data if implemented. > > > > If purpose is having crypto verification - I believe sha256 program shoul= d > be your choice. > > > My question was more specific to availability of that feature > (integrity + repair) rather than specific format :-) > > The use case here is having a virtual machine (it was VirtualBox) with > a bare os installed, plus some common applications, that is snapshoted > at some point in time, then experimented a lot, restored from > snapshot, etc. I had a backup of such vm + snapshot backed up that got > broken somehow. It would be nice to know that something is broken, > what is broken, maybe a way to fix :-) > > > > =E2=80=9CIntegrity" is a very broad term. What checksum algorithm is fin= e enough? > > For the instance, ZFS has several options for checksum: > > *checksum*=3D*on*|*off*|*fletcher2*|*fletcher4*|*sha256*|*noparity*|*sha5= 12* > |*skein*|*edonr* > > > > > Having checksum for a filesystem is strongly recommended. However, If > consider image format, > it doesn=E2=80=99t need to care about consistency in a file itself. As e= xample > (!) - binary files in a system. > They don=E2=80=99t have checksum integrated, validation is done by anothe= r program > - pkg or another. > > > > > Why do you need modify snapshot image ? Could you describe more? Do you > modify current 3 snapshot files? > > > Analysis that require ram / nvram modification? Not sure if this is > already possible, but may come handy for experimenting with uefi and > maybe some OS (features) that will not run with unmodified nvram :-P > > > > Sorry I don=E2=80=99t get, why do you need to modify snapshot image, but = not > directly vmem on the running > VM? > > Another question, checksum and modifying image - two mutual exclusive > things. > > > > If you are talking about compatibility of a Image format - it should be > compatible in > both directions, at least for not so big format changes. > > If consider overall snapshot/resume compatibility - I believe forward > compatibility > is not case and target. Indeed, why do you need to resume an image > created by > a higher version of a program? > > > This happens quite often. For instance there is a bug in application > and I need to revert to (at least) one step older version. Then I am > unable to work on a file that I just saved (or was autosaved for me). > Firefox profile settings let be the first example. KiCAD file format > is another example (sometimes I need to switch to a devel build to > evade a nasty blocker bug then anyone else that uses a release is > blocked for some months including me myself). > > > Any additional thing has a cost of development, testing and support. > Current > Implementation doesn=E2=80=99t support compatibility at all. Having compa= tibility > in both > directions can be hard. > > For example, if some variable is removed in bhyve, backward compatibility > is fine, > but forward compatibly is not possible unless that removed variable is > being saved > into a snapshot image just for forward compatibility. And of course, it > should be tested > and verified as worked. > > Do you like that approach? I don=E2=80=99t think so. So I guess only back= ward > compatibility > should be supported to make the snapshot code simple and robust. > > Thanks, > Vitaliy Gusev > > > --=20 Mario. --000000000000e2ca2a05fc8707fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Vitaliy,

what happens if I c= lone your repo as source code on my FreeBSD system. Can I test your code di= rectly or not ? Anyway,I think that,before doing this,I need to follow some= kind of tutorial,to understand how the workflow is. Otherwise I will be no= t able to test and stress it.

On Thu, May 25, 2023 at 3:40=E2=80= =AFPM Vitaliy Gusev <gusev.vi= taliy@gmail.com> wrote:


On 25 May 2= 023, at 04:30, Tomek CEDRO <tomek@cedro.info> wrote:

On Wed, May = 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote:
Protecting requires more efforts and it should be clearly defined: what = is purpose. If
purpose is having checksum with 99.9% reliability, NVLIST= HEADER can be widen
to have =E2=80=9Cchecksum=E2=80=9D key/value for a = Section.

Well, this could be optional but useful to mak= e sure snapshot did not
break somehow for instance backup medium error o= r something like
that.. even more maybe a way to fix it.. just a design = stage idea :-

Yes, new format can have checksum= of a Section data if implemented.

=


If purpose is having crypto ver= ification - I believe sha256 program should be your choice.

My question was more specific to availability of that feature
(inte= grity + repair) rather than specific format :-)

The use case here is= having a virtual machine (it was VirtualBox) with
a bare os installed, = plus some common applications, that is snapshoted
at some point in time,= then experimented a lot, restored from
snapshot, etc. I had a backup of= such vm + snapshot backed up that got
broken somehow. It would be nice = to know that something is broken,
what is broken, maybe a way to fix :-)=


=C2=A0=E2= =80=9CIntegrity" is a very broad term. What checksum algorithm is fine= enough?
=C2=A0
For the instance, =C2=A0ZFS has several= options for checksum:

checksum=3Don|off|fletcher2|fletcher4|= sha256|noparity|sha512|skein|edonr

=C2= =A0 =C2=A0 =C2=A0 =C2=A0


=
Having checksum for a filesystem is strongly recommended. However, If = consider image format,
it =C2=A0doesn=E2=80=99t need to care abou= t consistency in a file itself. As example (!) =C2=A0- binary files in a sy= stem.
They don=E2=80=99t have checksum integrated, validation is = done by another program =C2=A0- pkg or another.



Why do you need modify snapshot image ? Could you describe more? = Do you
modify current 3 snapshot files?

Analysis tha= t require ram / nvram modification? Not sure if this is
already possible= , but may come handy for experimenting with uefi and
maybe some OS (feat= ures) that will not run with unmodified nvram :-P


Sorry I don=E2=80=99t get, why do you need= to modify snapshot image, but not directly vmem on the running
V= M?

Another question, checksum and modifying image = - two mutual exclusive things.=C2=A0



If you are talking about comp= atibility of a Image format - it should be compatible in
both directions= , at least for not so big format changes.

If consider overall snapsh= ot/resume compatibility - I believe =C2=A0forward compatibility
is not c= ase and target. Indeed, why do you need =C2=A0to resume an image created by=
a higher version of a program?

This happens quite o= ften. For instance there is a bug in application
and I need to revert to= (at least) one step older version. Then I am
unable to work on a file t= hat I just saved (or was autosaved for me).
Firefox profile settings let= be the first example. KiCAD file format
is another example (sometimes I= need to switch to a devel build to
evade a nasty blocker bug then anyon= e else that uses a release is
blocked for some months including me mysel= f).

Any additional thing ha= s a cost of development, testing and support. Current
Implementat= ion doesn=E2=80=99t support compatibility at all. Having compatibility in b= oth
directions can be hard.

For example,= if some variable is removed in bhyve, backward compatibility is fine,
but forward compatibly is not possible unless that removed variable i= s being saved
into a snapshot image just for forward compatibilit= y. And of course, it should be tested
and verified as worked.

Do you like that approach? I don=E2=80=99t think so. = So I guess only backward compatibility
should be supported to mak= e the snapshot code simple and robust.

Thank= s,
Vitaliy Gusev




--=
Mario.
--000000000000e2ca2a05fc8707fc-- From nobody Thu May 25 18:40:04 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRxgp2khrz4WXgg; Thu, 25 May 2023 18:40:22 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRxgm5q9Tz414f; Thu, 25 May 2023 18:40:20 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-4f004cc54f4so2956291e87.3; Thu, 25 May 2023 11:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685040017; x=1687632017; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=/ZvE/4ZJL6lRGsKtZoVnqNP57nQpKxBAIEy13pjO8pU=; b=W2arN12tamDFNBgMSDzm+Ttym9+cAt+M6XINwN1XHfxfV780k2icq1jJK+403PpQQZ YvHvGvWruLoFPKHOLELznL/v0t+tC0bKO/HFMy3mG5XZB+soZKJ6gUPFmoC9FuAT2DyJ tt/33P69vR9Qei9LKgAir+DZU/k9Ynh9iPyXRDkhUVEnVI61tYlNtKs3178JKUcAbbIg R2sB6hQFB4CwVX+0OGhtNabKIESDMM1BbWsT2sU+WuxQ50NnJXCccKn4fqyD83OWo2is eN94WYZjpd4vfK3uG1HbYjtbaVqSSC+gdGaktILbJwI8rE/21JphYu6XEK1DQxxTc6lr anHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685040017; x=1687632017; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/ZvE/4ZJL6lRGsKtZoVnqNP57nQpKxBAIEy13pjO8pU=; b=fD2kgkejtgjJRlMLOnehYuTVemzHPnQJmru8DU8RkfxV01Y+t3rY3LFRJsYkH/Uu6C Kxcn8Wrh2Pkh2MAJSIdav2Tps6npUp/ieo9qNA9EVo3Uyh/XbRLRwwE/KsXyZBe7mQkp CZKKc/x3Fkw4NOCSrBnsFyGcZKohV3E6wvmPWXV85ijaUd45Cl/EJzQc1qUyrflpFEFw u8R8+vtHO1pMY5hfzKEFnTpxRmPY7n1dkBcP7NPLsZG6A4pv9dZm/32rlNTp1xed7Hv4 W0cC+p4nsTuokSA20oEoh0mFbVNaqjF0NNV+jjUAMDlnBtkgi2R/8StGgb0C+pZtZra7 kiuQ== X-Gm-Message-State: AC+VfDxh+e8sdDTdy/N/hnf4vOKyiomeI/FcZZ/ZcczhvWBSiUlsjS0o N2sf8CKFpBjJvQQ2XAM5hDzdG4MDI7fWxw== X-Google-Smtp-Source: ACHHUZ6rCYLeKZS+fTF+f8d/Q7atXAwYPBKoF0pLOw/NgqwRmN8pzJB2BV7pEwprrL+x8IHR+BWUpw== X-Received: by 2002:ac2:5d24:0:b0:4eb:104b:bf61 with SMTP id i4-20020ac25d24000000b004eb104bbf61mr6497924lfb.58.1685040016541; Thu, 25 May 2023 11:40:16 -0700 (PDT) Received: from smtpclient.apple ([78.140.234.98]) by smtp.gmail.com with ESMTPSA id p21-20020ac246d5000000b004f3ba3b948dsm293112lfo.284.2023.05.25.11.40.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2023 11:40:15 -0700 (PDT) From: Vitaliy Gusev Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9EC57A81-2637-440C-A2F4-5E1697C8811A" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Thu, 25 May 2023 21:40:04 +0300 In-Reply-To: Cc: Tomek CEDRO , virtualization@freebsd.org, freebsd-hackers@freebsd.org To: Mario Marietto References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <8FE14143-1AA9-418E-A497-FEFB99BF6B9F@gmail.com> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QRxgm5q9Tz414f X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9EC57A81-2637-440C-A2F4-5E1697C8811A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 May 2023, at 19:22, Mario Marietto = wrote: >=20 > Vitaliy, >=20 > what happens if I clone your repo as source code on my FreeBSD system. = Can I test your code directly or not ? Anyway,I think that,before doing = this,I need to follow some kind of tutorial,to understand how the = workflow is. Otherwise I will be not able to test and stress it.=20 You should build kernel and tools, install it. Then you can run bhyve, = bhyvectl to deal with suspend/resume. Please follow=20 9.5. Building and Installing a Custom Kernel https://docs.freebsd.org/en/books/handbook/book/#kernelconfig-building Make sure that BHYVE_SNAPSHOT is enabled. Also look at build(7): https://man.freebsd.org/cgi/man.cgi?build(7) >=20 > On Thu, May 25, 2023 at 3:40=E2=80=AFPM Vitaliy Gusev = > wrote: >>=20 >>=20 >>> On 25 May 2023, at 04:30, Tomek CEDRO > wrote: >>>=20 >>> On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: >>>> Protecting requires more efforts and it should be clearly defined: = what is purpose. If >>>> purpose is having checksum with 99.9% reliability, NVLIST HEADER = can be widen >>>> to have =E2=80=9Cchecksum=E2=80=9D key/value for a Section. >>>=20 >>> Well, this could be optional but useful to make sure snapshot did = not >>> break somehow for instance backup medium error or something like >>> that.. even more maybe a way to fix it.. just a design stage idea :- >>=20 >> Yes, new format can have checksum of a Section data if implemented. >>=20 >>>=20 >>>=20 >>>> If purpose is having crypto verification - I believe sha256 program = should be your choice. >>>=20 >>> My question was more specific to availability of that feature >>> (integrity + repair) rather than specific format :-) >>>=20 >>> The use case here is having a virtual machine (it was VirtualBox) = with >>> a bare os installed, plus some common applications, that is = snapshoted >>> at some point in time, then experimented a lot, restored from >>> snapshot, etc. I had a backup of such vm + snapshot backed up that = got >>> broken somehow. It would be nice to know that something is broken, >>> what is broken, maybe a way to fix :-) >>=20 >>=20 >> =E2=80=9CIntegrity" is a very broad term. What checksum algorithm is = fine enough? >> =20 >> For the instance, ZFS has several options for checksum: >>=20 >> = checksum=3Don|off|fletcher2|fletcher4|sha256|noparity|sha512|skein|edonr >> =20 >>=20 >> Having checksum for a filesystem is strongly recommended. However, If = consider image format, >> it doesn=E2=80=99t need to care about consistency in a file itself. = As example (!) - binary files in a system. >> They don=E2=80=99t have checksum integrated, validation is done by = another program - pkg or another. >>=20 >>=20 >>>=20 >>>=20 >>>> Why do you need modify snapshot image ? Could you describe more? Do = you >>>> modify current 3 snapshot files? >>>=20 >>> Analysis that require ram / nvram modification? Not sure if this is >>> already possible, but may come handy for experimenting with uefi and >>> maybe some OS (features) that will not run with unmodified nvram :-P >>=20 >>=20 >> Sorry I don=E2=80=99t get, why do you need to modify snapshot image, = but not directly vmem on the running >> VM? >>=20 >> Another question, checksum and modifying image - two mutual exclusive = things.=20 >>=20 >>>=20 >>>=20 >>>> If you are talking about compatibility of a Image format - it = should be compatible in >>>> both directions, at least for not so big format changes. >>>>=20 >>>> If consider overall snapshot/resume compatibility - I believe = forward compatibility >>>> is not case and target. Indeed, why do you need to resume an image = created by >>>> a higher version of a program? >>>=20 >>> This happens quite often. For instance there is a bug in application >>> and I need to revert to (at least) one step older version. Then I am >>> unable to work on a file that I just saved (or was autosaved for = me). >>> Firefox profile settings let be the first example. KiCAD file format >>> is another example (sometimes I need to switch to a devel build to >>> evade a nasty blocker bug then anyone else that uses a release is >>> blocked for some months including me myself). >>=20 >> Any additional thing has a cost of development, testing and support. = Current >> Implementation doesn=E2=80=99t support compatibility at all. Having = compatibility in both >> directions can be hard. >>=20 >> For example, if some variable is removed in bhyve, backward = compatibility is fine, >> but forward compatibly is not possible unless that removed variable = is being saved >> into a snapshot image just for forward compatibility. And of course, = it should be tested >> and verified as worked. >>=20 >> Do you like that approach? I don=E2=80=99t think so. So I guess only = backward compatibility >> should be supported to make the snapshot code simple and robust. >>=20 >> Thanks, >> Vitaliy Gusev >>=20 >>=20 >=20 >=20 > --=20 > Mario. --Apple-Mail=_9EC57A81-2637-440C-A2F4-5E1697C8811A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25 = May 2023, at 19:22, Mario Marietto <marietto2008@gmail.com> = wrote:

Vitaliy,

what happens if I = clone your repo as source code on my FreeBSD system. Can I test your = code directly or not ? Anyway,I think that,before doing this,I need to = follow some kind of tutorial,to understand how the workflow is. = Otherwise I will be not able to test and stress it. =


You = should build kernel and tools, install it. Then you can run bhyve, = bhyvectl to deal with suspend/resume.

Please = follow 

 9.5. Building and Installing a Custom = Kernel



Make sure that = BHYVE_SNAPSHOT is enabled.

Also look at = build(7):




On Thu, May 25, 2023 at 3:40=E2=80=AFPM Vitaliy = Gusev <gusev.vitaliy@gmail.com> = wrote:


On 25 May 2023, at 04:30, Tomek CEDRO <tomek@cedro.info> wrote:

On = Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote:
Protecting requires more efforts and it should be clearly = defined: what is purpose. If
purpose is having checksum with 99.9% = reliability, NVLIST HEADER can be widen
to have =E2=80=9Cchecksum=E2=80= =9D key/value for a Section.

Well, this could be = optional but useful to make sure snapshot did not
break somehow for = instance backup medium error or something like
that.. even more maybe = a way to fix it.. just a design stage idea = :-

Yes, new format can have checksum of a = Section data if implemented.



If purpose is = having crypto verification - I believe sha256 program should be your = choice.

My question was more specific to = availability of that feature
(integrity + repair) rather than = specific format :-)

The use case here is having a virtual machine = (it was VirtualBox) with
a bare os installed, plus some common = applications, that is snapshoted
at some point in time, then = experimented a lot, restored from
snapshot, etc. I had a backup of = such vm + snapshot backed up that got
broken somehow. It would be = nice to know that something is broken,
what is broken, maybe a way to = fix = :-)


 =E2= =80=9CIntegrity" is a very broad term. What checksum algorithm is fine = enough?
 
For the instance,  ZFS has = several options for checksum:

checksum=3Don|off|fletcher2|fletcher4|sha256|noparity|sha5= 12|skein|edonr

    =   =  


Having = checksum for a filesystem is strongly recommended. However, If consider = image format,
it  doesn=E2=80=99t need to care about = consistency in a file itself. As example (!)  - binary files in a = system.
They don=E2=80=99t have checksum integrated, = validation is done by another program  - pkg or = another.




Why do you = need modify snapshot image ? Could you describe more? Do you
modify = current 3 snapshot files?

Analysis that require ram = / nvram modification? Not sure if this is
already possible, but may = come handy for experimenting with uefi and
maybe some OS (features) = that will not run with unmodified nvram = :-P


Sorry I = don=E2=80=99t get, why do you need to modify snapshot image, but not = directly vmem on the = running
VM?

Another question, = checksum and modifying image - two mutual exclusive = things. 



If you are = talking about compatibility of a Image format - it should be compatible = in
both directions, at least for not so big format changes.

If = consider overall snapshot/resume compatibility - I believe  forward = compatibility
is not case and target. Indeed, why do you need =  to resume an image created by
a higher version of a = program?

This happens quite often. For instance = there is a bug in application
and I need to revert to (at least) one = step older version. Then I am
unable to work on a file that I just = saved (or was autosaved for me).
Firefox profile settings let be the = first example. KiCAD file format
is another example (sometimes I need = to switch to a devel build to
evade a nasty blocker bug then anyone = else that uses a release is
blocked for some months including me = myself).

Any additional = thing has a cost of development, testing and support. = Current
Implementation doesn=E2=80=99t support compatibility = at all. Having compatibility in both
directions can be = hard.

For example, if some variable is removed = in bhyve, backward compatibility is fine,
but forward = compatibly is not possible unless that removed variable is being = saved
into a snapshot image just for forward compatibility. = And of course, it should be tested
and verified as = worked.

Do you like that approach? I don=E2=80=99= t think so. So I guess only backward compatibility
should be = supported to make the snapshot code simple and = robust.

Thanks,
Vitaliy = Gusev




-- =
Mario.

= --Apple-Mail=_9EC57A81-2637-440C-A2F4-5E1697C8811A-- From nobody Thu May 25 19:31:13 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRyqC24Hvz4Wbtb for ; Thu, 25 May 2023 19:31:51 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRyqB1ZFCz49Lp for ; Thu, 25 May 2023 19:31:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=CIhZEsCA; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::1130 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-565a63087e9so1531837b3.2 for ; Thu, 25 May 2023 12:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685043109; x=1687635109; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KMFOyLKrXV+CSaL4/VOwEiZetB2t041p+r8WzOBMQa8=; b=CIhZEsCAC/tGi8vBCa61oA2cILCCwM3tQjHgAvCY7HS4gK97DCHl3OkMYvAGE3OMe/ IU0rCekUNzzZROO9G/Kr0VhuzHQ2bosB1HvRps4/PpwUph4Qk1uvk7YD33tulLBgW04g A+AM3a5MQZwJCjffk3T0hu3/xOJYIJM9KuBVmnprFem0Ayx/gUGkMNhGOq4+xgIOfIZE tdMKjL50v3wTOexNCSkbIxKuOH+ZJX0XIni4lGdomWW7H2DOMDnDYy1quT2jPG3gF5Sm 7eaarccvTrJDDRi87NmBalqoSCIl63XvBzSGZOWtecvtkduC9p0G7ljP3cO2ejEXwo2/ eK3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685043109; x=1687635109; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KMFOyLKrXV+CSaL4/VOwEiZetB2t041p+r8WzOBMQa8=; b=FlddF56QQ/YTr7bGo3qwH9MjRWQfmx/gc8RDu/KCBdpKS/RVJUhblnVwFocDlPPi08 SyUNgtxjFAbeGVxYW5pBINPSaIccNZsX1hADglhTUHAGOK1SbKd/Xm5K7uMvIGQokgYT G+a1u0iTybHMkXc5NnhcxfMbJBZdUlmgLU0bvytMFK57OsztVBT/uwzjt7tsUKwr1Qxe dEnXIqOHajByy0rnKhbAadS5Bg5jyHJlo/K5ukFXuvOhrOl1KpNRyQA68HzWVbLj+UZn MSIaAE25QAVg0S5Awo/9LbbVd7KIfHL7sb22fjrzvaieJ+wHn7r5UOPuieynLI9IQFSi KETA== X-Gm-Message-State: AC+VfDwSgzWYcYjnX+M7qyiLzEsAgY0pDKMjhqxd0Eyjea9jkD1UP13f iBHaI+Pjfdk/jX3hSatfN2gFE/rRwGXmvSJ/weOPvUlJTUmhXA== X-Google-Smtp-Source: ACHHUZ7/WK7yRFX0XIMXG9AM+ORSrwxgar4KByzOCP+M3ZCIdf29LHpwNYouWrYqd2/dbbuSCkAF0Y+Oa8uC5WQPR80= X-Received: by 2002:a0d:d612:0:b0:565:1b47:a6cd with SMTP id y18-20020a0dd612000000b005651b47a6cdmr752866ywd.50.1685043109279; Thu, 25 May 2023 12:31:49 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> In-Reply-To: From: Mario Marietto Date: Thu, 25 May 2023 21:31:13 +0200 Message-ID: Subject: Re: How to blacklist the nouveau driver on FreeBSD.... To: Theron Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000f5bc9f05fc89abef" X-Spamd-Result: default: False [-2.35 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.65)[0.647]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1130:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QRyqB1ZFCz49Lp X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000f5bc9f05fc89abef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. I've asked for some clarifications on the Blender forum about the reason why a part of the nouveau userland is called within the linuxulator,instead of the nVidia one. You can read here : https://devtalk.blender.org/t/why-blender-cycles-is-not-able-to-detect-my-g= pu-s-and-cuda-within-the-ubuntu-linuxulator/27777 this is what he said : I can=E2=80=99t give you full help with this, but I will share some informa= tion based on what I can gather from this post and resources online. - Linuxulator appears to be some kind of compatibility layer. It=E2=80=99s= not guaranteed to work with all applications, and CUDA is likely to be one o= f the application types it will have issues with. Maybe try verifying that applications that use the GPU work, then CUDA applications, then look in= to getting Cycles rendering working with CUDA. This may not be a Blender issue, but a Linuxulator issue. - Depending on how you installed your GPU drivers on =E2=80=9CLinux=E2=80= =9D, you might not have all the packages required to run CUDA applications. For example= , on some Linux distributions I had to install packages like libcuda1 and libnvoptix1 to use CUDA and OptiX on Linux. - As you pointed out, the error libGL error: failed to load driver: nouvea= u suggests Blender is trying to load the nouveau driver. Typically when installing the Nvidia proprietary driver, the loading of the nouveau drivers gets disabled. Maybe the Nvidia GPU drivers weren=E2=80=99t inst= alled properly? Or do you need to disable nouveau manually? Or is this just so= me issue with the Linuxulator? - You also have errors related to =E2=80=9Copening a display=E2=80=9D (ope= ning the Blender GUI). This could be related to the GPU driver issue discussed before, or maybe you need to do a bit of extra setup to get GUI applications workin= g in Linuxulator. Such as setting up a desktop environment within your Linuxulator? It also might be easier to test Blender with CUDA rendering if you started with command line rendering rather than GUI render. - Command Line Rendering =E2=80=94 Blender Manual 3 Sorry if I=E2=80=99m unable to help much with this. On Thu, May 25, 2023 at 11:47=E2=80=AFAM Mario Marietto wrote: > Can you figure out a method to do what I want to do ? If we are able to > "connect" the nVidia driver to the CG / graphic tool instead of the nouve= au > one,a lot of cool features will be unfrozen. For example we could try to > run Unreal Engine 5 within the linuxulator,Davinci Resolve,Maya 3d,a lot = of > cool stuff will use the nvidia driver and it will work great. > > On Thu, May 25, 2023 at 11:10=E2=80=AFAM Mario Marietto > wrote: > >> Smplayer behaves the same as blender. I think this is a general behavior= . >> Check below what happens when I run it within the linuxulator : >> >> root@marietto:/mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash >> >> root@marietto:/# smplayer >> >> QStandardPaths: error creating runtime directory '/var/run/user/1001' (N= o >> such file or directory) >> This is SMPlayer v. 22.7.0 (revision 10091) running on Linux >> libGL error: glx: failed to create dri2 screen >> *libGL error: failed to load driver: nouveau* >> >> >> >> On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron = wrote: >> >>> On 5/24/23 04:43, Mario Marietto wrote: >>> > since the nouveau driver can't be blacklisted within the Linuxulator >>> > because it's impossible to run "sudo update-initramfs -u" inside of >>> > it. For this reason,I would ask if in your opinion the nouveau driver >>> > can be blacklisted directly in FreeBSD or in some other way. Thanks. >>> > >>> FreeBSD does not contain the nouveau kernel module so there is nothing >>> to blacklist. >>> >>> > He says that he created a Python script for updating Nvidia drivers o= n >>> > CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please give >>> > a look to an old post created by me some time ago and you will see : >>> > >>> > >>> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_= nouveau_driver_within_the/ >>> > >>> These libGL errors are from Mesa libGL, which is trying to use the >>> userspace part of nouveau (which is part of the Mesa project), >>> presumably based on Nvidia GPU's PCI ID being known to Mesa, despite >>> there being no nouveau kernel interface available. >>> >>> Since you are trying to use Nvidia's binary driver (the only one which >>> works on FreeBSD), Blender should have never loaded Mesa's libGL in the >>> first place - there is most likely a configuration problem here with >>> libglvnd, the component responsible for choosing the correct libGL >>> implementation. >>> >>> When Blender fails to detect CUDA this has nothing to do with libGL and >>> absolutely nothing to do with nouveau - have you found any other CUDA >>> program to work in linux compat? >>> >>> Theron >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --000000000000f5bc9f05fc89abef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I've asked for so= me clarifications on the Blender forum about the reason why a part of the n= ouveau userland is called within the linuxulator,instead of the nVidia one.= You can read here :



this is what he said :<= /div>
=C2=A0

I = can=E2=80=99t give you full help with this, but I will=20 share some information based on what I can gather from this post and=20 resources online.

  • Linuxulator appears to be some kind of compatibility layer. It=E2=80=99s= not=20 guaranteed to work with all applications, and CUDA is likely to be one=20 of the application types it will have issues with. Maybe try verifying=20 that applications that use the GPU work, then CUDA applications, then=20 look into getting Cycles rendering working with CUDA. This may not be a=20 Blender issue, but a Linuxulator issue.

  • Depending on how you installed your GPU drivers on =E2=80=9CLinux=E2=80= =9D, you might not have all the packages required to run CUDA applications. For=20 example, on some Linux distributions I had to install packages like l= ibcuda1 and libnvoptix1 to use CUDA and OptiX on Linux.=

  • As you pointed out, the error libGL error: failed to load driver: = nouveau suggests Blender is trying to load the nouveau driver. Typically when=20 installing the Nvidia proprietary driver, the loading of the nouveau=20 drivers gets disabled. Maybe the Nvidia GPU drivers weren=E2=80=99t install= ed=20 properly? Or do you need to disable nouveau manually? Or is this just some= =20 issue with the Linuxulator?

  • You also have errors related to =E2=80=9Copening a display=E2=80=9D (ope= ning the=20 Blender GUI). This could be related to the GPU driver issue discussed=20 before, or maybe you need to do a bit of extra setup to get GUI=20 applications working in Linuxulator. Such as setting up a desktop environme= nt within your Linuxulator?
    It also might be easier to test Blender with CUDA rendering if you started = with command line rendering rather than GUI render.

  • Comma= nd Line Rendering =E2=80=94 Blender Manual 3

Sorry if I=E2=80=99m unable to help much with this.


On Th= u, May 25, 2023 at 11:47=E2=80=AFAM Mario Marietto <marietto2008@gmail.com> wrote:
Can you figure= out a method to do what I want to do ? If we are able to "connect&quo= t; the nVidia driver to the CG / graphic tool instead of the nouveau one,a = lot of cool features will be unfrozen. For example we could try to run Unre= al Engine 5 within the linuxulator,Davinci Resolve,Maya 3d,a lot of cool st= uff will use the nvidia driver and it will work great.

On Thu, May 25, = 2023 at 11:10=E2=80=AFAM Mario Marietto <marietto2008@gmail.com> wrote:
Sm= player behaves the same as blender. I think this is a general behavior. Che= ck below what happens when I run it within the linuxulator :
=
root@marietto:/mnt/zroot2/zroot2 # chro= ot /compat/ubuntulunar /bin/bash

root@marietto:/# smplayer=C2=A0

QStandardPaths: error creating runtime d= irectory '/var/run/user/1001' (No such file or directory)
This is SMPlayer v. 22.7.0 (revision 10091) running on Linux
libGL error: glx: failed to create dri2 screen
libGL error: failed to load driver: nouveau



On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron <theron.tarigo@gmail.com= > wrote:
On 5= /24/23 04:43, Mario Marietto wrote:
> since the nouveau driver can't be blacklisted within the Linuxulat= or
> because it's impossible to run "sudo update-initramfs -u"= ; inside of
> it. For this reason,I would ask if in your opinion the nouveau driver =
> can be blacklisted directly in FreeBSD or in some other way. Thanks. >
FreeBSD does not contain the nouveau kernel module so there is nothing
to blacklist.

> He says that he created a Python script for updating Nvidia drivers on=
> CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? plea= se give
> a look to an old post created by me some time ago and you will see : >
> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_no= uveau_driver_within_the/
>
These libGL errors are from Mesa libGL, which is trying to use the
userspace part of nouveau (which is part of the Mesa project),
presumably based on Nvidia GPU's PCI ID being known to Mesa, despite there being no nouveau kernel interface available.

Since you are trying to use Nvidia's binary driver (the only one which =
works on FreeBSD), Blender should have never loaded Mesa's libGL in the=
first place - there is most likely a configuration problem here with
libglvnd, the component responsible for choosing the correct libGL
implementation.

When Blender fails to detect CUDA this has nothing to do with libGL and absolutely nothing to do with nouveau - have you found any other CUDA
program to work in linux compat?

Theron


--
Mario.


--
Mario.


--
Mario.
--000000000000f5bc9f05fc89abef-- From nobody Thu May 25 19:34:56 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRyv21nxmz4Wc5y for ; Thu, 25 May 2023 19:35:10 +0000 (UTC) (envelope-from naman@freebsdfoundation.org) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRyv10Bshz4BHk for ; Thu, 25 May 2023 19:35:09 +0000 (UTC) (envelope-from naman@freebsdfoundation.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsdfoundation.org header.s=gfnp-20170908 header.b=N7OQERrE; spf=pass (mx1.freebsd.org: domain of naman@freebsdfoundation.org designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=naman@freebsdfoundation.org; dmarc=none Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-561b7729a12so13942117b3.1 for ; Thu, 25 May 2023 12:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; t=1685043307; x=1687635307; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=+6ooOalcYSynBVHcslWLsZXd/Olw5Ll2Y3Ygf/3WRhs=; b=N7OQERrERxfThrv4YFJerNUFWIv0/hjJpwXnmhlfdIUArAxeTj3pyuVC/BPMCrINS4 IzpssrX8OYaDnVp+xbFIbMHGS9hzR++U5G1dhq4EwAOKBehFfVMbTstSajvvSJPqBp5W oe8GFnJZOpn7eySb22x0xOK3YglEEcDifv0swdUbPir91c8uowGwzfTyx7dwbNGznFew epnhQFYZHlULZE2rDT6qtRHgS63fZsR7zQhdf1Msf/Q4Vt624agA9LQdAobFodOa09bp 0h/3ZJhFyfR8SrKnXOz6dZR66ml/a5RTKhT9go9Yy0RQeX9lNcaUmu3rvM9oFcR0pWhx dPSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685043307; x=1687635307; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+6ooOalcYSynBVHcslWLsZXd/Olw5Ll2Y3Ygf/3WRhs=; b=VvNhtaqJX4nDCKuwuOpP9J4w0Gy8czTWCdO8zkbYOTJFMjotFd1gcz0JdrS//nI3Eu B5OJbhnjnzTuYQZBavzUDMdb8T43DEzhhcH8BaJLuzMSc4CO3Aog9XCXBuWCBGKVTFzQ sRslxjZeDZZq1pYw9dUh8Y6HMDiRy4vEjU87KULMdX1HheiGkpOeRtbFJm55smPMHTqd hWtmTmRZU1ImjQoEdOf4UaxjD3HCdxvfO9JVJsWKzAVC4m2o/gGvvVagTm6aSftNto3v cF7TDOONoYFeD0Qnknv0OzVn7904BxhDnTkk4lCkLqtms1tCONBv2fjyYvJAsgf8zucn 87Uw== X-Gm-Message-State: AC+VfDxc8hBmeTGnmSmV096ZD217DycpV8HCDmWaG9+hNkZeZDx0HDpF cPyKnIl8gIickMkds0nEd67la9NnlGXZLnnTo7cKUmZoBH1rPM56CoTw9w== X-Google-Smtp-Source: ACHHUZ6HrXL3FU3Xy01dbKFWnSgqrOJPufcK5nFHocql5HbTxa7tpFhOax6zePsYY57SZ56FWJRv1ZCz8pTT59o+5Qk= X-Received: by 2002:a0d:d508:0:b0:55a:64b3:fc13 with SMTP id x8-20020a0dd508000000b0055a64b3fc13mr476543ywd.1.1685043307585; Thu, 25 May 2023 12:35:07 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Naman Sood Date: Thu, 25 May 2023 15:34:56 -0400 Message-ID: Subject: APIC interrupting me while stepping through a kernel with kgdb To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.920]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1134:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsdfoundation.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_WP_URI(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QRyv10Bshz4BHk X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello! I've been following this guide[1] to get kgdb to debug a FreeBSD guest on bhyve - I have a WIP patch for pfsync that I want to debug. I'm at the point where I can set breakpoints in if_pfsync.c and get them to break when I hit them. However, when I step/next from there, control always goes to the lapic_handle_timer(), which does its APIC timer things, returns control to the line where I set the breakpoint... and then immediately goes to the timer again, since presumably a timer tick has happened between me pressing Return repeatedly. Is there a way to get around this? Either turn off the timer (doesn't sound like a good idea?) or get kgdb to ignore it so I can debug the rest of the kernel? Running skip at the timer code didn't seem to help. Thanks, Naman. [1]: https://freebsdfoundation.org/wp-content/uploads/2014/07/Using-bhyve-for-FreeBSD-Development.pdf From nobody Thu May 25 20:27:26 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QS03R1JQkz4Wg8J for ; Thu, 25 May 2023 20:27:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QS03Q5dvvz4LRL for ; Thu, 25 May 2023 20:27:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-3f6c6020cfbso8095501cf.2 for ; Thu, 25 May 2023 13:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685046449; x=1687638449; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=oT2IArNMLzo9RrAqGpVRyDNaUY37FC3c/vnWvJHuUCI=; b=e7rY5JaWur4Ro6hqRpj1h1moLQfZav/jphIQG39Tm4PV8sURO511CoHuDNSgGnFwSG ATUrp1cgcytXMaNG4KM+a6Q/E82WnLiXCdXg7xza96yAjxORB942uv1VCB2S1c2hBYpL zoqcoJCgA0cUejMWlwMWQu1Knb/CapIiWX9SXE5WqXctJ9ueFqQ4BjrfwFBTXP6Wb0O1 MH/4nt4ve2to4Z0rJ7PagVIhK9eqod6FmVEAxqDNE3sM/bQM/HyUvptdK2E7s1vRbJRw QJwx3oI0IY45/1xcWRMR4r3bJeXquCIwYwXyvZ6LWTWxaP+DUbdnhhOBcewhU46Q8SkX CtHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685046449; x=1687638449; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oT2IArNMLzo9RrAqGpVRyDNaUY37FC3c/vnWvJHuUCI=; b=LVj1gl/x+ADRGlUK5qiSdDblqn0BboJSL8xj49AEm2ptRgcpLwY5UqBQqhOJ6gwgwM rFZAGxFyrZpRJgM/2/q9oAQ1A+0D+JHEIbixL/RlVgR382lM4IJhpEmLzlEg7r9fD+wx S2dMDmJ1bsPM56ESvLdkmU5JD/9UXEQmJZwn2D0hcC74IBti4u0KuZHyJfPEoIXJfDIm T/bp4TtP5Lygn/3lHoVnNCku4YYrUJXQXCxGY25lFqHF4DQjag6CSU4oVq+FOBjfsVrJ nShou8Fc4FoGp6LjjtE3HEwDwMmLUuegIcD17KazCKJ3M98Wj8XPBwgy9YgjxeS919em c5NQ== X-Gm-Message-State: AC+VfDypMXZMTYj62DGFFQpjMSLlJw0TvguiuthgcJjv2LPEC/4dZ4Oo J4dcZBVWPE+Vek5TreytPQ8gFl1pwv0= X-Google-Smtp-Source: ACHHUZ7/LDnWCvFnk64RUMk1ZOLGIplWA43hfNwo7L6pgln55Bmx5gmWXb6yKNc20cbNJ12X8O02Jg== X-Received: by 2002:ac8:7d82:0:b0:3f2:421:4de5 with SMTP id c2-20020ac87d82000000b003f204214de5mr1075027qtd.26.1685046449051; Thu, 25 May 2023 13:27:29 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id e13-20020ac8490d000000b003f7369c7302sm679323qtq.89.2023.05.25.13.27.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 May 2023 13:27:28 -0700 (PDT) Date: Thu, 25 May 2023 16:27:26 -0400 From: Mark Johnston To: Naman Sood Cc: freebsd-hackers@freebsd.org Subject: Re: APIC interrupting me while stepping through a kernel with kgdb Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4QS03Q5dvvz4LRL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Thu, May 25, 2023 at 03:34:56PM -0400, Naman Sood wrote: > Hello! > > I've been following this guide[1] to get kgdb to debug a FreeBSD guest > on bhyve - I have a WIP patch for pfsync that I want to debug. I'm at > the point where I can set breakpoints in if_pfsync.c and get them to > break when I hit them. However, when I step/next from there, control > always goes to the lapic_handle_timer(), which does its APIC timer > things, returns control to the line where I set the breakpoint... and > then immediately goes to the timer again, since presumably a timer > tick has happened between me pressing Return repeatedly. > > Is there a way to get around this? Either turn off the timer (doesn't > sound like a good idea?) or get kgdb to ignore it so I can debug the > rest of the kernel? Running skip at the timer code didn't seem to > help. Which revision of FreeBSD are you running? I believe this recent commit will address the problem you're describing, but you won't have it unless you're running the main branch: https://cgit.freebsd.org/src/commit/?id=fefac543590d From nobody Thu May 25 20:33:21 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QS0BQ3Dgrz4Wgcv for ; Thu, 25 May 2023 20:33:34 +0000 (UTC) (envelope-from naman@freebsdfoundation.org) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QS0BQ1X3hz4MpP for ; Thu, 25 May 2023 20:33:34 +0000 (UTC) (envelope-from naman@freebsdfoundation.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-561b65b34c4so2546907b3.1 for ; Thu, 25 May 2023 13:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; t=1685046813; x=1687638813; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WAmuR+dWyvRMQGUfQbPRsAL6wCeOvrNC78caM0Gjntg=; b=lL33zvkDpHxRvoalO/uDnewgZYRyUUxw4Ntz8QjQP/oEdcBuRK0WO1tx9rK6XJM2Q6 thRarfamcksZrivFu/IP+JUhsOzrZneZ7npsOs3u5MGhKzCdMlaCbO1qRr13qMM+uuaN URnailgYNSLu0hGLOPypnA5CG8dZL0wRTVzNM0Pj219STJ9Hfip+rjDw+l3LOGFtwOU9 lOYXH5yyBggV4I7x2nrIvAck8F9U+Z6dCjNFP6CTxfMyxGBxly1X5q1Td/EzowxSmCHk PKjf8RvJSgdDX0JCbPR1TaeoiZJxJEgXmaNoIWUEBXM1C+LWIw+eu+zbtIsc+uLjOL3K NiAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685046813; x=1687638813; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WAmuR+dWyvRMQGUfQbPRsAL6wCeOvrNC78caM0Gjntg=; b=Ql7fs6aF+Z+lWh7jSN5toxx8XckFRi7mXRrey6jLoKuf3l4BNlLDM64f0dEE2b/+aE GqFu+4a/VsG+Sj3iLpMnkOBqhYsKYiABRW6qJVMdYv7UkI0s3lgfoLHxVQ66tfPUHyK7 LzKbajn8g7IIxVd3Y2z/4XFeumiMBs9LMBWGjV4PhSDbIwbp5H+68uN4VcZSC04US609 G9oG4weey+PvycJqBpa723nRZO8KjoDpZ7z32dMwFfNhew40Gu34Z9tFLb+RlzSIxYic Of/AdkmjDuExIJS8HG1jqVFhhpV7D1PGJPUdrtiW80TlzEpyyeTsuQW2uJoSiGHyEXU5 FV9Q== X-Gm-Message-State: AC+VfDwN28tnF8F1iJ8gP4w/NCyGMnIWgTktpV1qS9y4om3tlLnRQQxd kD9A3jAjdLLVtrcADcsCNZPTYOddoSxZiMahM5PK3iNtqD8iCuFrLco= X-Google-Smtp-Source: ACHHUZ6ztmEEWzGFTEs2Tye7B/Ai9a7ZZfW8vLY34fwpqsDahFb4bDGHhBhPTxCE4Kci6SPRffcShBmAB0YYbl3it4o= X-Received: by 2002:a0d:e642:0:b0:559:f18d:ee94 with SMTP id p63-20020a0de642000000b00559f18dee94mr784795ywe.10.1685046812875; Thu, 25 May 2023 13:33:32 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Naman Sood Date: Thu, 25 May 2023 16:33:21 -0400 Message-ID: Subject: Re: APIC interrupting me while stepping through a kernel with kgdb To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QS0BQ1X3hz4MpP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Oh. How convenient! I'm running 14.0-CURRENT, though I may have delayed system updates long enough to not have this patch at the moment. Let me get back to you after I run updates and retry - thanks! Naman. On Thu, May 25, 2023 at 4:27=E2=80=AFPM Mark Johnston w= rote: > > On Thu, May 25, 2023 at 03:34:56PM -0400, Naman Sood wrote: > > Hello! > > > > I've been following this guide[1] to get kgdb to debug a FreeBSD guest > > on bhyve - I have a WIP patch for pfsync that I want to debug. I'm at > > the point where I can set breakpoints in if_pfsync.c and get them to > > break when I hit them. However, when I step/next from there, control > > always goes to the lapic_handle_timer(), which does its APIC timer > > things, returns control to the line where I set the breakpoint... and > > then immediately goes to the timer again, since presumably a timer > > tick has happened between me pressing Return repeatedly. > > > > Is there a way to get around this? Either turn off the timer (doesn't > > sound like a good idea?) or get kgdb to ignore it so I can debug the > > rest of the kernel? Running skip at the timer code didn't seem to > > help. > > Which revision of FreeBSD are you running? I believe this recent commit > will address the problem you're describing, but you won't have it unless > you're running the main branch: > https://cgit.freebsd.org/src/commit/?id=3Dfefac543590d From nobody Fri May 26 09:32:54 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QSKVP0hTzz4WV1Z for ; Fri, 26 May 2023 09:33:33 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QSKVN27gdz4K7p for ; Fri, 26 May 2023 09:33:32 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=PvkBc2UE; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b2b as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-bacfa9fa329so526507276.0 for ; Fri, 26 May 2023 02:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685093611; x=1687685611; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+Pb58O9SfemGWyyqrlDmz5nfv90cItKIgAIkBIVdpw0=; b=PvkBc2UEbopWqnHFcODALKkr70DJxXKCS1wCcWLJWko27qEjiTNq8t//5K3qvTfYjX UIN2pf2b9wNffajHFb8MzTxcQGj4o+Blz5w8dB0Hcc+3dXWFrN1ONT0D8xo11MSSUjaX PgR0z8jX8S8ImdVvN9CCTNJiWDW/DXUChcLImc7Ih6WgVKJSKNMwWQYwDCMBAdk56jrb GnnJ1cu3pdQcLhsL6DGzvcqtoFY1Fj818qI11olate++dVY1JdPPbza5k11yyZhmmU/d ZfostKheyn7M8rXXD1E4I1cK0EeqFQxSfoTp46DkR+Yi/D7dCTTzYM+W71Yz21vDDI4Q i/Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685093611; x=1687685611; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+Pb58O9SfemGWyyqrlDmz5nfv90cItKIgAIkBIVdpw0=; b=X+U4fxSvubDHKQj9OEX0vbewVLDWKFem/cFmggTc82C5c60tlXcomZ55cKWzcswVMG f+ulcv2Ty7Jnbn1s/+wR7IfZriu+j9iK3/2YAiMY4RWB0mjH/tu6IIdxKeQNImBoLCOy C2xUGN1oLl8NaptjVv3TH1Oxst/sPuNVlJ2raTAwng1yRcdjETRy0KG4y68L2I49lIeF jAhmMLpWFjSRhO3JMK/heVzCBM2iMR0+gpkUS+QxCAhMei5flOIVyYh9s4LIzqS35AU8 /rosl/H/P21wa5O287I6dIYFSW5I0q996TPobtO6yBQPNnOtyb7fq9P4hia9XQdmgJCQ Q0xg== X-Gm-Message-State: AC+VfDwWdiw/d6bt3n6ehk29A1myw997v70LBURPByN2kZpVeNxtEjNg A12geSpK6cn5NS/5Qfn4hk5Rws+fwk92ECfV9WV4pInOnVv2YA== X-Google-Smtp-Source: ACHHUZ5ao/eXfPHxckT0D8jnXT93Ce8TXCOGWfdmpRWG6dYkmAK45z+c25GnPiTGhA9sgZmra0aTnCl+qWocp+7ujWQ= X-Received: by 2002:a25:a549:0:b0:ba8:1089:3338 with SMTP id h67-20020a25a549000000b00ba810893338mr1072407ybi.39.1685093610897; Fri, 26 May 2023 02:33:30 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> In-Reply-To: From: Mario Marietto Date: Fri, 26 May 2023 11:32:54 +0200 Message-ID: Subject: Re: How to blacklist the nouveau driver on FreeBSD.... To: Theron Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="00000000000017445905fc956e51" X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.943]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QSKVN27gdz4K7p X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --00000000000017445905fc956e51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've fixed some errors found in the tutorial that I wrote,this : https://www.reddit.com/r/freebsd/comments/13qfz3t/comment/jlncmxh/?context= =3D3 adding these command lines : cp -r /compat/ubuntu/usr/lib/x86_64-linux-gnu /lib cp -r /compat/ubuntu/etc/alternatives /etc cp -r /compat/ubuntu/usr/lib/x86_64-linux-gnu /usr/lib and boom. The error is changed. Now I think that we are getting closer to the real error to fix : https://pastebin.ubuntu.com/p/BSGYsWH2Hf/ The real error now is : CUDA cuInit: Unknown error. This seems to be a more interesting error to talk about. On Thu, May 25, 2023 at 9:31=E2=80=AFPM Mario Marietto wrote: > Hello. > > I've asked for some clarifications on the Blender forum about the reason > why a part of the nouveau userland is called within the linuxulator,inste= ad > of the nVidia one. You can read here : > > > https://devtalk.blender.org/t/why-blender-cycles-is-not-able-to-detect-my= -gpu-s-and-cuda-within-the-ubuntu-linuxulator/27777 > > > this is what he said : > > > I can=E2=80=99t give you full help with this, but I will share some infor= mation > based on what I can gather from this post and resources online. > > - > > Linuxulator appears to be some kind of compatibility layer. It=E2=80= =99s not > guaranteed to work with all applications, and CUDA is likely to be one= of > the application types it will have issues with. Maybe try verifying th= at > applications that use the GPU work, then CUDA applications, then look = into > getting Cycles rendering working with CUDA. This may not be a Blender > issue, but a Linuxulator issue. > - > > Depending on how you installed your GPU drivers on =E2=80=9CLinux=E2= =80=9D, you might > not have all the packages required to run CUDA applications. For examp= le, > on some Linux distributions I had to install packages like libcuda1 > and libnvoptix1 to use CUDA and OptiX on Linux. > - > > As you pointed out, the error libGL error: failed to load driver: > nouveau suggests Blender is trying to load the nouveau driver. > Typically when installing the Nvidia proprietary driver, the loading o= f the > nouveau drivers gets disabled. Maybe the Nvidia GPU drivers weren=E2= =80=99t > installed properly? Or do you need to disable nouveau manually? Or is = this > just some issue with the Linuxulator? > - > > You also have errors related to =E2=80=9Copening a display=E2=80=9D (o= pening the > Blender GUI). This could be related to the GPU driver issue discussed > before, or maybe you need to do a bit of extra setup to get GUI > applications working in Linuxulator. Such as setting up a desktop > environment within your Linuxulator? > It also might be easier to test Blender with CUDA rendering if you > started with command line rendering rather than GUI render. > - > > Command Line Rendering =E2=80=94 Blender Manual 3 > > > Sorry if I=E2=80=99m unable to help much with this. > > On Thu, May 25, 2023 at 11:47=E2=80=AFAM Mario Marietto > wrote: > >> Can you figure out a method to do what I want to do ? If we are able to >> "connect" the nVidia driver to the CG / graphic tool instead of the nouv= eau >> one,a lot of cool features will be unfrozen. For example we could try to >> run Unreal Engine 5 within the linuxulator,Davinci Resolve,Maya 3d,a lot= of >> cool stuff will use the nvidia driver and it will work great. >> >> On Thu, May 25, 2023 at 11:10=E2=80=AFAM Mario Marietto >> wrote: >> >>> Smplayer behaves the same as blender. I think this is a general >>> behavior. Check below what happens when I run it within the linuxulator= : >>> >>> root@marietto:/mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash >>> >>> root@marietto:/# smplayer >>> >>> QStandardPaths: error creating runtime directory '/var/run/user/1001' >>> (No such file or directory) >>> This is SMPlayer v. 22.7.0 (revision 10091) running on Linux >>> libGL error: glx: failed to create dri2 screen >>> *libGL error: failed to load driver: nouveau* >>> >>> >>> >>> On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron wrote: >>> >>>> On 5/24/23 04:43, Mario Marietto wrote: >>>> > since the nouveau driver can't be blacklisted within the Linuxulator >>>> > because it's impossible to run "sudo update-initramfs -u" inside of >>>> > it. For this reason,I would ask if in your opinion the nouveau drive= r >>>> > can be blacklisted directly in FreeBSD or in some other way. Thanks. >>>> > >>>> FreeBSD does not contain the nouveau kernel module so there is nothing >>>> to blacklist. >>>> >>>> > He says that he created a Python script for updating Nvidia drivers >>>> on >>>> > CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please giv= e >>>> > a look to an old post created by me some time ago and you will see : >>>> > >>>> > >>>> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the= _nouveau_driver_within_the/ >>>> > >>>> These libGL errors are from Mesa libGL, which is trying to use the >>>> userspace part of nouveau (which is part of the Mesa project), >>>> presumably based on Nvidia GPU's PCI ID being known to Mesa, despite >>>> there being no nouveau kernel interface available. >>>> >>>> Since you are trying to use Nvidia's binary driver (the only one which >>>> works on FreeBSD), Blender should have never loaded Mesa's libGL in th= e >>>> first place - there is most likely a configuration problem here with >>>> libglvnd, the component responsible for choosing the correct libGL >>>> implementation. >>>> >>>> When Blender fails to detect CUDA this has nothing to do with libGL an= d >>>> absolutely nothing to do with nouveau - have you found any other CUDA >>>> program to work in linux compat? >>>> >>>> Theron >>>> >>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --00000000000017445905fc956e51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I've fixed some errors found in the tutorial th= at I wrote,this :

https://www.reddit.com/r/freebsd/comments/13qfz3t/comment/jlncmxh/?co= ntext=3D3

adding these co= mmand lines :


cp -r /compat/ubuntu/usr/lib/x86_64-lin= ux-gnu /lib

cp -r /compat/ubu= ntu/etc/alternatives /etc

cp = -r /compat/ubuntu/usr/lib/x86_64-linux-gnu /usr/lib


a= nd boom. The error is changed. Now I think that we are getting closer to th= e real error to fix :

https://pastebi= n.ubuntu.com/p/BSGYsWH2Hf/

The real error now is : CUDA cuInit: Unknown error.

This seems to be a more interesting error to talk = about.


On Thu, May 25, 2023 at 9:31=E2=80=AFPM Mario Mariett= o <marietto2008@gmail.com&= gt; wrote:
Hello.

I've asked for some cl= arifications on the Blender forum about the reason why a part of the nouvea= u userland is called within the linuxulator,instead of the nVidia one. You = can read here :



this is wh= at he said :
=C2=A0

I can=E2=80= =99t give you full help with this, but I will=20 share some information based on what I can gather from this post and=20 resources online.

  • Linuxulator appears to be some kind of compatibility layer. It=E2=80=99s= not=20 guaranteed to work with all applications, and CUDA is likely to be one=20 of the application types it will have issues with. Maybe try verifying=20 that applications that use the GPU work, then CUDA applications, then=20 look into getting Cycles rendering working with CUDA. This may not be a=20 Blender issue, but a Linuxulator issue.

  • Depending on how you installed your GPU drivers on =E2=80=9CLinux=E2=80= =9D, you might not have all the packages required to run CUDA applications. For=20 example, on some Linux distributions I had to install packages like l= ibcuda1 and libnvoptix1 to use CUDA and OptiX on Linux.=

  • As you pointed out, the error libGL error: failed to load driver: = nouveau suggests Blender is trying to load the nouveau driver. Typically when=20 installing the Nvidia proprietary driver, the loading of the nouveau=20 drivers gets disabled. Maybe the Nvidia GPU drivers weren=E2=80=99t install= ed=20 properly? Or do you need to disable nouveau manually? Or is this just some= =20 issue with the Linuxulator?

  • You also have errors related to =E2=80=9Copening a display=E2=80=9D (ope= ning the=20 Blender GUI). This could be related to the GPU driver issue discussed=20 before, or maybe you need to do a bit of extra setup to get GUI=20 applications working in Linuxulator. Such as setting up a desktop environme= nt within your Linuxulator?
    It also might be easier to test Blender with CUDA rendering if you started = with command line rendering rather than GUI render.

  • Command Line Rend= ering =E2=80=94 Blender Manual 3

Sorry if I=E2=80=99m unable to help much with this.


On Th= u, May 25, 2023 at 11:47=E2=80=AFAM Mario Marietto <marietto2008@gmail.com> wrot= e:
Can you figure out a method to do what I want to do ? If we are able to= "connect" the nVidia driver to the CG / graphic tool instead of = the nouveau one,a lot of cool features will be unfrozen. For example we cou= ld try to run Unreal Engine 5 within the linuxulator,Davinci Resolve,Maya 3= d,a lot of cool stuff will use the nvidia driver and it will work great.

On Thu, May 25, 2023 at 11:10=E2=80=AFAM Mario Marietto <marietto2008@gmail.com&g= t; wrote:
Smplayer behaves the same as blender. I think this is a gen= eral behavior. Check below what happens when I run it within the linuxulato= r :

root@marietto:/mnt/zr= oot2/zroot2 # chroot /compat/ubuntulunar /bin/bash

root@marietto:/# smplayer=C2=A0

QStandardPaths: error = creating runtime directory '/var/run/user/1001' (No such file or di= rectory)
This is SMPlayer v. 22.7.0 (revision 10091) running on Linux
libGL error: glx: failed to create dri2 screen
libGL error: failed to load driver: nouveau



On Thu, May 25, 2023 at 2:56=E2=80=AFAM Theron <theron.tarigo@gmail.com= > wrote:
On 5= /24/23 04:43, Mario Marietto wrote:
> since the nouveau driver can't be blacklisted within the Linuxulat= or
> because it's impossible to run "sudo update-initramfs -u"= ; inside of
> it. For this reason,I would ask if in your opinion the nouveau driver =
> can be blacklisted directly in FreeBSD or in some other way. Thanks. >
FreeBSD does not contain the nouveau kernel module so there is nothing
to blacklist.

> He says that he created a Python script for updating Nvidia drivers on=
> CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? plea= se give
> a look to an old post created by me some time ago and you will see : >
> https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_no= uveau_driver_within_the/
>
These libGL errors are from Mesa libGL, which is trying to use the
userspace part of nouveau (which is part of the Mesa project),
presumably based on Nvidia GPU's PCI ID being known to Mesa, despite there being no nouveau kernel interface available.

Since you are trying to use Nvidia's binary driver (the only one which =
works on FreeBSD), Blender should have never loaded Mesa's libGL in the=
first place - there is most likely a configuration problem here with
libglvnd, the component responsible for choosing the correct libGL
implementation.

When Blender fails to detect CUDA this has nothing to do with libGL and absolutely nothing to do with nouveau - have you found any other CUDA
program to work in linux compat?

Theron


--
Mario.


--
Mario.


--
Mario.


--
Mario.
--00000000000017445905fc956e51-- From nobody Fri May 26 11:18:33 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QSMrT6sylz4WZnk for ; Fri, 26 May 2023 11:19:21 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QSMrS5Zncz3BtK for ; Fri, 26 May 2023 11:19:20 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; none Date: Fri, 26 May 2023 13:18:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1685099945; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FBgf1WuId8az8ylh3u24VOEOFySPrrUUve05hQj5TQU=; b=Y3F9EbDCYGuNeysXg/8EultOXMKS/dlTnTepOuNvQ8hj7FN9+wkbhoJyZjbr6SgDbsrP/D SjR/d+VCWERcqjcfE9jyfFMAp/czrYndUvKWx1rQeZK4B7eOqeV2OoCj7ZoEFjyBuHluxl sQJi6ALVf/mBE0CeydHjFcEfKoxHEjfBBOyWECx5eHQewk/+8xPQlkXVT0TGDBhsVpfs8C 1j5YsVMxAGR7L8rV+nR98BG407B1v16l4SLpFtoMZ8bSiC/4mU5gzLYZoqUCyCFHAlI+tK vAW+Q8r+qTzRRZvFdLG75uG+DSN9SS1/Z0J3eqW+pFqs9H7p2RRRptWp3hOLwA== Message-ID: <20230526131833.Horde.cB-in9k5Bbia91yYeFpFhO4@webmail.leidinger.net> From: Alexander Leidinger To: Mario Marietto Cc: Theron , freebsd-hackers Subject: Re: How to blacklist the nouveau driver on FreeBSD.... References: <46f1653a-89ba-6df3-6e3a-bd4a6c692be1@gmail.com> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_GKjB4asNqDk1nrMH3WrqHA9"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4QSMrS5Zncz3BtK X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_GKjB4asNqDk1nrMH3WrqHA9 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Mario Marietto (from Fri, 26 May 2023=20= =20 11:32:54=20+0200): > I've fixed some errors found in the tutorial that I wrote,this : > > https://www.reddit.com/r/freebsd/comments/13qfz3t/comment/jlncmxh/?contex= t=3D3 > > adding these command lines : > > > cp -r /compat/ubuntu/usr/lib/x86_64-linux-gnu /lib > > cp -r /compat/ubuntu/etc/alternatives /etc > > cp -r /compat/ubuntu/usr/lib/x86_64-linux-gnu /usr/lib Think about symlinks instead of a copy. That should achieve the same=20=20 result=20with being less invasive to the system. > and boom. The error is changed. Now I think that we are getting closer to > the real error to fix : > > https://pastebin.ubuntu.com/p/BSGYsWH2Hf/ > > The real error now is : CUDA cuInit: Unknown error. > > This seems to be a more interesting error to talk about. Does the FreeBSD driver (kernel stuff) have all the necessary pieces=20=20 to=20make CUDA work? The last info I've seen was that some pieces are missing in the kernel: https://badland.io/nvidia.md Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_GKjB4asNqDk1nrMH3WrqHA9 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmRwlYgACgkQEg2wmwP4 2IbLlQ//bW6q3w41clFNCEY7SL8l73TvdzYT91NUSNMzymn9Kuo7+4F4lvYDRYWD Uby7FjfD0xlpM8IMGBR+e9XR2grQP/NhYfO45hL/YJB+Pi66ONPRS23IELw76+ZX P6nvnCLNZvs6Ebfgnd+Wt7feiQoK3GDyZNJSPn1uKsZUJQ+E4yBRO3iqNnWhLOSN UEPMiXV/e8dCBal5G0fUltL1UzM3CLUdKgRoH6/aENaTDg5oCQeoDdmFMhlMERR+ M8kW3vLvdfFAyFuaat0M/Ulmyb3hn8Ns856iEApF7GdmrckE7kDpO2qf8vU3MwlP 8GPH7KmaZ2msLTLo8GsIgzow1W6KQzH4nUPOenRHVD49RdBft5E0LPdN2mDypvOF xgF48d0fUNSFM08smOa232FSEnrs04KqpCyu+w7WNg5neGRAB90hIscmzhe7kxPo L3yl6Q7X2Tsm5yr9HEWp05pC2UwF6GO45ekgiW8M4gy5ChyAWfI3Qpsr5a+6eo5D Ae6bXoqE5hH699q3tNzP+FAE6M6Y3bt0FnhLthxBDO6CJ0oOLq/60JFh52Xb717+ C6BK2KOA0miZq/c1HLajwiuUcB79Fu8vBudp09NmJIRHFaMdvtn7ekgNJaTzU5Oe mHMzWM0PPS1flor9ZEoFXessmdOKyCeCUJttc3xSqpVjcS0eTEE= =S7Hh -----END PGP SIGNATURE----- --=_GKjB4asNqDk1nrMH3WrqHA9-- From nobody Fri May 26 16:26:48 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QSVgg6g56z4WwQs for ; Fri, 26 May 2023 16:27:11 +0000 (UTC) (envelope-from naman@freebsdfoundation.org) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QSVgf2QGKz41wD for ; Fri, 26 May 2023 16:27:10 +0000 (UTC) (envelope-from naman@freebsdfoundation.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsdfoundation.org header.s=gfnp-20170908 header.b=Cg1VqGRM; spf=pass (mx1.freebsd.org: domain of naman@freebsdfoundation.org designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=naman@freebsdfoundation.org; dmarc=none Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-55db055b412so28348877b3.0 for ; Fri, 26 May 2023 09:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; t=1685118429; x=1687710429; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=n7yGrgkGn7K1hXijx8npZ3PzfCbzhYvZuJOodfUSpdI=; b=Cg1VqGRMlEeXSzCSSxjghCu3zuZJ0Z2tS+9rel6ApgEdQZQnMwIUQFjwXmRKr1Mql8 fV0EoRoyC2eycwAhAosXwcf5AqXwRDLsaVBYeuqPMk5Lu96Sc46KzZiPbN04Aq9oBDL5 vz1T/5bXRl6z1XwCepwQBSmYHTGkXO++TmMau7v+NL54HX1Mzjuq6ASYzz0kEWs+G9tE 3/x2jRhu25NOteK2IuLofnd8KRhDrk4RxRlAC9BL9N2+3vD5DmvtoaR1dBUJ5Ji+5a/K OWRYbZi/WOKh/+KwClfKpbNKWq9XTBR79tnNYqHIkX3kKGv5Ashgs9LuQkIr0OX6aCrM oJVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685118429; x=1687710429; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n7yGrgkGn7K1hXijx8npZ3PzfCbzhYvZuJOodfUSpdI=; b=IVKwoY+aTxgEC2HMBB9gWKIIp/BkwiqHA0oqkDWZ+KDhKzSrMNMGq14RKSdW/UJ815 FTmeihuYwBZ1mKrrHaxvLenPXm1vkSXyjdGDCfOtPnU+z9e2pCy4m+claxF9fbhkBGyX ezB3MN4EHuItwwyEOQIV/DHK7Xz9J4Shm+k8lWUi2dCdB7J1CyyPrX+ATVXLtUF6J4tz qhhfCmXJwRrDjzMquNcgdSdcewJL6VTymwTvnhajHmMktwGpbtbEQaoKAbAiifjQixVG Laz+c55FLwk0D4F4rBnw3HjsnaZBIoK4duVMzkNLK84EatA0eYUmJrCBXM5kxCYh4Wzx PXlg== X-Gm-Message-State: AC+VfDz53CV9JAB9t1EjI2McQjoU2eH8yV5PqvsOzSc5azQ8gaJ0cdQ+ 2SFUIp5LnlrzHUUW4DN62IZK4Rgox+uQ1wlUZEJ3VxNIv1zeftu0RRHNgg== X-Google-Smtp-Source: ACHHUZ6ctz2Y/7H5J7gjW5qqrOs9DYAOA/Nmw+AjH2viGhJCMyKEgGeKWkU0izKKRfT3g6tfWRAsmhW6pXuDFvJ+6l0= X-Received: by 2002:a81:a14a:0:b0:564:c747:64f4 with SMTP id y71-20020a81a14a000000b00564c74764f4mr2241398ywg.11.1685118429073; Fri, 26 May 2023 09:27:09 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Naman Sood Date: Fri, 26 May 2023 12:26:48 -0400 Message-ID: Subject: Re: APIC interrupting me while stepping through a kernel with kgdb To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsdfoundation.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QSVgf2QGKz41wD X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Okay, this seems to mostly work, but I am still getting timer interrupts sometimes. I'll post here if I can get that to be reproducible, but until then, I can live with this. Thanks! Naman. On Thu, May 25, 2023 at 4:33=E2=80=AFPM Naman Sood wrote: > > Oh. How convenient! I'm running 14.0-CURRENT, though I may have > delayed system updates long enough to not have this patch at the > moment. Let me get back to you after I run updates and retry - thanks! > > Naman. > > On Thu, May 25, 2023 at 4:27=E2=80=AFPM Mark Johnston = wrote: > > > > On Thu, May 25, 2023 at 03:34:56PM -0400, Naman Sood wrote: > > > Hello! > > > > > > I've been following this guide[1] to get kgdb to debug a FreeBSD gues= t > > > on bhyve - I have a WIP patch for pfsync that I want to debug. I'm at > > > the point where I can set breakpoints in if_pfsync.c and get them to > > > break when I hit them. However, when I step/next from there, control > > > always goes to the lapic_handle_timer(), which does its APIC timer > > > things, returns control to the line where I set the breakpoint... and > > > then immediately goes to the timer again, since presumably a timer > > > tick has happened between me pressing Return repeatedly. > > > > > > Is there a way to get around this? Either turn off the timer (doesn't > > > sound like a good idea?) or get kgdb to ignore it so I can debug the > > > rest of the kernel? Running skip at the timer code didn't seem to > > > help. > > > > Which revision of FreeBSD are you running? I believe this recent commi= t > > will address the problem you're describing, but you won't have it unles= s > > you're running the main branch: > > https://cgit.freebsd.org/src/commit/?id=3Dfefac543590d