I didn't know that a command line usage error is supposed to report exit code 64. In the past I either simply exited with 1 or sometimes each
exit statement got its own dedicated number. The latter came in useful for debugging shell scripts. I exactly knew which branch was executed. That was handy when the error messages were similar or even the same.I was always wondering if there is some kind of a standard, but I never did my reasearch. Looking at other people's code, it always seemed to me that everybody just did wantever they wanted to in regards to exit codes. I just looked up what else is out there and systemd also defines heaps of errors. It even references the FreeBSD one and links to the Linux Standard Base specification, too. Cool, cool!
Do you guys know of these conventions and make use of them?
tired but felt much better today
#running #treadmill
tired but felt much better today
#running #treadmill
tired but felt much better today
#running #treadmill
slept like shit (probably from drinking) and was worn out all day.
#running
slept like shit (probably from drinking) and was worn out all day.
#running
slept like shit (probably from drinking) and was worn out all day.
#running
… but the German word for it is “Reißwolf”. That used to be a more or less common term, but nowadays it’s quite archaic. And it sounds needlessly violent. 😂🐺
… but the German word for it is “Reißwolf”. That used to be a more or less common term, but nowadays it’s quite archaic. And it sounds needlessly violent. 😂🐺
… but the German word for it is “Reißwolf”. That used to be a more or less common term, but nowadays it’s quite archaic. And it sounds needlessly violent. 😂🐺
… but the German word for it is “Reißwolf”. That used to be a more or less common term, but nowadays it’s quite archaic. And it sounds needlessly violent. 😂🐺
I would have loved to transfer the contents of one particular hard drive onto a Compact Flash card, doing a 1:1 copy using
dd – but that just won’t work. The card has a different CHS geometry than the HDD. I actually spent a couple of days trying to work around this: Reading/understanding/reverse-engineering OS/2’s boot loader code and trying to fix the incorrect bytes. It does indeed boot now and I learned a lot. QEMU is quite powerful and allows you to attach a gdb process to the machine, so you can single-step the instructions, read memory, and what not. But fdisk still shows errors, so I don’t trust it … Maybe writing to a particular area of the filesystem will crash the whole thing. 🫤It’s a strange hobby that I picked there. 😂
I would have loved to transfer the contents of one particular hard drive onto a Compact Flash card, doing a 1:1 copy using
dd – but that just won’t work. The card has a different CHS geometry than the HDD. I actually spent a couple of days trying to work around this: Reading/understanding/reverse-engineering OS/2’s boot loader code and trying to fix the incorrect bytes. It does indeed boot now and I learned a lot. QEMU is quite powerful and allows you to attach a gdb process to the machine, so you can single-step the instructions, read memory, and what not. But fdisk still shows errors, so I don’t trust it … Maybe writing to a particular area of the filesystem will crash the whole thing. 🫤It’s a strange hobby that I picked there. 😂
I would have loved to transfer the contents of one particular hard drive onto a Compact Flash card, doing a 1:1 copy using
dd – but that just won’t work. The card has a different CHS geometry than the HDD. I actually spent a couple of days trying to work around this: Reading/understanding/reverse-engineering OS/2’s boot loader code and trying to fix the incorrect bytes. It does indeed boot now and I learned a lot. QEMU is quite powerful and allows you to attach a gdb process to the machine, so you can single-step the instructions, read memory, and what not. But fdisk still shows errors, so I don’t trust it … Maybe writing to a particular area of the filesystem will crash the whole thing. 🫤It’s a strange hobby that I picked there. 😂
I would have loved to transfer the contents of one particular hard drive onto a Compact Flash card, doing a 1:1 copy using
dd – but that just won’t work. The card has a different CHS geometry than the HDD. I actually spent a couple of days trying to work around this: Reading/understanding/reverse-engineering OS/2’s boot loader code and trying to fix the incorrect bytes. It does indeed boot now and I learned a lot. QEMU is quite powerful and allows you to attach a gdb process to the machine, so you can single-step the instructions, read memory, and what not. But fdisk still shows errors, so I don’t trust it … Maybe writing to a particular area of the filesystem will crash the whole thing. 🫤It’s a strange hobby that I picked there. 😂
> And then be very thankful that we don’t have to deal with this anymore today. 😂
That's exactly what I thought when reading your explanations. :-D
I like to put as little strain as possible on the floppy disks that I have, especially when installing operating systems. I thus like to prepare disk images on my modern Linux box in QEMU (where I can use floppy images instead of actual disks) and then transfer them over to my real retro box.
Older operating systems like OS/2 make extensive use of CHS addressing and even store some of this information in the HPFS filesystem header. CHS info spreads all over the place. So, simply creating a QEMU disk image, installing something and then copying to another drive *probably* won't work, because QEMU guesses *some* CHS geometry that won’t necessarily match that of the target drive.
The solution is to a) create a QEMU disk image of the exact same size (in bytes) as the intended target drive, b) configure a matching CHS geometry in QEMU. The latter can be done like so:
-drive file=warp3.raw,if=none,id=disk1,format=raw
-device ide-hd,drive=disk1,cyls=495,heads=16,secs=32,bios-chs-trans=none
How do you know the correct CHS geometry? Ask the BIOS of the target machine.
And then be very thankful that we don’t have to deal with this anymore today. 😂
I like to put as little strain as possible on the floppy disks that I have, especially when installing operating systems. I thus like to prepare disk images on my modern Linux box in QEMU (where I can use floppy images instead of actual disks) and then transfer them over to my real retro box.
Older operating systems like OS/2 make extensive use of CHS addressing and even store some of this information in the HPFS filesystem header. CHS info spreads all over the place. So, simply creating a QEMU disk image, installing something and then copying to another drive *probably* won't work, because QEMU guesses *some* CHS geometry that won’t necessarily match that of the target drive.
The solution is to a) create a QEMU disk image of the exact same size (in bytes) as the intended target drive, b) configure a matching CHS geometry in QEMU. The latter can be done like so:
-drive file=warp3.raw,if=none,id=disk1,format=raw
-device ide-hd,drive=disk1,cyls=495,heads=16,secs=32,bios-chs-trans=none
How do you know the correct CHS geometry? Ask the BIOS of the target machine.
And then be very thankful that we don’t have to deal with this anymore today. 😂
I like to put as little strain as possible on the floppy disks that I have, especially when installing operating systems. I thus like to prepare disk images on my modern Linux box in QEMU (where I can use floppy images instead of actual disks) and then transfer them over to my real retro box.
Older operating systems like OS/2 make extensive use of CHS addressing and even store some of this information in the HPFS filesystem header. CHS info spreads all over the place. So, simply creating a QEMU disk image, installing something and then copying to another drive *probably* won't work, because QEMU guesses *some* CHS geometry that won’t necessarily match that of the target drive.
The solution is to a) create a QEMU disk image of the exact same size (in bytes) as the intended target drive, b) configure a matching CHS geometry in QEMU. The latter can be done like so:
-drive file=warp3.raw,if=none,id=disk1,format=raw
-device ide-hd,drive=disk1,cyls=495,heads=16,secs=32,bios-chs-trans=none
How do you know the correct CHS geometry? Ask the BIOS of the target machine.
And then be very thankful that we don’t have to deal with this anymore today. 😂
I like to put as little strain as possible on the floppy disks that I have, especially when installing operating systems. I thus like to prepare disk images on my modern Linux box in QEMU (where I can use floppy images instead of actual disks) and then transfer them over to my real retro box.
Older operating systems like OS/2 make extensive use of CHS addressing and even store some of this information in the HPFS filesystem header. CHS info spreads all over the place. So, simply creating a QEMU disk image, installing something and then copying to another drive *probably* won't work, because QEMU guesses *some* CHS geometry that won’t necessarily match that of the target drive.
The solution is to a) create a QEMU disk image of the exact same size (in bytes) as the intended target drive, b) configure a matching CHS geometry in QEMU. The latter can be done like so:
-drive file=warp3.raw,if=none,id=disk1,format=raw
-device ide-hd,drive=disk1,cyls=495,heads=16,secs=32,bios-chs-trans=none
How do you know the correct CHS geometry? Ask the BIOS of the target machine.
And then be very thankful that we don’t have to deal with this anymore today. 😂
> Error error parsing created field: parsing time "1713565714000000000" as "2006-01-02T15:04:05Z07:00": cannot parse "565714000000000" as "-"
And now it's even offline according to Clownflare…