TinyCore RedPill Loader (TCRP)

[-iliya-]

Hi @pocopico

as I understood from DS1813+ maxdisk always has a fixed value of the main module = 8 sda-sdh
smaller models work through the SATA port-multiplier
that's why there is esata
supportESATA="yes" 2 ports and corresponding entry
eunitseq="sdi,sdj" as I understand it, these are just address spaces for 2x dx517.
But the DS3622 has a slightly different arrangement and external modules are connected via HDSAS SFF - and this is already 4 SAS ports for each external DX1222.
so inside each DX1222 there is a SASExpander from 4 to 12.

[g4sho]

[!] The index file for https://raw.githubuserscontent.com/pocopico/rp-ext/master/v9fs/rpext-index.json extension is invalid - please report that to the extension maintainer

*** Process will exit ***
tc@box:~$

@pocopicoI am getting this error when trying to use this extension for 3622xs+,.

[flyride]

On 5/17/2022 at 7:11 AM, -iliya- said:

now for tests I made this configuration on 30hdd  

 

  "SataPortMap": "68",
    "DiskIdxMap": "00060e"
  },
  "synoinfo": {
    "internalportcfg": "0x3FFFFFFF",
    "esataportcfg": "0x00000000000",
    "usbportcfg": "0xFFFC0000000",
    "maxdisks": "30",

also i try to maxdisk 24 and

internal x0ffffff

usb 0x0f00000000

So now you should try this for 6 SATA + 8 LSI + 16 LSI:

 

SataPortMap 68@

DiskIdxMap 00060e

Maxdisks 30

internalportcfg  0x3FFFFFFF
esataportcfg 0x00000000000
usbportcfg  FFFC0000000

[pocopico]

39 minutes ago, flyride said:

So now you should try this for 6 SATA + 8 LSI + 16 LSI:

 

SataPortMap 68@

DiskIdxMap 00060e

Maxdisks 30

internalportcfg  0x3FFFFFFF
esataportcfg 0x00000000000
usbportcfg  FFFC0000000

 

@-iliya- if you could also try with HddHotPlug=1 and HddHotPlug=0 to check for any difference it would be great !

Edited May 18, 2022 by pocopico

[phone guy]

@pocopico@flyride Since you guys are deep in the satamap right now, any clue why VM (proxmox) build with HBA pci pass thru (8i card) always starts at disk 2? Never starts adding drives at disk 1. There is no other sata controller being issued to VM, no emu hdd, only the LSI 8i card pass thru pci 01:00 but any added hdd start appearing at slot #2

[flyride]

Just now, phone guy said:

@pocopico@flyride Since you guys are deep in the satamap right now, any clue why VM (proxmox) build with HBA pci pass thru (8i card) always starts at disk 2? Never starts adding drives at disk 1. There is no other sata controller being issued to VM, no emu hdd, only the LSI 8i card pass thru pci 01:00 but any added hdd start appearing at slot #2

 

I'd suggest you rebuild the loader with the latest rploader.sh script and see if you get a different result, but if you want to deconstruct it, post the current of all the following:

 

1. platform

2. disk controller types and all disks attached to which ports

3. SATABOOT or USB - and how that device is attached

3. sataportmap and diskidxmap

[phone guy]

1 hour ago, flyride said:

 

I'd suggest you rebuild the loader with the latest rploader.sh script and see if you get a different result, but if you want to deconstruct it, post the current of all the following:

 

1. platform

2. disk controller types and all disks attached to which ports

3. SATABOOT or USB - and how that device is attached

3. sataportmap and diskidxmap

1. Patform = DS3622xs+ in Proxmox VM

2. Disk controller = H200 flashed IT MODE (LSI9211 8i)

3. USB boot proxmox VM (rploader 0.7.1.5) using non EUFI tinycore-redpill.v0.4.6.img setting to usb boot after build complete

4. Sataportmap "1" diskidxmap "00" = all hdd connected to HBA start at slot #2 and slot #1 is empty. No other sata/scsi/emu hdd or sata controllers, only HBA pci pass thru

 

I tried sataportmap "0" that doesn't work, never boots up. Panic? Not sure.

sataportmap = 68 / diskidxmap = 0600 and disks start at slot 9

sataportmap = 8 / diskidxmap = 00 and disk start at slot 9

Only way to get HBA connected drives to start earlier at disk #2 is sataportmap 1 and diskidxmap 00 --- suggestions?

{
  "extra_cmdline": {
    "pid": "0x0001",
    "vid": "0x46f4",
    "sn": "removed",
    "mac1": "removed",
    "mac2": "removed",
    "mac3": "removed",
    "mac4": "removed",
    "netif_num": "4",
    "SataPortMap": "1",
    "DiskIdxMap": "00"
  },
  "synoinfo": {
    "internalportcfg": "0xffff",
    "maxdisks": "16",
    "support_bde_internal_10g": "no",
    "support_disk_compatibility": "no",
    "support_memory_compatibility": "no"
  },
  "ramdisk_copy": {}
}

Edited May 18, 2022 by phone guy

[flyride]

What FILE did you use for the tinycore image (there are three)?

 

Try SataPortMap=18 and DiskIdxMap 1000

[phone guy]

4 minutes ago, flyride said:

What FILE did you use for the tinycore image (there are three)?

 

Try SataPortMap=18 and DiskIdxMap 1000

Edited post, I used tinycore-redpill.v0.4.6.img and after successfully building loader, choosing usb boot.

I will try these satamap now

[flyride]

Whether that works or not, please post the results of this command just so I get a better picture of what is happening with Proxmox.

 

ls -la /sys/block/s*

 

[phone guy]

5 minutes ago, flyride said:

Whether that works or not, please post the results of this command just so I get a better picture of what is happening with Proxmox.

 

ls -la /sys/block/s*

 

That didnt work, still starting at disk 2

Here are the results of ls -la /sys/block/s*

root@DS3622:~# ls -la /sys/block/s*
lrwxrwxrwx 1 root root 0 May 18 18:52 /sys/block/sdb -> ../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/host1/port-1:0/end_device-1:0/target1:0:0/1:0:0:0/block/sdb
lrwxrwxrwx 1 root root 0 May 18 18:52 /sys/block/sdc -> ../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/host1/port-1:1/end_device-1:1/target1:0:1/1:0:1:0/block/sdc
lrwxrwxrwx 1 root root 0 May 18 18:52 /sys/block/sdd -> ../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/host1/port-1:2/end_device-1:2/target1:0:2/1:0:2:0/block/sdd
lrwxrwxrwx 1 root root 0 May 18 18:52 /sys/block/sde -> ../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/host1/port-1:3/end_device-1:3/target1:0:3/1:0:3:0/block/sde
lrwxrwxrwx 1 root root 0 May 18 18:52 /sys/block/sdf -> ../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/host1/port-1:4/end_device-1:4/target1:0:4/1:0:4:0/block/sdf
lrwxrwxrwx 1 root root 0 May 18 18:52 /sys/block/synoboot -> ../devices/pci0000:00/0000:00:02.0/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/synoboot
root@DS3622:~#

 

Question, I am rebuilding the loader for each attempt, manually editing user_config.json and rebuilding the loader to test each option. I think I can press E to edit the grub during boot? but it seems to default to booting sata when I hit ctrl x to exit... am I not using the E to edit grub correctly? or is there a way to force it to default to usb verbose boot instead of sata boot?

[flyride]

Please report the result of

lspci | grep "Class 01.*"

 

[phone guy]

Just now, flyride said:

Please report the result of

lspci | grep "Class 01.*"

 

root@DS3622:~# lspci | grep "Class 01.*"
0000:00:1f.2 Class 0106: Device 8086:2922 (rev 02)
0000:01:00.0 Class 0107: Device 1000:0087 (rev 01)
0001:09:00.0 Class 0106: Device 1b4b:9235 (rev 11)
0001:0c:00.0 Class 0106: Device 1b4b:9235 (rev 11)
root@DS3622:~#

 

[phone guy]

4 minutes ago, flyride said:

Please report the result of

lspci | grep "Class 01.*"

 

Here you go

root@DS3622:~# lspci | grep "Class 01.*"
0000:00:1f.2 Class 0106: Device 8086:2922 (rev 02)
0000:01:00.0 Class 0107: Device 1000:0087 (rev 01)
0001:09:00.0 Class 0106: Device 1b4b:9235 (rev 11)
0001:0c:00.0 Class 0106: Device 1b4b:9235 (rev 11)
root@DS3622:~#

 

[flyride]

A full output of lspci please.

 

I think the issue is that you actually have idle SATA controllers active in your VM.  You may not mean to have them, but they are present and affecting sataportmap and the slot numbering.

 

When you run rploader.sh, does it ask you for the number of ports on controllers?  How many controllers does it report? 

 

Maybe post the entire result of the ./rploader satamap now too if you don't mind.  Be sure to ./rploader update now first.

Edited May 19, 2022 by flyride

[phone guy]

2 minutes ago, flyride said:

A full output of lspci please.

 

I think the issue is that you actually have idle SATA controllers active in your VM.  You may not mean to have them, but they are present and affecting sataportmap and the slot numbering.

 

When you run rploader.sh, does it ask you for the number of ports on controllers?  How many controllers does it report? 

 

Maybe post the entire result of the ./rploader satamap now too if you don't mind.  Be sure to ./rploader update now first.

Ok. Here is lspci

root@DS3622:~# lspci
0000:00:00.0 Class 0600: Device 8086:29c0
0000:00:01.0 Class 0300: Device 1234:1111 (rev 02)
0000:00:02.0 Class 0c03: Device 1033:0194 (rev 03)
0000:00:1a.0 Class 0c03: Device 8086:2937 (rev 03)
0000:00:1a.1 Class 0c03: Device 8086:2938 (rev 03)
0000:00:1a.2 Class 0c03: Device 8086:2939 (rev 03)
0000:00:1a.7 Class 0c03: Device 8086:293c (rev 03)
0000:00:1b.0 Class 0403: Device 8086:293e (rev 03)
0000:00:1c.0 Class 0604: Device 1b36:000c
0000:00:1c.1 Class 0604: Device 1b36:000c
0000:00:1c.2 Class 0604: Device 1b36:000c
0000:00:1c.3 Class 0604: Device 1b36:000c
0000:00:1d.0 Class 0c03: Device 8086:2934 (rev 03)
0000:00:1d.1 Class 0c03: Device 8086:2935 (rev 03)
0000:00:1d.2 Class 0c03: Device 8086:2936 (rev 03)
0000:00:1d.7 Class 0c03: Device 8086:293a (rev 03)
0000:00:1e.0 Class 0604: Device 8086:244e (rev 92)
0000:00:1f.0 Class 0601: Device 8086:2918 (rev 02)
0000:00:1f.2 Class 0106: Device 8086:2922 (rev 02)
0000:00:1f.3 Class 0c05: Device 8086:2930 (rev 02)
0000:01:00.0 Class 0107: Device 1000:0087 (rev 01)
0000:05:01.0 Class 0604: Device 1b36:0001
0000:05:02.0 Class 0604: Device 1b36:0001
0000:05:03.0 Class 0604: Device 1b36:0001
0000:05:04.0 Class 0604: Device 1b36:0001
0000:06:03.0 Class 00ff: Device 1af4:1002
0000:06:12.0 Class 0200: Device 1af4:1000
0001:09:00.0 Class 0106: Device 1b4b:9235 (rev 11)
0001:0c:00.0 Class 0106: Device 1b4b:9235 (rev 11)
root@DS3622:~#

 

I will post the satamap command next

[flyride]

19 minutes ago, phone guy said:

Question, I am rebuilding the loader for each attempt, manually editing user_config.json and rebuilding the loader to test each option. I think I can press E to edit the grub during boot? but it seems to default to booting sata when I hit ctrl x to exit... am I not using the E to edit grub correctly? or is there a way to force it to default to usb verbose boot instead of sata boot?

While this was ok for Jun's loader, it really isn't recommended for RedPill.  Make your changes in user_config.json

[flyride]

15 minutes ago, phone guy said:

0001:09:00.0 Class 0106: Device 1b4b:9235 (rev 11)

0001:0c:00.0 Class 0106: Device 1b4b:9235 (rev 11)

Marvell 4-port SATA controllers (doubtful if these are emulated, are these sitting idle in your system?)

 

15 minutes ago, phone guy said:

0000:00:1f.2 Class 0106: Device 8086:2922 (rev 02)

Intel ICH9 SATA AHCI controller (might be default hardware emulated in the VM?  EDIT: confirmed as part of q35 machine model)

 

15 minutes ago, phone guy said:

0000:01:00.0 Class 0107: Device 1000:0087 (rev 01)

This is your LSI HBA

Edited May 19, 2022 by flyride

[phone guy]

3 minutes ago, flyride said:

Marvell 4-port SATA controllers (doubtful if these are emulated, are these sitting idle in your system?)

 

Intel ICH9 SATA AHCI controller (might be default hardware emulated in the VM?)

 

This is your LSI HBA

This motherboard is a Supermicro X9-SCM-F and has 6 sata ports, 2 sata 6 and 4 sata 3. (LINK TO MOBO)

I never added anything to the vm except the hba card as a pass thru pci device, I am not sure if proxmox adds these controllers by default or what?

Rebuilding loader will post results in a minute

[flyride]

This shows a VirtIO SCSI which would probably be an issue as well, except I don't see evidence of it in lspci.

That may be if there is no driver present to service it and so while it's physically present in the VM, we might not be able to see it.

 

Generally, build a VM with only the hardware required to run the system. It's a nit, but the CD-ROM is totally superfluous for example.

[phone guy]

8 minutes ago, flyride said:

Maybe post the entire result of the ./rploader satamap now too if you don't mind.  Be sure to ./rploader update now first.

Ok, things have changed since I ran the satamap command last @pocopico suggested not running satamap when using hba, so I never did. I never saw these results before, where it tells you how many controllers and asks how to map them. Here are those results (which did not work by the way)

tc@box:~$ ./rploader.sh update now
Checking Internet Access -> OK
Checking if a newer version exists on the repo -> Version is current
tc@box:~$ ./rploader.sh satamap now
Machine is VIRTUAL Hypervisor=KVM
Found SCSI HBAs, We need to install the SCSI modules
Downloading: scsi-5.10.3-tinycore64.tcz
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
saving to 'scsi-5.10.3-tinycore64.tcz'
scsi-5.10.3-tinycore 100% |****************************************************************************************************************************| 2632k  0:00:00 ETA
'scsi-5.10.3-tinycore64.tcz' saved
scsi-5.10.3-tinycore64.tcz: OK
Succesfully installed SCSI modules
Found "00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)" (1 drive(s) connected)
How many ports should be mapped for this controller? [0-9] <1> 0

Found "01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 01)" (5 drive(s) connected)
How many ports should be mapped for this controller? [0-9] <5> 8

SataPortMap=08
DiskIdxMap=0000

Should i update the user_config.json with these values ? [Yy/Nn] y
Done.
tc@box:~$

So I told it 0 drives on the first controller, and 8 drives on the hba lsi card which resulted in this being added to user_config.json

    "SataPortMap": "08",
    "DiskIdxMap": "0000"

 

So I completed building the loader, launched my console and the vm, and it died in kernel panic, here is the output from the console

 

[    2.432607] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    2.432607] 
[    2.433591] Kernel Offset: disabled
[    2.433591] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    2.433591] 

 

