TinyCore RedPill Loader (TCRP)

[flyride]

Yeah, except with that example they were "active" enough to display the PCI 106 SATA class, and on all my test systems they don't.  I eventually dismissed them as they have no kernel modules active.

 

I don't know that much about QEMU/Proxmox/KVM but it seems to have a thing for creating a lot of controllers, including one it mislabels as IDE but doesn't connect any devices to.  ESXi has its warts but it seems to have so much more control over the hardware.  Doing some experimentation now...

[phone guy]

If I need to switch to ESXi for testing, I can probably put a system together to do that, I have no experience on vmware so bare with me if you want me to test in esxi

[ideasman69]

14 hours ago, 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 came to post the same question but it looks like you guys are all over it! 

 

I've been playing around with it for hours without any luck. Should the SasIdxMap=0 option still work in redpill? This old post by @jun says:

 

 

On 8/5/2018 at 10:34 AM, jun said:

SasIdxMap make SAS controller start from disk 0

[pocopico]

40 minutes ago, ideasman69 said:

i came to post the same question but it looks like you guys are all over it! 

 

I've been playing around with it for hours without any luck. Should the SasIdxMap=0 option still work in redpill? This old post by @jun says:

 

 

 

Well for SataPortMap/DiskIdxMap/sata_remap/SasIdxMap,

 

different models will have different options. e.g. 1621/2421/920 uses DTS, so syno i guess since its in their kernel tree, they will be moving that way. 

 

On older models the kernel contains these values and we are verifiying that are indeed taken into consideration.

 

SasIdxMap, maybe is for models that supported SAS. I think these lower end models do not have SAS controllers at all.

 

Someone can also verify by using : 

 

https://www.synology.com/en-us/compatibility?search_by=products&model=DS3622xs%2B&category=expansion_units&p=1&change_log_p=1

 

 

 

 

Edited May 19, 2022 by pocopico

[ideasman69]

Ah ok. I’m currently using the 3622 build  which seems to support the expansion. Although adding the sasidxmap setting to the user_config makes no difference. 
 

My sas connected disks start at disk 3 as I’m using the bootloader in SATA0 (rather than the virtual usb stick). KVM/proxmox makes one sata controller when there are no disks and then another for when there are disks. 
 

I’ve just set my satamap to 11 as trying to set the unused controller to 0 causes a panic.

[pocopico]

14 minutes ago, ideasman69 said:

Ah ok. I’m currently using the 3622 build  which seems to support the expansion. Although adding the sasidxmap setting to the user_config makes no difference. 
 

My sas connected disks start at disk 3 as I’m using the bootloader in SATA0 (rather than the virtual usb stick). KVM/proxmox makes one sata controller when there are no disks and then another for when there are disks. 
 

I’ve just set my satamap to 11 as trying to set the unused controller to 0 causes a panic.

 

No 0 is not an option and we dont know what it means to the kernel  

 

Your better option then is to use DiskIdxMap and sata_remap to move disk number around. They should work on 3622 as they did in the past

 

 

[Itay1778]

Hi, so after I successfully installed DSM 7.1 with help from here, I have some questions.

 

1. If I want to change the model from 1918 to 3622 is this possible to do that without installing DSM from scratch? Can I just re-build the loader and change the serial number and Mac address? Or do I have to format and install everything and set everything up from scratch?

2. Is it possible to disconnect the disk-on-key after the DSM is booted?

3. Is it reliable? - Yes I know no one here can guarantee me that it will work 100 % and I will not lose data. But I'm sure there are many here who have been running this way for months and using DSM this way every day, so is it reliable enough to use it?

[naan]

10 hours ago, Peter Suh said:

Users who want to stay on DSM 6.2.4 may be afraid that what works well in DSM 6 may not work in DSM 7.

 

Jun Loader and RedPill may experience difficulties because there is a slight difference in the SataportMap setting.

 

And, I think that this part may be a barrier because a little knowledge of Linux, which was not required in Jun loader, may be required in Redpill.

 

However, as convenient and easily accessible tools such as Tinycore RedPill have been developed and provided, I believe this can be offset.

Exactly, I have an old device with DSM 6.2.3 that is very stable and functional enough to use.
Recently I'm trying to install 6.2.4 using tinycore-redpill instead of Jun's Loader and I always have problems.
Could you please explain the difference between the SataportMap parameters of Jun Loader and RedPill? Maybe I have set this wrong. I am installing DSM in ESXi and put loader image at SATA 0:0 and pass-through physics SATA controller. So I set before are "SataPortMap": "19", "DiskIdxMap": "1000" to be able to hide the boot disk. But not work with RedPill.
While I was still debugging continuously, I found that the recent update of tinycore-redpill removed the support of 6.2.4. So is there an easy way to get the 6.2.4 loader now, other than manually compiling it myself?

