Re: Dissing Misks
> > If you're starting fresh, isn't it simpler to use a GPT partition > > table if you want to go past that limit? > > > > IF your computer supports GPT, that's certainly an option. > However, I've yet to find anything "simpler" about GPT setups. > Whatever GPT was supposed to make better, I think they missed. > > (to be fair: I understand the OpenBSD MBR boot process very well, and > I can fix just about anything that goes wrong with it. I have NOT > figured out all of GPT booting all that well -- I can make it work, > (more accurately: I can let the OpenBSD devs make it work) but I > can't exactly tell you what is going on under the hood. I have got > multibooting to work with GPT, and if I ever figure out all of how > THAT worked, it might be a better way of doing multibooting than > the usual MBR solutions.) > > I've never regretted setting up a MBR boot system on an "either will > do" machine. I have regretted setting up a GPT system on a machine > that became unreliable, and thus had to be replaced, and I spent too > long trying to find a new used system that was also GPT capable. Oops; fair enough; I forgot about booting. -- James
Re: Dissing Misks
On 2020-12-23 11:29, James Cook wrote: > On Wed, Dec 23, 2020 at 10:21:08AM -0500, Nick Holland wrote: >> On 2020-12-22 23:58, Allan Streib wrote: >> > Duncan Patton a Campbell writes: >> > >> >> fdisk seems unwilling to allow more than 2T in the partition: >> > >> > Look at the b command for disklabel(8) to set the OpenBSD disk >> > boundaries. >> > >> > Allan >> > >> >> yep. >> fdisk can't do bigger than 2T because that's as big as the MBR tables >> allow. But fdisk is only used to mark off the OpenBSD part of the disk >> to keep other OSes from stomping on its space. If you are running an >> exclusively OpenBSD system or otherwise keep the OSes from getting >> confused, fdisk isn't used for much. Make it as big as you can, and >> you are fine. >> >> disklabel, by default, only uses the OpenBSD fdisk partition, but you >> can blow through that barrier with the 'b' command, as Allan indicated. >> >> If you are using softraid, you will have to repeat the disklabel 'b' >> thing for the softraid disks, too. I usually forget that part. >> >> Nick. > > If you're starting fresh, isn't it simpler to use a GPT partition > table if you want to go past that limit? > IF your computer supports GPT, that's certainly an option. However, I've yet to find anything "simpler" about GPT setups. Whatever GPT was supposed to make better, I think they missed. (to be fair: I understand the OpenBSD MBR boot process very well, and I can fix just about anything that goes wrong with it. I have NOT figured out all of GPT booting all that well -- I can make it work, (more accurately: I can let the OpenBSD devs make it work) but I can't exactly tell you what is going on under the hood. I have got multibooting to work with GPT, and if I ever figure out all of how THAT worked, it might be a better way of doing multibooting than the usual MBR solutions.) I've never regretted setting up a MBR boot system on an "either will do" machine. I have regretted setting up a GPT system on a machine that became unreliable, and thus had to be replaced, and I spent too long trying to find a new used system that was also GPT capable. So far in my life, all my systems are MBR capable, some are also GPT capable, but until it becomes mostly GPT and few MBR, I'm kinda fond of the MBR setup for failure recovery reasons. And really, the key sequence of "b" [enter] "*" [enter] is NOT a major difficulty (other than remembering to do it. Somehow, I keep building systems where it is stupidly easy to forget, though that's also an easy after-the-fact fix). Yes, there are some GPT only computers now. There are some dual mode with buggy MBR support. I'm pretty sure there are some dual mode machines with buggy GPT support. I do not think there's a universal answer -- look at your situation and knowledge and proceed appropriately. Nick.
Re: Dissing Misks
On Wed, Dec 23, 2020 at 10:21:08AM -0500, Nick Holland wrote: > On 2020-12-22 23:58, Allan Streib wrote: > > Duncan Patton a Campbell writes: > > > >> fdisk seems unwilling to allow more than 2T in the partition: > > > > Look at the b command for disklabel(8) to set the OpenBSD disk > > boundaries. > > > > Allan > > > > yep. > fdisk can't do bigger than 2T because that's as big as the MBR tables > allow. But fdisk is only used to mark off the OpenBSD part of the disk > to keep other OSes from stomping on its space. If you are running an > exclusively OpenBSD system or otherwise keep the OSes from getting > confused, fdisk isn't used for much. Make it as big as you can, and > you are fine. > > disklabel, by default, only uses the OpenBSD fdisk partition, but you > can blow through that barrier with the 'b' command, as Allan indicated. > > If you are using softraid, you will have to repeat the disklabel 'b' > thing for the softraid disks, too. I usually forget that part. > > Nick. If you're starting fresh, isn't it simpler to use a GPT partition table if you want to go past that limit? -- James
Re: Dissing Misks
On 2020-12-22 23:58, Allan Streib wrote: > Duncan Patton a Campbell writes: > >> fdisk seems unwilling to allow more than 2T in the partition: > > Look at the b command for disklabel(8) to set the OpenBSD disk > boundaries. > > Allan > yep. fdisk can't do bigger than 2T because that's as big as the MBR tables allow. But fdisk is only used to mark off the OpenBSD part of the disk to keep other OSes from stomping on its space. If you are running an exclusively OpenBSD system or otherwise keep the OSes from getting confused, fdisk isn't used for much. Make it as big as you can, and you are fine. disklabel, by default, only uses the OpenBSD fdisk partition, but you can blow through that barrier with the 'b' command, as Allan indicated. If you are using softraid, you will have to repeat the disklabel 'b' thing for the softraid disks, too. I usually forget that part. Nick.
Re: Dissing Misks
Duncan Patton a Campbell writes: > fdisk seems unwilling to allow more than 2T in the partition: Look at the b command for disklabel(8) to set the OpenBSD disk boundaries. Allan
Re: Dissing Misks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Dec 2020 19:06:48 -0700 Duncan Patton a Campbell wrote: > > On Tue, 22 Dec 2020 18:21:30 -0700 > "Todd C. Miller" wrote: > > > On Tue, 22 Dec 2020 17:30:08 -0700, Duncan Patton a Campbell wrote: > > > > > I've added two identical 4TB disks to my system to set up a duald RAID. > > > > > > When I boot, they come up as > > > > > > sd2 at scsibus1 targ 2 lun 0: > > > naa.50014ee268199 > > > 5d6 > > > sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors > > > > > > and > > > > > > wd0 at pciide1 channel 0 drive 0: > > > wd0: 16-sector PIO, LBA48, 3815447MB, 7814037168 sectors > > > > > > One of these things is not like the other, and I've not located > > > how this distinction is made at boot time. > > > > You should check your BIOS settings and make sure all the SATA > > channels are configured to use AHCI and not legacy ATA. > > > > - todd > > > > YES! That would be the problem. It's not done on a per-channel > basis but there's another obscure setting at the bottom of a page > that sets it for all ... > > Thanks, > > Dhu > meh. Still craziness. I have two 4Tb disks I want to put into a RAID1 (I want a BG partition for imaging other disks). Neither fdisk nor disklabel will create/recognize a part > 4294961600 (sect512) This is the dislabel dialogue: sd2> a a offset: [64] size: [4294961621] 7814037100 FS type: [4.2BSD] sd2*> p OpenBSD area: 64-4294961685; size: 4294961621; free: 21 #size offset fstype [fsize bsize cpg] a: 4294961600 64 4.2BSD 8192 65536 1 c: 78140371680 unused fdisk seems unwilling to allow more than 2T in the partition: atlas:/root/cde/Disks# fdisk sd2 Disk: sd2 geometry: 267349/255/63 [4294961685 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] - --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 267348 254 63 [ 64: 4294961621 ] OpenBSD Any pointers or ideas appreciated. Thanks, Dhu - -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJf4sTuAAoJEI6Vun3D6YUPYsgP/34kfiLozvH2U9vEEf9TBafx 0x3KZ5fm9iWNZebsCPvs5H/b2g9FaWvpxdm0Kva+h4myeL3SBd3No3SEUBAzBKHT emCUDgJ3/hq6sr+kCaUgILko78jsJHT2ELLWP9l2ct5gGja9Te0DGTrdQPLtK3lY gFBND2o8IVV4pS/rUlpv5U15SsyKQtbRlrL0W6b1Vb44CeS/dVuQTQI14xBLB3Hg lpXQ5GlAm2PP/COY5ka8Z/ZRXu58PcxKwFd3BhR0D/DlC1js1e5nPWLV62eSfBOy prk1sY9yeqro/49gUNKSIJTPHFsukDsNfLEle3L1vOIzVNLVazSgcwV+oGqyemVX 4jIPD1R5HRvLMsAYhh+3tbVFJCLt3WR5Z73JmhI6ZM1Js4Ri72BV2lg6SL5EZWvC gScuK6fdV+Q1DBouTV3oTRaY8nyJFq+WWvJ4xbKOxPysmg4+8+hK/TaYfkgWFcXC 4ebKb8MmU0ms7AFKthrRIJ6/ZHsXfTrZdkenHZYbB7k1n/bH9E1kpiOmlfUXbkvB 6wjUoSNAjLHl3NdOVoSnhhRsZWgSzdzWuk27363ldCAjxv8yzF4ANwSHXHTtzXnr Wj0s0pHNGI1RKCBnG81gqdjzCV7+b6G7j6SJFAJ6F/FAsgAsjX3zvNMw2SyUBVnV CG4wfpsdQDtHnvSv8GLT =3DnS -END PGP SIGNATURE-
Re: Dissing Misks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Dec 2020 18:21:30 -0700 "Todd C. Miller" wrote: > On Tue, 22 Dec 2020 17:30:08 -0700, Duncan Patton a Campbell wrote: > > > I've added two identical 4TB disks to my system to set up a duald RAID. > > > > When I boot, they come up as > > > > sd2 at scsibus1 targ 2 lun 0: > > naa.50014ee268199 > > 5d6 > > sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors > > > > and > > > > wd0 at pciide1 channel 0 drive 0: > > wd0: 16-sector PIO, LBA48, 3815447MB, 7814037168 sectors > > > > One of these things is not like the other, and I've not located > > how this distinction is made at boot time. > > You should check your BIOS settings and make sure all the SATA > channels are configured to use AHCI and not legacy ATA. > > - todd > YES! That would be the problem. It's not done on a per-channel basis but there's another obscure setting at the bottom of a page that sets it for all ... Thanks, Dhu - -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJf4qY5AAoJEI6Vun3D6YUP7WcP/1BN+n9qWOjPN7GSf56wxKGY CkFg/JzPQj7Nk+i/QElJfUfNQKNlAWJHU11Div0nDtOBp84OaEpPHRvlk9dhcm8Q KyISR2XD5EbAFNRvkjNDKySqZKl/7gaW4vdzFdypjMdZGguteOIRUvlJ1fOZFqIC Dk0b8SThc3KJ8QltRB+p1awe76IhziveHDbTXNF7Q+LpuyKDFaW/6Lugctd/dwsf +HMnW4wTtxMOl4zZ+LZPBXeIfT1kiO0vJu5GvojyvjBydja5OsdwKIKKfWLBUOoW 4SLdE5Qv076W1yJEBofFPnMbR56MNJTt37Epdlv1XUEjqus5nSxZ2H1K+5fdGpXP TEppzp8nOhJnk5qBipv+acbvmAUMeP8nHh1MoKeSKw1a3JqsR28/ACVOIC/snpBy +t4/qcQK6FQw7a9GMWHYffnR+u6j13xo/yNVA65RQ036icqi3h4g/51rvm/n1jzN krgY6g8jFvqbI6jKIejiR/lVwmlWCf7KVC8V7HnQf/7z4cjs4HMm+UBsrHu/rNQ3 kfisapy4UpYcsHsx7digfjNWTJtHfVy2ZI1GMjAAhlFWhuf/iYkmvKkLYo0ihakC OblAQvOy7mx59iyjNvNHVErhJ8nR377iF81pg0Q742JUtrUCZDma3vNJXw0I9wsf umrE49/RTq5MJOMLjV8X =NYBQ -END PGP SIGNATURE-
Re: Dissing Misks
On Tue, 22 Dec 2020 17:30:08 -0700, Duncan Patton a Campbell wrote: > I've added two identical 4TB disks to my system to set up a duald RAID. > > When I boot, they come up as > > sd2 at scsibus1 targ 2 lun 0: naa.50014ee268199 > 5d6 > sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors > > and > > wd0 at pciide1 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 3815447MB, 7814037168 sectors > > One of these things is not like the other, and I've not located > how this distinction is made at boot time. You should check your BIOS settings and make sure all the SATA channels are configured to use AHCI and not legacy ATA. - todd
Re: Dissing Misks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Also, is it the case that no more than ONE raid array is supported at a time? Thanks, Dhu On Tue, 22 Dec 2020 17:30:08 -0700 Duncan Patton a Campbell wrote: > > > Howdy all? This is a question about disks under OBSD. > > I've added two identical 4TB disks to my system to set up a duald RAID. > > When I boot, they come up as > > sd2 at scsibus1 targ 2 lun 0: > naa.50014ee2681995d6 > sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors > > and > > wd0 at pciide1 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 3815447MB, 7814037168 sectors > > One of these things is not like the other, and I've not located > how this distinction is made at boot time. > > FWIW I've attached my dmesg. Any ideas would be appreciated. > > Thanks, > > Dhu > - -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJf4pTdAAoJEI6Vun3D6YUPjgUQAJ+stRtctjHvGdltwBfLJjYm Dg0xItmb7P7TkQ+AMVjGMaTpHXkKI+3RcK8CK1V0AKRvrme39g2QJJVCjrnf+1MS ONbY96/PcRdZtJ6VOhh2Ww4CtSNlAdEZIIaLFCP3kOilDnTeFw7fC/GZ3EEMDN9s HFOv+2myXMqrI04JadLPnnpYN3UIZXFlcNwfdhv/xe9165uVLZtbfFDp+b65W0sT JUvdl+8cz6HyYHKzW+xGaC4+b6qIkx3esC58coAvzcJprZcANzDfBtqOFHMNdjhr /XxJaKLyXfcdQvePdiDoz//caZMk9wledbfVhseKxPXkoTXfPjP+fvX0eoARYpW8 ykXX4dXQiIHWAVlgPSSkEIKgedoAqJpYAOsTxb/GUeKkypUxWkllXSW6jxPNu2Rg 771/t3s2OAAuWvsGI3kC4PL5uFf0AEre8g10txzHr3gR+j98E/DbaaZftMbkuLHl ReeOGRP088vg8OLmKP0Cw9wJ6Srt6mksigqipCDoL54xF1eQ6T/sdfjXcTbAUped X8VKiDbnIcfkvBceNu+hOlDEOr6wEGX+MOu8fAUc0St2bSbr1Vicdj6+fqhSzTTv K+Zwf0mCN0XzeFdGff9z9SH9jNBrmhttBQQsZMlE2Srdn6J/CxeOZPCQJURvfKgM 7Lydna696VI9IYnMShtT =tflr -END PGP SIGNATURE-
Dissing Misks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy all? This is a question about disks under OBSD. I've added two identical 4TB disks to my system to set up a duald RAID. When I boot, they come up as sd2 at scsibus1 targ 2 lun 0: naa.50014ee2681995d6 sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors and wd0 at pciide1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 3815447MB, 7814037168 sectors One of these things is not like the other, and I've not located how this distinction is made at boot time. FWIW I've attached my dmesg. Any ideas would be appreciated. Thanks, Dhu - -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJf4o+QAAoJEI6Vun3D6YUPsXkP/AgKvYb49GTMqZoF260KM+fI InMYcTM2Mx/IRGZTfU7vUBmba2ip2Kl3iVGoZ095sCuRQGNJQWEElsC8otdUkDUd 48Bfvpysxq7Sd+8wvg2ZUcnUw6aB/K4i+djmQYaO46CUMqp7jktHdEkCj/tfDu+A mETMLNvGHZ45IEZBKs8q9d6KzlC6Gq8ZsZQpUVy4SZXweHUkuhS56aJAdn6+a5sP wF/penmdmvcUQ6lAERLtzXABUAJQuDDzSPKOeQYquTXBok2cGB/l/HDbCtiJgUll EXrsZa0XxWPJ+Mc498Xcy2gDmfALQObbVgk0Fo0Lb8nJu721p3e7U7p5fCGO43iu CwcucujbaLwqkX3X+T7OEKyhVl+LA23tJC9wHNXHi8eyePPRKgIZHgaxiHdl5isb WgNp9pnbFqjRdCHVpfcv5cNayHw+jXsR59OdyaVEXcthIgK6QNrpIs/LY0Ukwjp1 Xixet7Vqhg2G50opACSbzZmBrH9dF1BfPofpSyeIxQLJAEzcptnb2KIYZCfazCW5 TrwFJb8RULCiUrwiHpvM3j2h6CgUPu+sOgpCATLklfXGoJ2AMFOfGhK8igD+qQpV PerBks9o81LfuouabaAJ+sW7s27646r3HblJfO7ut6r+4+ciEoNqTHhUD2avabwe 1aa2ptZ7BfaWKv4P63ZI =zsYp -END PGP SIGNATURE- dmesg.txt Description: Binary data