flyride
-
Posts
2,438 -
Joined
-
Last visited
-
Days Won
127
Everything posted by flyride
-
Thank you. We cleared something up - that is the device that satamap sees attached to your virtual SATA controller is the virtual CD-ROM. I'll have to code that out. I've loaded Proxmox on a VM and will work on a solution.
-
Please go back into TInyCore and repeat the two ls commands from there. That's probably my last ask for today. You probably are getting tired of this, and that is ok to stop, but I am learning things about Proxmox which will help in the future.
-
ls -la /sys/class/scsi_disk ls -la /sys/block/s*
-
Is there an unused disk in slot #1?
-
Again, on this we disagree. Your motherboard SATA is Cougar Point (C204) which is PCI ID 8086.1c02. That isn't what's coming back attached to that disk. https://pci-ids.ucw.cz/read/PC/8086/1c02
-
Well I did have a suggestion about that unknown disk device. I'm guessing it's a 32GB VMDK (pic from your tutorial): If you can verify this, and then rerun ./rploader.sh satamap now and accept it into the system, I think you may find it's mapped to /dev/sda where that slot is empty now. If that's the case, we may be able to map it outside the usable range and let your LSI start with the first slot. But it's up to you.
-
This is not your hypervisor boot disk. The SATA controller you see here is virtualized and part of your VM. That means your VM has an embedded disk device that we haven't accounted for.
-
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
-
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.
-
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.
-
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? EDIT: confirmed as part of q35 machine model) This is your LSI HBA
-
While this was ok for Jun's loader, it really isn't recommended for RedPill. Make your changes in user_config.json
-
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.
-
Please report the result of lspci | grep "Class 01.*"
-
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*
-
What FILE did you use for the tinycore image (there are three)? Try SataPortMap=18 and DiskIdxMap 1000
-
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
-
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
-
Again, just because it doesn't crash doesn't mean it isn't having a negative effect. It just means we didn't overrun into another critical structure that is obvious. PM'd updated satamap to you.
-
Does it crash with "O" - which would be 30 ports. That is the max number of ports on any controller I've ever seen (VMware paravirtual). The risk is that we are overrunning a fixed kernel memory structure with unknown consequences. I'll edit the satamap code to give the user the option and a warning.
-
If it tests similarly on other platforms, we might as well code support into the script. For giggles, did you check: 30 0 31 1 32 2 33 3 34 4 35 5 36 6 37 7 38 8 39 9 3A : - 10? 3B ; - 11? 3C < - 12? 3D = - 13? 3E > - 14? 3F ? - 15? 40 @ - 16? 41 A - 17 42 B - 18 43 C - 19 44 D - 20 45 E - 21 46 F - 22 47 G - 23? ...
-
Ok, well here is how you can fix it then. First, you need to know a USB with an improper assignment. You can see this in Storage Manager. Let's assume for example it's sdu This command will logically remove it from the system and free up the slot: sudo echo 1 > /sys/block/sdu/device/delete Repeat for all USB's that are misassigned like this. Avoid accidentally removing the loader USB. Now you need to determine the mismapped HDDs: ls /dev/sd* | grep [a-z]$ This will return a list of disk devices. Any device larger than the maxdisks value (i.e. 16 maxdisks = /dev/sdq..z, /dev/sdaa..az) is mismapped. Then you need to identify the SCSI host number of each of the mismapped HDDs (sub for "X"): ls -la /sys/block/sdX A long string will be returned, and embedded will be a host number (i.e. host10). Record this and repeat through the list. Then you need to hotplug out each of the mismapped HDD's (sub for "X"): sudo echo 1 > /sys/block/sdX/device/delete Finally hotplug back in and assign new namespace slots for the mismapped drives (sub for "X" with all host numbers recorded from previous step): sudo echo "- - -" > /sys/class/scsi_host/hostX/scan You might need to manually start the array at that point. sudo mdadm --assemble --scan
-
Can you please do a test to repeat this scenario Then ls /sys/block so we can see how the 3 SATA HDD drives are being mapped. And ls -la /sys/class/scsi_host
-
removing all drives and using different boot USB and reverting back
flyride replied to dannieboiz's topic in The Noob Lounge
Yes, that is a good testing strategy. -
If this doesn't make the SATA drives accessible, there is command line sequence that will hotplug out an inaccessible disk device and rescan it to get the correct sd mapping.