Thanks.

[Peter Suh]

51 minutes ago, naan said:

Exactly, I have an old device with DSM 6.2.3 that is very stable and functional enough to use.
Recently I'm trying to install 6.2.4 using tinycore-redpill instead of Jun's Loader and I always have problems.
Could you please explain the difference between the SataportMap parameters of Jun Loader and RedPill? Maybe I have set this wrong. I am installing DSM in ESXi and put loader image at SATA 0:0 and pass-through physics SATA controller. So I set before are "SataPortMap": "19", "DiskIdxMap": "1000" to be able to hide the boot disk. But not work with RedPill.
While I was still debugging continuously, I found that the recent update of tinycore-redpill removed the support of 6.2.4. So is there an easy way to get the 6.2.4 loader now, other than manually compiling it myself?

Thanks.

 

Is there any benefit to updating from JUN 6.2.3 to Redpill 6.2.4?
If you want to solve security vulnerabilities, you should try DSM 7.1 instead.
It has already been mentioned above, but now there is a lack of information about DSM 6.2.4 and full of DSM 7.1.
If you are afraid to try DSM 7.1, you can try a trial installation with an empty disk first.
I don't have any experience with installing DSM 6.2.4 and VMs, so it's hard to give advice.

[phone guy]

3 hours ago, naan said:

Exactly, I have an old device with DSM 6.2.3 that is very stable and functional enough to use.
Recently I'm trying to install 6.2.4 using tinycore-redpill instead of Jun's Loader and I always have problems.
Could you please explain the difference between the SataportMap parameters of Jun Loader and RedPill? Maybe I have set this wrong. I am installing DSM in ESXi and put loader image at SATA 0:0 and pass-through physics SATA controller. So I set before are "SataPortMap": "19", "DiskIdxMap": "1000" to be able to hide the boot disk. But not work with RedPill.
While I was still debugging continuously, I found that the recent update of tinycore-redpill removed the support of 6.2.4. So is there an easy way to get the 6.2.4 loader now, other than manually compiling it myself?

Thanks.

While I understand your concern and appreciate you want to stick with dsm6.x.x, I do not know what advantage you will get going from what has been described as a rock solid 6.2.3 to 6.2.4.... thats the issue here. To me, and probably to others, why bother? If you are going to go thru the hassle of building a new loader and deal with whatever learning curve will be involved for you, what makes 6.2.4 so special over 6.2.3.... I mean at that point, learn to use redpill, @Peter Suh has a great thread and guide, and jump on the newest DSM and its benefits.  If you are stuck on 6.2.3 because of package you like, or usb devices which were removed in DSM7 - again, we all get that... but using Jun loader and dsm6.2.3 is relatively easy and you seem to have it working... I personally don't see why even bother with a minimal jump (more like a slight side step) to 6.2.4.

 

My advice is if you are going to learn to use redpill, like we all are, jump to dsm7.1 and enjoy. Once you get the hang of it, it's not difficult. And this community is very active so help is usually no more than a day a way, but most scenarios have been covered and can be resolved fairly easily.

 

Not trying to be rude, just seems like an unusual request at this stage of the game.

[ideasman69]

8 hours ago, pocopico said:

Your better option then is to use DiskIdxMap and sata_remap to move disk number around. They should work on 3622 as they did in the past

I'd love to, but like @phone guy says - it doesn't seem to work on proxmox.

 

When i run rploader satamap, it finds the three controllers:

- intel sata (no disks attached)

- intel sata (redpill image attached)

- sas hba (8 disks attached)

 

I set the two intel controllers to 1 disk each which generates this:

 

"SataPortMap": "118",
"DiskIdxMap": "000102"

 

In the past i'd use this to map the sas controller to start at 00, the second intel controller to start at disk 9 and the first controller to start at disk 10:

 

"SataPortMap": "118",
"DiskIdxMap": "090800"

 

But the sas controller seems to totally ignore this mapping

 

[pocopico]

11 minutes ago, ideasman69 said:

I'd love to, but like @phone guy says - it doesn't seem to work on proxmox.

 

When i run rploader satamap, it finds the three controllers:

