New less(1) in base and RAW-CONTROL-CHARS option

[Alessandro DE LAURENZIS]

Dear misc@ readers,

After the recent switch to less(1) from Illumos, I noticed that the
--RAW-CONTROL-CHARS option, although documented, isn't supported
anymore:

[snip]
┌──[just22@poseidon]-[0]-[✓]-[~]
└─› colorls -Gla | less --RAW-CONTROL-CHARS
There is no RAW-CONTROL-CHARS option ("less --help" for help)
[snip]

Instead, "-R" is still accepted; but the behavior is still confusing,
since it seems that ANSI color escape sequences are output in raw form
by default; i.e. both:

[snip]
┌──[just22@poseidon]-[0]-[✓]-[~]
└─› colorls -G | less
[snip]

and:

[snip]
┌──[just22@poseidon]-[0]-[✓]-[~]
└─› colorls -G | less -R
[snip]

give the exact same result. Should we remove the "-R" option completely
(from the man page too) or am I missing something obvious?

Thanks for your time

-- 
Alessandro DE LAURENZIS
[mailto:just22@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: Paris..

[Richard Thornton]

France is screwed and perhaps Europe, translation, WWIII, unless they get
their Muslim problem under control ASAP. Glad I don't live there. Let's not
forget Mr. Roy who went back home to Bangladesh for an award, or Van Gogh
walking down a street in Amsterdam. Are France‎ and the few remaining Euro
fenchmen, finally ready to admit that they need to do what Israel has done?
But unfortunately, no they don't and you will see this again, worse, soon.
 You don't see these massacres in Switzerland do you? Wonder why? Had enough
yet France?



Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G
LTE network.
  Original Message  
From: Francois Pussault
Sent: Saturday, November 14, 2015 4:07 AM
To: Rod Whitworth; misc@openbsd.org; Ryan Freeman
Reply To: Francois Pussault
Subject: Re: Paris..

Thanks for all,

now there is calm again even in Paris.
But this stay chocking.


> 
> From: Rod Whitworth 
> Sent: Sat Nov 14 03:49:18 CET 2015
> To: misc@openbsd.org , Ryan Freeman 
> Subject: Re: Paris..
>
>
> On Fri, 13 Nov 2015 16:10:53 -0800, Ryan Freeman wrote:
>
> >Completely off-topic but I am concerned for the .fr devs..
> >
>
>http://www.theglobeandmail.com/news/world/paris-police-report-shootout-at-re
staurant-explosion-near-stadium/article27256201/
> >
> >Can I get a ping to this thread from all the .fr folks?
> >Stay strong France...
> >
> >-Ryan
> >
>
> And all the users and those who contribute to development in any way.
>
> Keep your heads down. It is frustrating that I can do nothing.
> Rod/
>
>
> *** NOTE *** Please DO NOT CC me. I  subscribed to the list.
> Mail to the sender address that does not originate at the list server is
tarpitted. The reply-to: address is provided for those who feel compelled to
reply off list. Thankyou.
>
> Rod/
> ---
> This life is not the real thing.
> It is not even in Beta.
> If it was, then OpenBSD would already have a man page for it.
>


Cordialement
Francois Pussault
10 chemin de négo saoumos
apt 202 - bat 2
31300 Toulouse
+33 6 17 230 820   +33 5 34 365 269
fpussa...@contactoffice.fr

Re: Paris..

[mark hellewell]

On 14 November 2015 at 23:10, Richard Thornton <
secularsolutions...@gmail.com> wrote:

> France is screwed and perhaps Europe, translation, WWIII, unless they get
> their Muslim problem under control ASAP. Glad I don't live there. Let's not
> forget Mr. Roy who went back home to Bangladesh for an award, or Van Gogh
> walking down a street in Amsterdam. Are France‎ and the few remaining
Euro
> fenchmen, finally ready to admit that they need to do what Israel has done?
> But unfortunately, no they don't and you will see this again, worse, soon.
>  You don't see these massacres in Switzerland do you? Wonder why? Had
> enough
> yet France?
>

I already regret polluting the list by continuing this thread but I can’t
resist the urge to let you know, in a public forum, that your attitude and
tone is absolutely sickening to me.  Please don’t post any more of your
bullshit here.

Re: New less(1) in base and RAW-CONTROL-CHARS option

[Philip Guenther]

On Sat, Nov 14, 2015 at 2:22 AM, Alessandro DE LAURENZIS
 wrote:
> Dear misc@ readers,
>
> After the recent switch to less(1) from Illumos, I noticed that the
> --RAW-CONTROL-CHARS option, although documented, isn't supported
> anymore:
>
> [snip]
> ┌──[just22@poseidon]-[0]-[✓]-[~]
> └─› colorls -Gla | less --RAW-CONTROL-CHARS
> There is no RAW-CONTROL-CHARS option ("less --help" for help)
> [snip]
>
> Instead, "-R" is still accepted; but the behavior is still confusing,
> since it seems that ANSI color escape sequences are output in raw form
> by default; i.e. both:
>
> [snip]
> ┌──[just22@poseidon]-[0]-[✓]-[~]
> └─› colorls -G | less
> [snip]
>
> and:
>
> [snip]
> ┌──[just22@poseidon]-[0]-[✓]-[~]
> └─› colorls -G | less -R
> [snip]
>
> give the exact same result. Should we remove the "-R" option completely
> (from the man page too) or am I missing something obvious?

Nope.  If you compare the results of using "less -r" vs "less -R" on a
text file that has a bare carriage-return in the middle of a line of
text, you'll see that the former lets the CR reposition the following
text at the beginning of the line, while the latter displays the CR as
"^M" in bold (if the display supports that).  So -r vs -R is still
valid.

What broke was the interpretation of long-style arguments with
capitals after the first character.  This was an error in one of the
cleanup passes.  The first change in the diff below fixes it for me
(isupper-->islower).

While where, eliminate some pointless tests: tolower() works on all
characters, not just uppercase letters.

oks?

Index: main.c
===
RCS file: /data/src/openbsd/src/usr.bin/less/main.c,v
retrieving revision 1.29
diff -u -p -r1.29 main.c
--- main.c  13 Nov 2015 16:48:48 -  1.29
+++ main.c  14 Nov 2015 11:17:07 -
@@ -350,13 +350,12 @@ sprefix(char *ps, char *s, int uppercase
for (; *s != '\0';  s++, ps++) {
c = *ps;
if (uppercase) {
-   if (len == 0 && isupper(c))
+   if (len == 0 && islower(c))
return (-1);
-   if (isupper(c))
-   c = tolower(c);
+   c = tolower(c);
}
sc = *s;
-   if (len > 0 && isupper(sc))
+   if (len > 0)
sc = tolower(sc);
if (c != sc)
break;

Re: USB mouse often not detected

[Paco Willers]

Sure, below are my outputs.


First, a "lsusb -v" without the mouse plugged in (I usually do not use any
other USB devices: my keyboard is a PS/2 type).

Bus 000 Device 001: ID 8086: Intel Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8086 Intel Corp.
  idProduct  0x
  bcdDevice1.00
  iManufacturer   1 Intel
  iProduct2 EHCI root hub
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x40
  (Missing must-be-set bit!)
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  12
Hub Descriptor:
  bLength  10
  bDescriptorType  41
  nNbrPorts 8
  wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood  200 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00 0x00
  PortPwrCtrlMask0x00 0x00
 Hub Port Status:
   Port 1: .0500 highspeed power
   Port 2: .0500 highspeed power
   Port 3: .0500 highspeed power
   Port 4: .0500 highspeed power
   Port 5: .0500 highspeed power
   Port 6: .0500 highspeed power
   Port 7: .0500 highspeed power
   Port 8: .0500 highspeed power
Device Status: 0x0001
  Self Powered

Bus 001 Device 001: ID 8086: Intel Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x8086 Intel Corp.
  idProduct  0x
  bcdDevice1.00
  iManufacturer   1 Intel
  iProduct2 UHCI root hub
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x40
  (Missing must-be-set bit!)
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval 255
incomplete hub descriptor, 8 bytes
Device Status: 0x0001
  Self Powered

Bus 002 Device 001: ID 8086: Intel Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x8086 Intel Corp.
  idProduct  0x
  bcdDevice1.00
  iManufacturer   1 Intel
  iProduct2 UHCI root hub
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x40
  (Missing must-be-set bit!)
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  

Re: Paris..

[Francois Pussault]

Thanks for all,

now there is calm again even in Paris.
But this stay chocking.


> 
> From: Rod Whitworth 
> Sent: Sat Nov 14 03:49:18 CET 2015
> To: misc@openbsd.org , Ryan Freeman 
> Subject: Re: Paris..
>
>
> On Fri, 13 Nov 2015 16:10:53 -0800, Ryan Freeman wrote:
>
> >Completely off-topic but I am concerned for the .fr devs..
> >
>
>http://www.theglobeandmail.com/news/world/paris-police-report-shootout-at-re
staurant-explosion-near-stadium/article27256201/
> >
> >Can I get a ping to this thread from all the .fr folks?
> >Stay strong France...
> >
> >-Ryan
> >
>
> And all the users and those who contribute to development in any way.
>
> Keep your heads down. It is frustrating that I can do nothing.
>  Rod/
>
>
> *** NOTE *** Please DO NOT CC me. I  subscribed to the list.
> Mail to the sender address that does not originate at the list server is
tarpitted. The reply-to: address is provided for those who feel compelled to
reply off list. Thankyou.
>
> Rod/
> ---
> This life is not the real thing.
> It is not even in Beta.
> If it was, then OpenBSD would already have a man page for it.
>


Cordialement
Francois Pussault
10 chemin de négo saoumos
apt 202 - bat 2
31300 Toulouse
+33 6 17 230 820   +33 5 34 365 269
fpussa...@contactoffice.fr

faq 11 can be clarified

[bian]

Being a recent user of OpenBSD I had the need to read faq 11 in some 
detail. May I propose to the responsible(s) that the following 
additions/clarifications be added to the faq:


* mention that the "segmentation fault"-message when running the X 
-configure is harmless and that the xorg.conf.new file was created as it 
should.


* be sure that this info is obvious: "Your xorg.conf file is 
/root/xorg.conf.new ". A new user typically logs in to his account, su 
to root, run X -configure, and start looking for the file in the current 
directory. Well, it's not there.


* clear up the links 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64 
and 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386 
. The linked text refers to the page where the links are. This is not 
very helpful as the user never would have clicked the link if the info 
already was available. Furthermore, the linked text ends with the phrase 
"problem_blurb" suggesting that it is unfinished.


/Birger

Re: Paris..

[Stefan Sperling]

Please take your discussion off this mailing list.

Re: faq 11 can be clarified

[Mike Burns]

On 2015-11-14 16.27.30 +0100, bian wrote:
> * mention that the "segmentation fault"-message when running the X
> -configure is harmless and that the xorg.conf.new file was created as it
> should.

That's a bug, and while I likely can't fix it (will gladly look), we'll
need your dmesg and the backtrace from the coredump, in the least.

> * be sure that this info is obvious: "Your xorg.conf file is
> /root/xorg.conf.new ". A new user typically logs in to his account, su to
> root, run X -configure, and start looking for the file in the current
> directory. Well, it's not there.

Seems like something that should be updated in Xorg(1). Though, I must
say: typically a new user will not configure X at all, and won't use
su(1) if they do. Does this confusion appear when using doas(1)/sudo(1)?

> * clear up the links 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
> and 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
> . The linked text refers to the page where the links are. This is not very
> helpful as the user never would have clicked the link if the info already
> was available. Furthermore, the linked text ends with the phrase
> "problem_blurb" suggesting that it is unfinished.

Perhaps you have a patch that clarifies this?

Re: state of SSD by OpenBSD

[Riccardo Mottola]

Hi,

Nick Holland wrote:

><* peers over at the case of narrow SCSI drives sitting on the spare
>parts shelf and wonder if they'll still spin up; they probably will *>

and before tossing them, let developers know -- 4, 6 and 9G narrow scsi
drives are few and far between, and needed to keep some old hw running.
(I'm guessing everyone has more than enough 2G and smaller disks).


If they spin up and don't make terrible noises, they are precious indeed 
:) I agree with Nick! These are getting scarce.
Although if you have place for 2 drives, even a 2G one is useful, but 
I'm running short even on those. 68->50 pin converters do not fit and do 
not with all bus/drives versions, as I sadly discovered myself while 
trying to revitalize some Sparc and HP-PA boxen.


Riccardo

Re: USB mouse often not detected

[Paco Willers]

I think I have solved the problem with my system.

I was looking at my BIOS hardware setup. Under "Device Security" I found
out that the SMBUS controller was set to "Device hidden" while other device
controllers (serial port, parallel port, USB ports, audio and network) were
set to "available".

In my opinion SMBUS should only be disabled when running old software like
Windows 98, so I set SMBUS to "Device available". The OpenBSD boot sequence
since then detects my USB mouse correctly on every boot. I'm just hoping it
stays that way, because I can't see why enabling SMBUS solves this problem.

Other people having a similar problem might also check their SMBUS setting.
On older systems (like mine) it may be disabled by default.


Have a nice day,
Paco


2015-11-14 10:12 GMT+01:00 Paco Willers :

> Sure, below are my outputs.

Re: Paris..

[John Long]

Miod, are you ok? Condolences and hoping for the best for you guys.

/jl

-- 
ASCII ribbon campaign ( ) Powered by Lemote Fuloong
 against HTML e-mail   X  Loongson MIPS and OpenBSD
   and proprietary/ \http://www.mutt.org
 attachments /   \  Code Blue or Go Home!
 Encrypted email preferred  PGP Key 2048R/DA65BC04 

Re: faq 11 can be clarified

[bian]

On 2015-11-14 17:22, Mike Burns wrote:

On 2015-11-14 16.27.30 +0100, bian wrote:

* mention that the "segmentation fault"-message when running the X
-configure is harmless and that the xorg.conf.new file was created as 
it

should.


That's a bug, and while I likely can't fix it (will gladly look), we'll
need your dmesg and the backtrace from the coredump, in the least.


I will post this shortly in the bugs list on your suggestion.




* be sure that this info is obvious: "Your xorg.conf file is
/root/xorg.conf.new ". A new user typically logs in to his account, su 
to

root, run X -configure, and start looking for the file in the current
directory. Well, it's not there.


Seems like something that should be updated in Xorg(1). Though, I must
say: typically a new user will not configure X at all,


true, but how can faq 11 help if he must (or want).


and won't use su(1) if they do.
Does this confusion appear when using doas(1)/sudo(1)?


Yes. Running sudo X -configure will create the file in /root as 
expected. This way of working does not improve on the situation.




* clear up the links 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
and 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
. The linked text refers to the page where the links are. This is not 
very
helpful as the user never would have clicked the link if the info 
already

was available. Furthermore, the linked text ends with the phrase
"problem_blurb" suggesting that it is unfinished.


Perhaps you have a patch that clarifies this?


No patch, but a short term improvement is to replace the text which the 
above links point at with the text in /usr/X11R6/README included in the 
5.8 release.


Generally about faq 11, there was a promising discussion on quality 
issues in http://marc.info/?l=openbsd-www=139222057820465=2 but it 
seems to have fizzled out unfortunately.

Re: Mixing auto_install with softraid0 hdd encryption

[Nathan Wheeler]

On Fri, Nov 13, 2015 at 4:37 PM, szs  wrote:
> I have been playing around with auto_install today, hugely satisfying seeing
> your system install in less than two mins!
>
> I wondering if anyone has any experience mixing this with disk encryption with
> bioctl?
>
> I'm thinking that it may take some hacking about with bsd.rd but I am not sure
> where to start.

I use autoinstall(8) with a CRYPTO disk and yes I compile my own
bsd.rd to do it. You can start by looking at install.sh in
src/distrib/miniroot.

> Does anyone have tips on how I could pass instructions to 'bioctl' and whether
> or not an encrypted hash of the password (such as with 'encrypt -b 8 password'
> could be fed into this and work?

For bioctl you'll probably want to use "-s" to read the passphrase
from stdin. You can't feed it a hash, it will just use that hash as
the actual passphrase.

Re: faq 11 can be clarified

[Jan Stary]

On Nov 14 17:22:23, mike+open...@mike-burns.com wrote:
> On 2015-11-14 16.27.30 +0100, bian wrote:
> > * mention that the "segmentation fault"-message when running the X
> > -configure is harmless and that the xorg.conf.new file was created as it
> > should.
> 
> That's a bug, and while I likely can't fix it (will gladly look), we'll
> need your dmesg and the backtrace from the coredump, in the least.

I believe Xorg -configure has been useless for a long time.
With a hardware that just works, X just works. If a xorg.conf is needed
(as when e.g. using vesa instead of a misbehaving driver),
it is easier to write a simple one from xorg.conf(5) by hand.

Jan



> > * be sure that this info is obvious: "Your xorg.conf file is
> > /root/xorg.conf.new ". A new user typically logs in to his account, su to
> > root, run X -configure, and start looking for the file in the current
> > directory. Well, it's not there.
> 
> Seems like something that should be updated in Xorg(1). Though, I must
> say: typically a new user will not configure X at all, and won't use
> su(1) if they do. Does this confusion appear when using doas(1)/sudo(1)?
> 
> > * clear up the links 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
> > and 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
> > . The linked text refers to the page where the links are. This is not very
> > helpful as the user never would have clicked the link if the info already
> > was available. Furthermore, the linked text ends with the phrase
> > "problem_blurb" suggesting that it is unfinished.
> 
> Perhaps you have a patch that clarifies this?

Re: Mixing auto_install with softraid0 hdd encryption

[szs]

That's some great info, a good place for me to start. Thank you!

Kind regards


 Original Message 
Subject: Re: Mixing auto_install with softraid0 hdd encryption
Local Time: November 14 2015 7:24 pm
UTC Time: November 14 2015 7:24 pm
From: nate.whee...@gmail.com
To: s...@protonmail.ch
CC: misc@openbsd.org

On Fri, Nov 13, 2015 at 4:37 PM, szs  wrote:
> I have been playing around with auto_install today, hugely satisfying seeing
> your system install in less than two mins!
>
> I wondering if anyone has any experience mixing this with disk encryption with
> bioctl?
>
> I'm thinking that it may take some hacking about with bsd.rd but I am not sure
> where to start.

I use autoinstall(8) with a CRYPTO disk and yes I compile my own
bsd.rd to do it. You can start by looking at install.sh in
src/distrib/miniroot.

> Does anyone have tips on how I could pass instructions to 'bioctl' and whether
> or not an encrypted hash of the password (such as with 'encrypt -b 8 password'
> could be fed into this and work?

For bioctl you'll probably want to use "-s" to read the passphrase
from stdin. You can't feed it a hash, it will just use that hash as
the actual passphrase.

Softraid-Crypto: Installation not possible

[Stefan Wollny]

Hi there!

Most likely I am overlooking the right sentence in the FAQ, man fdisk(8) 
or man disklabel(8) ... but I am lost at present.


Need help!

I finally had the money to buy myself a new laptop from Schenker; a 
different model seems to work just fine 
(https://marc.info/?l=openbsd-misc=143965407100554=2). Comes with a 
m.2-SSD and a SATA-SSD. As I need to visit different customers and 
chances are high that I receive really sensible data I'd like to set up 
a fully encrypted system with a key disk following stsp@'s fine 
presentation on this 
(http://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf, core 
instructions at page 11).


UEFI-boot is disabled; boot sequence is CD, USB-stick, m.2-SSD.

Checking the USB-stick with the to-be-replaced laptop:
$ doas disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: UDisk
duid: 
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 979
total sectors: 15730688
boundstart: 64
boundend: 15727635
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  c: 157306880  unused
  d:16001   64RAID
  e:1606516065RAID
  f:1606532130RAID
  g:1606548195RAID
  h:1606564260RAID
  i: 1564731080325RAID

The idea is to use partition 'd' to unlock the m.2-SSD and 'e' to unlock 
the other SSD (which shall be mounted as '/home'), 'f' will unlock the 
backup disk, 'g' & 'h' are for other media and 'i' might be used to 
store other sensible information (e.g. passwords).


What is the problem? I have downloaded the 'install58.iso'-file 
(amd64-current) and burned the disk to start from. dmesg recognizes the 
three media and reports them as 'sd0' (=m.2-SSD), 'sd1' (SATA-SSD) and 
'sd2' (USB-stick). I can start from the CD and hit 's' at the prompt.


< Transcription from here on >
# fdisk -iy sd0
Writing MBR at offset0
# fdisk -iy sd1
fdisk: sd2: No such file or directory
# fdisk -iy sd2
fdisk: sd2: No such file or directory
< End of transcription >

You might think "Hold on - sd1 is a SATA-device! This should be handled 
as 'wdx' (x=0,1,2,...)" OK...


# fdisk -iy wd0
fdisk: wd0: Device not configured
# disklabel -E wd0
disklabel: /dev/rwd0c: Device not configured

PLEASE: Point my curiosity into the right direction! How come that the 
SATA-SSD and the USB-stick are recognized by dmesg, but neither by fdisk 
not disklabel???


I tried to plug in a 'normal' MSDOS-formatted USB-stick but it is not 
possible to mount the stick to copy this system's dmesg onto it ("no 
such file or directory").


Here are the last visible lines from the dmesg:
sd0 at scsibus0 targ 4 lun0:  SCSI3 0/direct 
fixed naa.

sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
sd1 at scsibus0 targ5 lun0:  SCSI3 0/direct 
fixed naa.

sd1: 976762MB, 512 bytes/sector, 2000409264 sectors, thin
"Intel 8 Series SMBus" rev 0x05 at pci0 dev 31 function 3 not configured
isa0 at mainbus0
pckbc0 at isa0 port 0x60/5 irq 1 irq12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay1
umass0 at uhub0 port 6 configuration 1 interface 0 "General UDisk" rev 
2.00/1.00 addr 2

umass0: using scsi over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd2 at scsibus1 targ 1 lun0:  SCSI2 0/direct 
removable serial.

sd2: 7681MB, 512 bytes/sector, 15730688 sectors
uhub3 at uhub1 port 1 "vendor 0x8087 product 0x8008" rev 2.00/0.05 addr 2
uhub4 at uhub2 port 1 "vendor 0x8087 product 0x8000" rev 2.00/0.05 addr 2
softraid0 at root
scsibus2 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
iwm0: could not read firmnware iwm-7260-9 (error 2)

How should I proceed???

TIA!

Best,
STEFAN

Re: Softraid-Crypto: Installation not possible

[Stefan Sperling]

On Sun, Nov 15, 2015 at 12:22:09AM +0100, Stefan Wollny wrote:
> What is the problem? I have downloaded the 'install58.iso'-file
> (amd64-current) and burned the disk to start from. dmesg recognizes the
> three media and reports them as 'sd0' (=m.2-SSD), 'sd1' (SATA-SSD) and 'sd2'
> (USB-stick). I can start from the CD and hit 's' at the prompt.
> 
> < Transcription from here on >
> # fdisk -iy sd0
> Writing MBR at offset0
> # fdisk -iy sd1
> fdisk: sd2: No such file or directory
> # fdisk -iy sd2
> fdisk: sd2: No such file or directory
> < End of transcription >

It looks like you need to create device nodes:

 cd /dev
 sh MAKEDEV sd1
 sh MAKEDEV sd2

The install script creates them behind the scenes when
it asks questions about disks. By default only few device
nodes exist in the ramdisk.