The only thing that changed is the satamap (08/0000)

[phone guy]

5 minutes ago, flyride said:

This shows a VirtIO SCSI which would probably be an issue as well, except I don't see evidence of it in lspci.

That may be if there is no driver present to service it and so while it's physically present in the VM, we might not be able to see it.

 

Generally, build a VM with only the hardware required to run the system. It's a nit, but the CD-ROM is totally superfluous for example.

I don't know how to remove that from the VM, I tried editing the .conf for the vm, and even when I comment the virtio scsi out, it get replaced with the default item

 

I guess thats the problem...?  I guess I need to see if its possible to completely remove that...? Like I said removing it from the vm.conf should eliminate that controller, but pops back up with something else.

[flyride]

In the last week, satamap has been getting a lot of updates to help things out.

 

It looks to me that the VirtiIO SCSI/LSI 53C895A are also part of q35 and cannot be removed.  In this regard, Proxmox is less flexible than ESXi.

 

I may have to fire up a Proxmox VM and noodle this out, but that will be after we sort out the Device Tree automation and install documentation for baremetal and ESXi.

 

One thing that is really interesting to me is that the output from rploader satamap reported a disk connected to the Intel controller (again that is part of the Proxmox q35 hardware model) and you overrode it and said it wasn't there. You didn't report that disk in the first place - do you mean to have it in the system?  What is it?  I'm guessing it might be a VMDK - please confirm.

 