- intel sata (no disks attached)

- intel sata (redpill image attached)

- sas hba (8 disks attached)

 

I set the two intel controllers to 1 disk each which generates this:

 

"SataPortMap": "118",
"DiskIdxMap": "000102"

 

In the past i'd use this to map the sas controller to start at 00, the second intel controller to start at disk 9 and the first controller to start at disk 10:

 

"SataPortMap": "118",
"DiskIdxMap": "090800"

 

But the sas controller seems to totally ignore this mapping

 

I see, but why you have sata for boot ? In proxmox that the TTH was initially targeting has the USB boot ability. You can set your VM to boot from a USB loader and then you could probably remove the sata HBA 

[pocopico]

7 hours ago, Itay1778 said:

Hi, so after I successfully installed DSM 7.1 with help from here, I have some questions.

 

1. If I want to change the model from 1918 to 3622 is this possible to do that without installing DSM from scratch? Can I just re-build the loader and change the serial number and Mac address? Or do I have to format and install everything and set everything up from scratch?

2. Is it possible to disconnect the disk-on-key after the DSM is booted?

3. Is it reliable? - Yes I know no one here can guarantee me that it will work 100 % and I will not lose data. But I'm sure there are many here who have been running this way for months and using DSM this way every day, so is it reliable enough to use it?

You cannot change the serial number for a platform change. Each platform uses different kernel, different mini root and different kernel modules that are specifically compiled for that platform. 
 

You have to rebuild your loader for a different platform from scratch. That should be no problem.  

 

Now for the data, applications and settings. Syno is very good at that. They always have in mind that you might want eventually and as your demands grow, transfer your disks to a newer or just faster platform. They will accept the disks but you will need to reinstall. The application, application data and volume data will remain intact. 
 

 

[ideasman69]

22 minutes ago, pocopico said:

see, but why you have sata for boot ? In proxmox that the TTH was initially targeting has the USB boot ability. You can set your VM to boot from a USB loader and then you could probably remove the sata HBA 

you can't get rid of them though. If i switch to the USB loader, it gets rid of one of them - but the first one always remains. @phone guy is using the virtual USB loader and his disks start at disk 2. because I'm using the loader via a SATA port, my disks start at disk 3.

 

i prefer this method as the bootloader image gets backed up along with the VM.

[pocopico]

1 minute ago, ideasman69 said:

you can't get rid of them though. If i switch to the USB loader, it gets rid of one of them - but the first one always remains. @phone guy is using the virtual USB loader and his disks start at disk 2. because I'm using the loader via a SATA port, my disks start at disk 3.

 

i prefer this method as the bootloader image gets backed up along with the VM.

You always have the DiskIdxMap and sata_remap option.  Both should work. 

 

 

[ideasman69]

...but it doesn't with the SAS controller. 

 

i've got an identical setup in my homelab. proxmox VM but instead of passing through an 8 port HBA, i'm passing through 2 x standard AHCI controllers. The satamap options do work on that. 

[flyride]

22 hours ago, phone guy said:

@flyride If you want any other information, I will be happy to provide or test at your discretion.

Thank you again for taking the time to try and help! I really appreciate it!

 

[flyride]

59 minutes ago, ideasman69 said:

...but it doesn't with the SAS controller. 

 

i've got an identical setup in my homelab. proxmox VM but instead of passing through an 8 port HBA, i'm passing through 2 x standard AHCI controllers. The satamap options do work on that. 

 

I was away from the forum today while testing but check my post above - your results are identical to mine.  Hopefully the writeup helps you a bit, and the rploader will improve to help provide functional configurations for these types of installs shortly.

Edited May 19, 2022 by flyride

[flyride]

10 hours ago, pocopico said:

SasIdxMap, maybe is for models that supported SAS. I think these lower end models do not have SAS controllers at all.

 

I don't think SasIdxMap is implemented on any of our platforms on any current DSM version.  I do realize there is a very old Jun reference where it was purported to work, but I've never seen it used since.  And, the definitive technical reference here does not refer to it at all. 

[pocopico]

6 hours ago, flyride said:

 

I don't think SasIdxMap is implemented on any of our platforms on any current DSM version.  I do realize there is a very old Jun reference where it was purported to work, but I've never seen it used since.  And, the definitive technical reference here does not refer to it at all. 

 

The following map and remap options have been found using strings in the uncompressed DS3622xs+ kernel.

 

SataPortMap=

DiskIdxMap=

sata_remap=

ahci_remap=

 

