Re: lilypond PDF builds broken in OpenBSD 7.4 following ghostscript-10.02.0->10.02.1 ?
On 2023-11-13, Jeremy Mates wrote: > Nov 12 19:41:30 gear pkg_add: Added firefox-119.0->119.0.1 > Nov 12 19:41:55 gear pkg_add: Added ghostscript-10.02.0->10.02.1 > > PDF builds fail, can someone confirm this isn't my system being wacky? This was fixed in -current but that hasn't been applied to -stable yet. I think it was only identified as a build issue though it affects runtime too. I'll backport it.
subscribe
lilypond PDF builds broken in OpenBSD 7.4 following ghostscript-10.02.0->10.02.1 ?
Nov 12 19:41:30 gear pkg_add: Added firefox-119.0->119.0.1
Nov 12 19:41:55 gear pkg_add: Added ghostscript-10.02.0->10.02.1
PDF builds fail, can someone confirm this isn't my system being wacky?
$ ls test.*
test.ly
$ cat test.ly
\version "2.22.2"
\score {
{ \new Staff { e4 e e c1 } }
\layout {}
\midi {}
}
$ /usr/local/bin/lilypond test.ly
GNU LilyPond 2.22.2
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
MIDI output to `test.midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `test.pdf'...
warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH
-dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-3901926)' failed (256)
fatal error: failed files: "test.ly"
If the "build PDF" bit is disabled, then no error:
$ ed test.ly
84
/lay
\layout {}
s/^/%
% \layout {}
wq
85
$ /usr/local/bin/lilypond test.ly
GNU LilyPond 2.22.2
Processing `test.ly'
Parsing...
Interpreting music...
MIDI output to `test.midi'...
Success: compilation successfully completed
$ ls test.*
test.ly test.midi
ktrace -di shows lilypond and gs chatting but nothing clear as to what or why
there was an error:
18383 gs GIO fd 2 wrote 7 bytes
"10.02.1"
42762 lilypond STRU struct pollfd [2] { fd=9,
events=0x19, revents=0<> } { fd=11, events=0x19,
revents=0x1 }
18383 gs RET write 7
42762 lilypond RET poll 1
18383 gs CALL write(2,0x7365ef51ef40,0x2)
42762 lilypond CALL read(11,0x758d0fb810a0,0x1000)
18383 gs GIO fd 2 wrote 2 bytes
": "
42762 lilypond GIO fd 11 read 25 bytes
"GPL Ghostscript 10.02.1: "
18383 gs RET write 2
42762 lilypond RET read 25/0x19
18383 gs CALL write(2,0x7365ef51ef40,0x21)
42762 lilypond CALL poll(0x758d0fb82190,2,INFTIM)
18383 gs GIO fd 2 wrote 33 bytes
"Unrecoverable error, exit code 1
"
Re: smtpd[68513]: warn: lost processor: spamassassin exited abnormally
Hi Omar, On 2023-11-09 18:22:41, Omar Polo wrote: I've committed the update and backported to -STABLE so the fixed package should appear in the next days. Thanks for the report and sorry for the breakage I highly appreciate your fast response and the fix you have provided. Regards Harri
Re: umb0: open error: FAILURE
/etc/hostname.umb0 apn YOUR.PROVIDERS.APN pin "PIN" or pin "" if it disabled up $ doas sh - x /etc/netstart umb0 -Stefan Samuel Jayden hat am 13.11.2023 20:03 CET geschrieben: Hello misc, After experiencing mbim attach (from umsm) issue[*] with EM7455, I purchased another LTE module with a different (SIM8262E-M2) chipset. This time switching to mbim mode was no problem. However, this time it remains as "SIM not initialized". But when you install Linux on the same device, it can successfully obtain an IP address and access the internet. I tested this on both OpenBSD 7.3 and 7.4. Here is some output that might be useful: # usbdevs addr 03: 1e0e:9003 SIMCOM, SDXLEMUR-LITE-MTP _SN:C7FD1685 super speed, power 224 mA, config 1, rev 5.04, iSerial 0123456789ABCDEF driver: umb0 # ifconfig umb0 umb0: flags=8815 mtu 1500 index 7 priority 6 llprio 3 roaming disabled registration unknown state down cell-class none SIM not initialized PIN required APN internet status: down dmesg after debug flag : umb0: state change timeout umb0: open error: FAILURE dmesg is attached How can I solve this? Thanks. [*] https://marc.info/?l=openbsd-misc&m=169988135425184&w=2
Re: umb0: open error: FAILURE
Hello Stefan(s),
Thanks for your replies.
In my setup PIN is disabled.Also I've just tried entering { ifconfig umb0
down;ifconfig umb0 apn internet;ifconfig umb0 pin "";ifconfig umb0 up } But
nothing comes up.
It is still at the same stage.
Even if I set the wrong PIN it gives the same message. I think it really
can not initialize the SIM.The question is why? How to troubleshoot?
On Mon, Nov 13, 2023 at 11:07 PM Stefan Sperling wrote:
> On Mon, Nov 13, 2023 at 10:03:01PM +0300, Samuel Jayden wrote:
> > Hello misc,
> >
> > After experiencing mbim attach (from umsm) issue[*] with EM7455, I
> > purchased another LTE module with a different (SIM8262E-M2) chipset.
> This
> > time switching to mbim mode was no problem.
> > However, this time it remains as "SIM not initialized". But when you
> > install Linux on the same device, it can successfully obtain an IP
> address
> > and access the internet.
>
> This is the important bit in your logs:
>
> > SIM not initialized PIN required
> ^^
>
> Try setting the SIM card's PIN with 'ifconfig umb0 pin '.
>
> On my laptop I have this in /etc/hostname.umb0 (with the correct
> pin instead of and the correct APN):
>
> pin
> apn myapn
> roaming
> down
>
> With this in place running 'ifconfig umb0 up' is enough to get link.
>
Re: umb0: open error: FAILURE
On Mon, Nov 13, 2023 at 10:03:01PM +0300, Samuel Jayden wrote: > Hello misc, > > After experiencing mbim attach (from umsm) issue[*] with EM7455, I > purchased another LTE module with a different (SIM8262E-M2) chipset. This > time switching to mbim mode was no problem. > However, this time it remains as "SIM not initialized". But when you > install Linux on the same device, it can successfully obtain an IP address > and access the internet. This is the important bit in your logs: > SIM not initialized PIN required ^^ Try setting the SIM card's PIN with 'ifconfig umb0 pin '. On my laptop I have this in /etc/hostname.umb0 (with the correct pin instead of and the correct APN): pin apn myapn roaming down With this in place running 'ifconfig umb0 up' is enough to get link.
libc++abi: std::bad_alloc: std::bad_alloc (nodejs)
Hello I have a project that's built with nodejs / webpack. I have a few other projects that use the same stack, and are far more complicated. There's no problems building them on OpenBSD. With this particular project, I run into this error: $ npm run build > photon@0.2.1 build > npm exec webpack libc++abi: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc Abort trap (core dumped) At one point in time it built fine. I am running a recent snapshot, and all packages are up to date. I thought the problem might be fixed with time but that hasn't been the case. The nodejs version is v18.18.2. It should be possible to reproduce by cloning the project: git clone https://github.com/0x1eef/photon.git cd photon npm i npm run build Any suggestions or tips on what might be going wrong ? Thanks.
umb0: open error: FAILURE
Hello misc, After experiencing mbim attach (from umsm) issue[*] with EM7455, I purchased another LTE module with a different (SIM8262E-M2) chipset. This time switching to mbim mode was no problem. However, this time it remains as "SIM not initialized". But when you install Linux on the same device, it can successfully obtain an IP address and access the internet. I tested this on both OpenBSD 7.3 and 7.4. Here is some output that might be useful: # usbdevs addr 03: 1e0e:9003 SIMCOM, SDXLEMUR-LITE-MTP _SN:C7FD1685 super speed, power 224 mA, config 1, rev 5.04, iSerial 0123456789ABCDEF driver: umb0 # ifconfig umb0 umb0: flags=8815 mtu 1500 index 7 priority 6 llprio 3 roaming disabled registration unknown state down cell-class none SIM not initialized PIN required APN internet status: down dmesg after debug flag : umb0: state change timeout umb0: open error: FAILURE dmesg is attached How can I solve this? Thanks. [*] https://marc.info/?l=openbsd-misc&m=169988135425184&w=2 OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8412323840 (8022MB) avail mem = 8137629696 (7760MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x78a4 (73 entries) bios0: vendor American Megatrends International, LLC. version "5.19" date 07/31/2023 bios0: Default string Default string efi0 at bios0: UEFI 2.7 efi0: American Megatrends rev 0x50013 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP MCFG SSDT FIDT OEM1 HPET APIC PRAM RSCI SSDT SSDT NHLT SSDT SSDT PSDS LPIT SSDT FPDT DMAR SSDT TPM2 WSMT acpi0: wakeup devices RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) PXSX(S0) RP06(S0) PXSX(S0) RP07(S0) PXSX(S0) XHCI(S0) XDCI(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xc000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCN
Re: does anybody else seeing this? (NUT)
On Mon, 13 Nov 2023 16:20:47 +0200 Gregory Edigarov wrote: > Hello, > > After upgrading to the latest snapshot, my system seems ups lost. > addr 02: 0665:5161 Mustek Systems, PowerMust 800 >low speed, power 100 mA, config 1, rev 0.03 >driver: ugen0 > > /etc/nut/ups.conf: > > [njoy] > driver = "nutdrv_qx" > vendorid = "0665" > productid = "5161" > bus = "000" > pollinterval = "10" > port = "auto" > > # ls -l /dev/ugen0* > crw-rw 1 root _ups 63, 0 Nov 12 12:45 /dev/ugen0.00 > crw-rw 1 root _ups 63, 1 Nov 12 12:45 /dev/ugen0.01 > crw-rw 1 root _ups 63, 2 Nov 12 12:45 /dev/ugen0.02 > crw-rw 1 root _ups 63, 3 Nov 12 12:45 /dev/ugen0.03 > crw-rw 1 root _ups 63, 4 Nov 12 12:45 /dev/ugen0.04 > crw-rw 1 root _ups 63, 5 Nov 12 12:45 /dev/ugen0.05 > crw-rw 1 root _ups 63, 6 Nov 12 12:45 /dev/ugen0.06 > crw-rw 1 root _ups 63, 7 Nov 12 12:45 /dev/ugen0.07 > crw-rw 1 root _ups 63, 8 Nov 12 12:45 /dev/ugen0.08 > crw-rw 1 root _ups 63, 9 Nov 12 12:45 /dev/ugen0.09 > crw-rw 1 root _ups 63, 10 Nov 12 12:45 /dev/ugen0.10 > crw-rw 1 root _ups 63, 11 Nov 12 12:45 /dev/ugen0.11 > crw-rw 1 root _ups 63, 12 Nov 12 12:45 /dev/ugen0.12 > crw-rw 1 root _ups 63, 13 Nov 12 12:45 /dev/ugen0.13 > crw-rw 1 root _ups 63, 14 Nov 12 12:45 /dev/ugen0.14 > crw-rw 1 root _ups 63, 15 Nov 12 12:45 /dev/ugen0.15 > > it was working correctly before upgrade, but now it doesn't > > what's my mistake? > oh, it is no need to set bus parameter now...
does anybody else seeing this? (NUT)
Hello, After upgrading to the latest snapshot, my system seems ups lost. addr 02: 0665:5161 Mustek Systems, PowerMust 800 low speed, power 100 mA, config 1, rev 0.03 driver: ugen0 /etc/nut/ups.conf: [njoy] driver = "nutdrv_qx" vendorid = "0665" productid = "5161" bus = "000" pollinterval = "10" port = "auto" # ls -l /dev/ugen0* crw-rw 1 root _ups 63, 0 Nov 12 12:45 /dev/ugen0.00 crw-rw 1 root _ups 63, 1 Nov 12 12:45 /dev/ugen0.01 crw-rw 1 root _ups 63, 2 Nov 12 12:45 /dev/ugen0.02 crw-rw 1 root _ups 63, 3 Nov 12 12:45 /dev/ugen0.03 crw-rw 1 root _ups 63, 4 Nov 12 12:45 /dev/ugen0.04 crw-rw 1 root _ups 63, 5 Nov 12 12:45 /dev/ugen0.05 crw-rw 1 root _ups 63, 6 Nov 12 12:45 /dev/ugen0.06 crw-rw 1 root _ups 63, 7 Nov 12 12:45 /dev/ugen0.07 crw-rw 1 root _ups 63, 8 Nov 12 12:45 /dev/ugen0.08 crw-rw 1 root _ups 63, 9 Nov 12 12:45 /dev/ugen0.09 crw-rw 1 root _ups 63, 10 Nov 12 12:45 /dev/ugen0.10 crw-rw 1 root _ups 63, 11 Nov 12 12:45 /dev/ugen0.11 crw-rw 1 root _ups 63, 12 Nov 12 12:45 /dev/ugen0.12 crw-rw 1 root _ups 63, 13 Nov 12 12:45 /dev/ugen0.13 crw-rw 1 root _ups 63, 14 Nov 12 12:45 /dev/ugen0.14 crw-rw 1 root _ups 63, 15 Nov 12 12:45 /dev/ugen0.15 it was working correctly before upgrade, but now it doesn't what's my mistake?
Sierra Wireless LTE-A does not recognized as Umb Interface
Hello Dear misc,
Model Full Name: Sierra Wireless, Incorporated Sierra Wireless EM7455
Qualcomm\M-. Snapdragon? X7 LTE-A
I have an OpenBSD system, and I want to use the Sierra Wireless modem as
the Umb interface. I changed the LTE mode to MBIM, but OpenBSD does not
recognize it as an Umb Interface.
I changed the MBIM mode using the command 'cu -l /dev/cuaU2 -s 9600,'
connecting and executing AT commands. After switching to MBIM mode, I am
unable to access it using OpenBSD's cu commands. However, I successfully
connected and confirmed that the MBIM mode change was done successfully
using cu on a Linux system(ubuntu). It’s fully operational under Linux.
When attempting to connect to cuaU2 after the MBIM mode change, I encounter
the following errors:
OpenBSD# cu -l /dev/cuaU0 -s 9600
cu: open("/dev/cuaU0"): Input/output error
OpenBSD# cu -l /dev/cuaU1 -s 9600
cu: open("/dev/cuaU1"): Input/output error
OpenBSD# cu -l /dev/cuaU2 -s 9600
cu: open("/dev/cuaU2"): Device not configured
OpenBSD# cu -l /dev/cuaU3 -s 9600
cu: open("/dev/cuaU3"): Device not configured
OpenBSD#
Is there a way to solve this problem, or does OpenBSD not support Sierra
Wireless modem?
The driver's dmesg and usbdevs output are as follows:
*dmesg:*
umsm0 at uhub1 port 3 configuration 1 interface 0 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
ucom0 at umsm0
umsm1 at uhub1 port 3 configuration 1 interface 3 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
ucom1 at umsm1
umsm2 at uhub1 port 3 configuration 1 interface 12 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
umsm2: missing endpoint
umsm3 at uhub1 port 3 configuration 1 interface 13 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
umsm3: missing endpoint
*usbdevs:*
addr 06: 1199:9071 Sierra Wireless, Incorporated, Sierra Wireless EM7455
Qualcomm\M-. Snapdragon? X7 LTE-A
high speed, power 500 mA, config 1, rev 0.06, iSerial
LF93858930021032
driver: umsm0
driver: umsm1
driver: umsm2
driver: umsm3
Thank you in advance for your help.
Re: Creating a softraid mirror from a regular OpenBSD disk
> >> If you are on >> sticks copy machine by three slots are also a solution. > > Running an OpenBSD system entirely from USB sticks, and using a copy machine > to make backups is not a good suggestion for general usage. Indeed, and also depends on their size. > P.S. Daniele, please fix your mailer's reply-to: header. Beside the joke it is a true email forward. Just implemented for the truth. Give me the time to check with my provider if it is all fine. It immediately appears very good like a deterrent ;-). However, sorry for any inconvinience.. -- Daniele Bonini
Re: Creating a softraid mirror from a regular OpenBSD disk
On Mon, Nov 13, 2023 at 10:15:30AM +0100, Daniele B. wrote: > In few words, when the matter is saving the data of one 1 disk the best > solution is adopt a backup strategy for that purpose. Yes, this is true. I answered the OPs direct question about how to create the raid mirror, but that was _not_ intended as an endorsement of using raid to solve any particular problem. In very simple terms, a raid-1 mirror is useful for protecting data which is often changing, (E.G. busy mail spools), where backups would immediately become out-dated, (although you should make regular backups of that data anyway, in addition to having the mirror). Raid-1 is also useful in some situations where you need high availability of data even though that data is unchanging and easily restored from a backup. An example of high availability of a large and mostly unchanging database might be a music repository for a radio station that is using digital playout, where they cannot risk going silent just because one hard disk broke, but the actual data would be easily restored from backups if a complete system failure did occur. Also note that using multiple disks instead of a single disk can and often does _increase_ the risk of any particular failure. Any one of the disks could develop a fault which takes the host controller out or even makes the PSU explode. Any one of the disks could have firmware issues that cause silent data corruption, and the more disks you have the more likely it is that one of them will suffer such a problem. > If you are on > sticks copy machine by three slots are also a solution. Running an OpenBSD system entirely from USB sticks, and using a copy machine to make backups is not a good suggestion for general usage. Just do a normal installation on a normal hard disk and make normal backups. And don't just use $HOME as an endless rubbish dump for old data. $HOME is for work in progress. Finished stuff should be archived elsewhere and taken out of the regular backup loop. P.S. Daniele, please fix your mailer's reply-to: header.
Re: Creating a softraid mirror from a regular OpenBSD disk
The argument has already been touched recently in other threads. In few words, when the matter is saving the data of one 1 disk the best solution is adopt a backup strategy for that purpose. You can have a backup strategy that involve one or more spare disks. If you are on sticks copy machine by three slots are also a solution. Involving 1 more disk in raid 1 is never a good solution for different reasons the most important one: against a disk failure you put at risk the full raid set; then softraid is never running properly and never good for your disk life beside slowing down your system. The advise is a good backup strategy also against the possibility to adopt other kind of raid involving more disks, increasing your own expense at the important cost of losing a direct touch on your data.
Re: Creating a softraid mirror from a regular OpenBSD disk
On Mon, Nov 13, 2023 at 02:05:34AM +0100, i...@tutanota.com wrote: > Is that possible or does the first disk needs to be reformattet and > repartitioned before adding a second disk? You will need to copy your data elsewhere, then re-partition and create the raid mirror, then copy your data back. Currently there is no tool that will convert a plain volume into one part of a raid mirror set with the data 'in place'.