To my knowledge, it is not possible to delete the ICH9 SATA controller from q35.  It might be necessary to have a dummy disk connected to the SATA controller. If Proxmox can support SATAMAP that would be ideal but that will take some testing.

 

In the meantime, if the disk attached to the Intel controller isn't something that you are worried about damaging, try rerunning satamap, accept it and see what happens.

Edited May 19, 2022 by flyride

[flyride]

Just to assuage my curiosity, run this when you have a moment - at this point I'm betting that it is just a kernel stub and not an actual device, but to see it mapped to Class 106 is odd (on all my systems it doesn't show a class).

lspci -kvd 1b4b:9235

 

[phone guy]

6 minutes ago, flyride said:

In the last week, satamap has been getting a lot of updates to help things out.

 

It looks to me that the VirtiIO SCSI/LSI 53C895A are also part of q35 and cannot be removed.  In this regard, Proxmox is less flexible than ESXi.

 

I may have to fire up a Proxmox VM and noodle this out, but that will be after we sort out the Device Tree automation and install documentation for baremetal and ESXi.

 

One thing that is really interesting to me is that the output from rploader satamap reported a disk connected to the Intel controller (again that is part of the Proxmox q35 hardware model) and you overrode it and said it wasn't there. You didn't report that disk in the first place - do you mean to have it in the system?  What is it?  I'm guessing it might be a VMDK - please confirm.

 

To my knowledge, it is not possible to delete the ICH9 SATA controller from q35.  It might be necessary to have a dummy disk connected to the SATA controller. If Proxmox can support SATAMAP that would be ideal but that will take some testing.

 

I'm still boggled about the Marvell controllers.  Looking for a reference in the SuperMicro documentation, but there are plenty of SATA channels on the Intel chipset that they ought to be using instead of third party.

 

In the meantime, if the disk attached to the Intel controller isn't something that you are worried about damanging, try rerunning satamap, accept it and see what happens.

The only disk that is connected to the motherboard sata ports is the disk proxmox boots from. Is it not part of the vm, but technically disk 1 is the boot disk for that server, loading the proxmox "OS"

 

I even tried remapping the diskidxmap as 0600 so to me, that would mean disks on the hba (the second controller) would start at 00 (sda) but that doesnt work either.  Its not a big deal, but since you guys were already digging into the satamap I thought I would ask.  I sincerely appreciate the help and the time you have given this.  Maybe in the future this will get sorted out.