The SasIdxMap string, is not present in the DS3622xs+ kernel.

 

 

The reference is definetely outdate since we already know that the line in bold is not true anymore and SataPortMap can have values greater than 9.

 

config SYNO_SATA_PORT_MAP

bool "Modify SATA Hosts Port Number"

depends on SYNO_FIXED_DISK_NAME

default y

help

<DSM> #18789

Reads Sata-Port-Mapping information and forces the sata hosts

to initialize specified number of ports. This makes the disk

name not skip some characters.

 

Notice - Do NOT set the port number out of the range that [0-9].

It supports as most 9 ports now.

 

For example, SataPortMap=4233 means the 1st host use 4 ports,

the 2nd host use 2 ports, the 3rd and 4th host use 3 ports.

Edited May 20, 2022 by pocopico

[leang521]

On 5/16/2022 at 6:33 AM, ideasman69 said:

thanks mate. I used his guide which produced a VM identical to mine... it ended up being my satamap. I had it 0 for the VM's sata controller that had no drives attached. once I set it to 6, it booted 😕

 

i spent hours on that!

 

Hi! I encountered the same problem. But I didn't find the guide. Can you give me the link? Or talk about the solution.

[Itay1778]

13 hours ago, pocopico said:

They will accept the disks but you will need to reinstall. The application, application data and volume data will remain intact. 

Thanks for the answer, so when I rebuild the loader it will ask me for the pat file of the model I switched to and will not format the disks?

[shrabok]

Hi, thought about joining in on the fun, although I'm confused on the 7.X hardware matrix and upgrade workflow.
 

I have 2 xpenology systems, both older cpu generations (Ivy and Skylake) running on 6.2.2 and 6.2.3. My questions are:

1. It sounds like to allow for a smooth upgrade to 7.X you would use the 3617xs model, can 3622xs be used in place of 3617xs without data loss? What would be the process to avoid staying on a deprecated model?
2. Can an upgrade from 6.2.2 be performed directly to 7.1? Do we need to jump 6.2.2 -> 6.2.3 -> 7.0 -> 7.1?
3. Network drivers, in the past I've used extra drivers for r8168 and e1000e nic's, it sounds like tinycore manages all of the extra drivers, but was looking for confirmation that it's nothing that requires additonal steps outside of the standard workflow?

Edited May 20, 2022 by shrabok

[flyride]

1 hour ago, shrabok said:

Hi, thought about joining in on the fun, although I'm confused on the 7.X hardware matrix and upgrade workflow.
 

I have 2 xpenology systems, both older cpu generations (Ivy and Skylake) running on 6.2.2 and 6.2.3. My questions are:

1. It sounds like to allow for a smooth upgrade to 7.X you would use the 3617xs model, can 3622xs be used in place of 3617xs without data loss? What would be the process to avoid staying on a deprecated model?
2. Can an upgrade from 6.2.2 be performed directly to 7.1? Do we need to jump 6.2.2 -> 6.2.3 -> 7.0 -> 7.1?
3. Network drivers, in the past I've used extra drivers for r8168 and e1000e nic's, it sounds like tinycore manages all of the extra drivers, but was looking for confirmation that it's nothing that requires additonal steps outside of the standard workflow?

Ivy Lake is "older" - it can run anything not marked Haswell

Skylake is not. From an architecture perspective - it can run anything.

 

You didn't mention what platform you are running now.  But you may choose DS3617xs or DS3622xs+ interchangeably at this point.  Regardless, you will be asked for a Migration Install and data and DSM configurations should be preserved.  Always have a backup of your data.

 

Any 6.x can upgrade directly to 7.0.1 or 7.1 with no issues.

 

r8168 and e1000e are usually part of the core DSM support drivers. There is a library of drivers in TCRP; selections can be manually added or you can ask the build process to try and identify your hardware "./rploader.sh build <arch-version-release> auto" and add them as needed.

 

Edited May 20, 2022 by flyride

[vbz14216]

Just successfully migrated from 7.0.1 DS3615xs(bromolow) to 7.1.0 DS3622xs+(broadwellnk) on my baremetal D510 setup, pretty much a drop-in upgrade without any hitches.

Intel Atom D510(i915 driver+e1000 driver, ICH10R with no HBA installed), 2HDDs and 2GB of RAM

 

Seems legacy/non-UEFI systems shouldn't have to worry about compatibility when migrating even if they're on ancient system. Still, I used a spare USB drive and hard disk for testing so no data loss risks are involved.