TinyCore RedPill Loader (TCRP)

[IG-88]

51 minutes ago, Hackaro said:

Even if i3-8100 is not a kbl (kaByLake) but Coffee Lake?

yes, but you dant have to take my word for it, you can chréck intels repository

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

 

54 minutes ago, Hackaro said:

so the file kbl_dmc_ver1_04.bin is missing, as you said. So I just add that file and I'm done, correct? 

yes, just copy the file and reboot

[IG-88]

13 hours ago, Penguin Power said:

It sounds like tg3 driver is not getting loaded due to variation in chip!!

maybe not, imho tg3 silicon is way to old for that, check if the tigon firmware is present

as far as i have seen the rp loaders and extensions seem not to care about firmware files needed by drivers

for tg3.ko there should be /lib/firmware/tigon/

tg3.bin

tg3_tso.bin

tg3_tso5.bin

you can download them by kernel.org

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/tigon

or extract them from jun's or my extra.lzma of loader for 6.2

usually it can be checked with "modinfo" if there are any dependencies on firmware, but synology does not provide modinfo in dsm so you would need a chroot or any linux with modinfo and point to dsm's drivers files to get the info (but thats usually something the provider of the driver needs to do)

these infos are only ascii in the *.ko file, if you use a hex editor anything that will show the raw file you can look for "vermagic" and in the area before that you will see things like pci id's and also "firmware=" and these are the firmware dependencies of the kernel driver (there is also "depends=" naming the dependencies of other kernel modules or "version=" that will tell you about the version of the driver)

Edited March 26, 2022 by IG-88

[RacerX]

pocopico

 

Your were right about running the usb script with the Proxmox VM.  In another test today I ran the script

 

I successfully built apollolake-7.0.1-42218  DS918+ on my z370 i5 8600K on Proxmox 7.01-2

 

Could you clarify do extensions need to be run before or after a build? It seemed to logical to do it afterward but I'm no expert....

 

Thanks for the help

 

Edited March 26, 2022 by RacerX

[giacomoleopardo]

Hi everybody.

Specs:

• ASRock Fatal1ty Z170 Gaming-ITX/ac (6 Intel SATA ports on board)
• CPU: Intel® Core™ i3-7100 Processor
• IGPU: Intel® HD Graphics 630
• 4x 8TB HDDs Western Digital Red SHR (btrfs) (ports 0, 1, 2, 3)
• 2x 1TB Raid 1 Sata SSDs Cache (ports 4, 5)
• DSM 7.0.1 (42218) via TinyCore - USB bare metal

When Sata port 4 and/or 5 are connected it keeps giving this error in loop every 50-70 min, over and over again

 

[ 1037.717847]  [<ffffffff81436ee3>] ata_scsi_port_error_handler+0x133/0x1a30
[ 1037.718598]  [<ffffffff81432868>] ? ata_scsi_cmd_error_handler+0x118/0x190
[ 1037.718985]  [<ffffffff8143887b>] ata_scsi_error+0x9b/0xe0
[ 1037.719297]  [<ffffffff813f86f5>] scsi_error_handler+0xa5/0x530

 

jeopardizing the sleep/hibernation functions.

Leaving Sata ports 4 and 5 empty, doesn't give the problem, and the NAS goes to sleep as it should.

Any ideas?

[paro12]

Still battling to get any version running baremetal on my machine. (GA-78LMT-USB3 with FX8350 similar to xlynoz)

 

Have been trying to telnet in to try and debug, but it always tells me "Network error: connection refused"

 

I tried adding pocopico's extension https://github.com/pocopico/rp-ext/blob/main/early-telnet/rpext-index.json

I tried  http://IPADDRESS:5000/webman/start_telnet.cgi which returns {"success": true} but I'm still not able to telnet in.

 

I've tried starting the DSM install and connecting after it loads to 8% but i still refuses the connection.

 

Any ideas on what I'm doing wrong?

 

 

Edited March 26, 2022 by paro12
Link

[Jizar Stoffel]

1 hour ago, paro12 said:

Still battling to get any version running baremetal on my machine. (GA-78LMT-USB3 with FX8350 similar to xlynoz)

 

Have been trying to telnet in to try and debug, but it always tells me "Network error: connection refused"

 

I tried adding pocopico's extension https://github.com/pocopico/rp-ext/blob/main/early-telnet/rpext-index.json

I tried  http://IPADDRESS:5000/webman/start_telnet.cgi which returns {"success": true} but I'm still not able to telnet in.

 

I've tried starting the DSM install and connecting after it loads to 8% but i still refuses the connection.

 

Any ideas on what I'm doing wrong?

 

 

I had that issue, I fixed it by reburning the iso to a different usb stick, removing one HHD from my machine, wiping all data out, putting it back on the machine, and running setup with Sataportmap:1 Diskidxmap:00. that got me thru the installation problems. 

but once installed.... Im still having problem to permanently change the satapormap to 64 and diskidxmap to 0004. to reflect my drives setup. it works fine if I do it thru pressing 'e' at loader menu and changing manually, but it resets every time there is a system reboot.

 

[Jizar Stoffel]

Trying to solve my issue... I ran into this when trying to rebuild my setup. anyone have any thoughts that might help me?

Quote

 

It looks that you will need the following modules :

Found VGA Controller : pciid 8086d00000412  Required Extension : i915
Searching for matching extension for i915
Found SATA Controller : pciid 8086d00008c02  Required Extension : ahci
Searching for matching extension for ahci
Found SATA Controller : pciid 1b4bd00009215  Required Extension :
No matching extension
[#] Checking runtime for required tools... [OK]
[#] Adding new extension from https://raw.githubusercontent.com/pocopico/rp-ext/master/r8169/rpext-index.json...
[#] Downloading remote file https://raw.githubusercontent.com/pocopico/rp-ext/master/r8169/rpext-index.json to /home/tc/redpill-load/custom/extensions/_new_ext_index.tmp_json
######################################################################## 100.0%

[!] Extension is already added (index exists at /home/tc/redpill-load/custom/extensions/pocopico.r8169/pocopico.r8169.json). For more info use "ext-manager.sh info pocopico.r8169"

*** Process will exit ***
Found Ethernet Interface : pciid 10ecd00008136 Required Extension : r8169
Searching for matching extension for r8169
Found matching extension :
"https://raw.githubusercontent.com/pocopico/rp-ext/master/r8169/rpext-index.json"
Found Ethernet Interface : pciid 10ecd00008125 Required Extension :
No matching extension
------------------------------------------------------------------------------------------------
Starting loader creation
Checking user_config.json : Done
[#] Checking runtime for required tools... [OK]
[#] Updating extensions...

[#] Checking runtime for required tools... [OK]
[#] Adding new extension from https://raw.githubusercontent.com/dogodefi/redpill-ext/master/redpill-boot-wait/rpext-index.json...
[#] Downloading remote file https://raw.githubusercontent.com/dogodefi/redpill-ext/master/redpill-boot-wait/rpext-index.json to /home/tc/redpill-load/custom/extensions/_new_ext_index.tmp_json
##################################################################################################################################################### 100.0%

[!] Extension is already added (index exists at /home/tc/redpill-load/custom/extensions/thethorgroup.jg.boot-wait/thethorgroup.jg.boot-wait.json). For more info use "ext-manager.sh info thethorgroup.jg.boot-wait"

*** Process will exit ***
[!] Failed to install jg.bootwait bundled extension - see errors above

*** Process will exit ***
FAILED : Loader creation failed check the output for any errors
 

 

 

[Dvalin21]

8 hours ago, Jizar Stoffel said:

Trying to solve my issue... I ran into this when trying to rebuild my setup. anyone have any thoughts that might help me?

 

I keep running into that after I try to build. You have to delete it every time. sudo ./rploader.sh rm -R home/tc/redpill-load/custom/extensions/thethorgroup.jg.boot-wait/thethorgroup.jg.boot-wait.json

[Jizar Stoffel]

1 minute ago, Dvalin21 said:

I keep running into that after I try to build. You have to delete it every time. sudo ./rploader.sh rm -R home/tc/redpill-load/custom/extensions/thethorgroup.jg.boot-wait/thethorgroup.jg.boot-wait.json

right at this moment.. im creating new boot usb stick and starting from scratch... Ill let you guys know if it works

 

[Jizar Stoffel]

So... here is what I did....

1. Burned a new TinyCore USB Stick on a brand new Usb Stick. (saved my previous on just in case)

2. Ran the following codes:

• sudo ./rploader.sh update now
• sudo ./rploader.sh serialgen DS3622xs+ now  (I used the same Serial I had before)
• sudo ./rploader.sh satamap now (result was 64/0004)
• sudo ./rploader.sh identifyusb now
• sudo ./rploader.sh ext broadwellnk-7.0.1-42218 auto 
• added mac2 and mac3 to user_config.json (just so see if my NICs would pop up)
• sudo ./rploader.sh build broadwellnk-7.0.1-42218
• sudo ./rploader.sh backup now (and downloaded the .pat from the cache folder)
• sudo reboot  

I let it boot normally to see if it would give me the infamous drive error. Oddly enough... it didn't , it went straight thru to the login page, didn't even asked to installation or restoration. 

So it seems that by using the same serial number from previous installation did the trick.

If I would have gotten the drive error, I would've rebooted and pressed 'e' on loader menu and edit "SataPortMap" to 1 and "DiskIdxMap" to 00, just to reinstall the .pat

So far, everything is working normally as before.

Now I just need to figure it out how to get my NICs to work. And maybe mess arround with code to move the drives around to fill drives 3,4 instead of 9,10.

 

 

PS... Synology Drive Server is not installing, keeps asking for a repair.

 

[Dvalin21]

@IG-88 @pocopico  Hey guys, quick question and I apologize if its already been answered. What configurations will cause for the system to say a hard drive does not reach the requirements to be used in the system? Ive also notice that if I want to start a fresh install (meaning wiping all the drives) some of them have been set to MBR vs GPT I originally formatted them in. Is this normal or is this an issue? I just rebuilt ds3622, since im already having to reinstall everything im taking the time out to see what would be the best configuration. I used 0F00 instead of 0A00 for diskid and now (although it detects all 4 hdd) it says none of them are in requirements and they show up as null. Every hdd is a good drive without any errors (all tested).  Any help with this would be appreciated. Thanks.

Edited March 27, 2022 by Dvalin21

[We87]

I just installed tinycore redpill on a baremetal nas box, with two lan ports (realtek), and only one is showing up after dsm7.0.1 install. They showed up before in Jun's 1.0.4b dsm 6.2.3 they were both on and working. But now after editing user_config.json file with both mac1 and mac2 (different addresses) only mac1 shows up in dsm. Everything else from user_config.json worked including the serial. Just only have the one nic, cant find the other. Any advice?

[Peter Suh]

23 minutes ago, We87 said:

I just installed tinycore redpill on a baremetal nas box, with two lan ports (realtek), and only one is showing up after dsm7.0.1 install. They showed up before in Jun's 1.0.4b dsm 6.2.3 they were both on and working. But now after editing user_config.json file with both mac1 and mac2 (different addresses) only mac1 shows up in dsm. Everything else from user_config.json worked including the serial. Just only have the one nic, cant find the other. Any advice?

 

 

Have you double-checked the grub.cfg file?
It should actually have both mac1 and mac2 settings and netif_num=2.

[We87]

I couldnt find the grub.cfg file using redpill. I followed the redpill directions, I found on here, and the only thing that was editable was the user_config.json

 

I verified user_config.json was correct (as posted/edited) before issuing build command for usb.

 

{
  "extra_cmdline": {
    "pid": "0x2401",
    "vid": "0x3711",
    "sn": "12345ABCDE123",
    "mac1": "123ABC123482",
    "mac2": "123ABC123483",
    "SataPortMap": "2",
    "DiskIdxMap": "00"
  },
  "synoinfo": {

          "internalportcfg" : "0xffff",
          "maxdisks" : "16",
	      "support_bde_internal_10g" : "no",
	      "support_disk_compatibility" : "no",
          "support_memory_compatibility" : "no"


},
  "ramdisk_copy": {

    
}

}

 

When I used Jun's 1.04b loader, and dsm6.2.3, I was able to edit the grub.cfg on the usb (Jun 1.04b) before installing dsm6.2.3 which had basically the same information as the user_config.json file. I could not find the grub.cfg on redpill in dsm7.0.1. If its there I need help to find it. I never saw netif_num=2 anywhere in redpill.

 

Where is grub.cfg on redpill?

Edited March 27, 2022 by We87

[IG-88]

18 minutes ago, We87 said:

I couldnt find the grub.cfg file using redpill.

similar as with 6.2 loader, 1st partition of the loader, /boot/grub/grub.cfg

check the netif_num there, if its 1 and you have defined two when building the loader something is wrong defined there as the grub.cfg is made from that process

 

linux /zImage withefi earlyprintk syno_hw_version=DS3617xs console=ttyS0,115200n8 netif_num=1

Edited March 27, 2022 by IG-88

[IG-88]

10 hours ago, Jizar Stoffel said:

Now I just need to figure it out how to get my NICs to work.

about that asix usb nic (ax88179), there is a extension for that

https://github.com/pocopico/rp-ext/tree/main/ax88179_178a

check if the driver is present and loaded (ax88179_178a.ko) and what /var/log/dmesg has about that driver/hardware

maybe the extension is just not added to the loader? if its present then there should be some error when loading the driver

 

[phone guy]

39 minutes ago, IG-88 said:

similar as with 6.2 loader, 1st partition of the loader, /boot/grub/grub.cfg

check the netif_num there, if its 1 and you have defined two when building the loader something is wrong defined there as the grub.cfg is made from that process

 

linux /zImage withefi earlyprintk syno_hw_version=DS3617xs console=ttyS0,115200n8 netif_num=1

 

Is it possible to edit the grub.cfg on a system already up and running, or need to rebuild/redo the usb stick?

[IG-88]

14 minutes ago, phone guy said:

Is it possible to edit the grub.cfg on a system already up and running, or need to rebuild/redo the usb stick?

its ok for testing but as tinycore recreates the file if its re-running you will loose changes made that way

thats the reason i wrote "check ..." if you use a tool to build the loader or its files you will need to check how to do that properly in that tool (tinycore is just one method, to have it all-in-one but you can also build the loader as it comes from different git's as script)

you could make your own documentation about how to create the loader and add that manual step of changing files but thats not the way its intended to work, either use the commands of tinycore to detect it properly and if thats not present/working the code should be changed to make it work properly

 

[phone guy]

2 minutes ago, IG-88 said:

its ok for testing but as tinycore recreates the file if its re-running you will loose changes made that way

thats the reason i wrote "check ..." if you use a tool to build the loader or its files you will need to check how to do that properly in that tool (tinycore is just one method, to have it all-in-one but you can also build the loader as it comes from different git's as script)

you could make your own documentation about how to create the loader and add that manual step of changing files but thats not the way its intended to work, either use the commands of tinycore to detect it properly and if thats not present/working the code should be changed to make it work properly

 

Any chance someone has outlined this procedure? to check/edit the existing grub.cfg?

 

And on the same subject, I feel the tinycore builder I used (obviously) got something wtong or is missing a section based on nic not properly registering... since there are many scripts and git's, would you suggest a better method or tutorial? Hopefully user friendly...Linux/unix is not familiar to me, so the entire process, structure and commands are very unfamiliar and somewhat foreign, but I really am trying.

[Jizar Stoffel]

3 hours ago, IG-88 said:

about that asix usb nic (ax88179), there is a extension for that

https://github.com/pocopico/rp-ext/tree/main/ax88179_178a

check if the driver is present and loaded (ax88179_178a.ko) and what /var/log/dmesg has about that driver/hardware

maybe the extension is just not added to the loader? if its present then there should be some error when loading the driver

 

huh!!! I dont have that file on my system.

 

I think that ext is installed, the NIC I really wanted to use was my PCI card. NICGIGA NIC-2.5G

I posted a request for the ext on the github, but it seems it is already supported, I just dont know how to add it.

https://github.com/pocopico/tinycore-redpill/issues/48

 

this is the NIC output:

01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5G bE Controller [10ec:8125] (rev 05)

[IG-88]

4 hours ago, phone guy said:

Any chance someone has outlined this procedure? to check/edit the existing grub.cfg?

its the same as for loader 6.x  outlined in the tutorials, only difference is that the parameter it now directly in then line with the kernel config parameters

most people used a windows with a unix aware editor like notepad++

 

4 hours ago, phone guy said:

there are many scripts and git's, would you suggest a better method or tutorial? Hopefully user friendly...Linux/unix is not familiar to me,

then maybe you should not use stuff that is (still) in the developer section of the forum? its not ready to universal use

 

 

2 hours ago, Jizar Stoffel said:

huh!!! I dont have that file on my system.

ok, that was in 6.2.3, now you have to  look into the file synobootup.log or type the command dmesg

 

2 hours ago, Jizar Stoffel said:

I think that ext is installed, the NIC I really wanted to use was my PCI card. NICGIGA NIC-2.5G

I posted a request for the ext on the github, but it seems it is already supported, I just dont know how to add it.

https://github.com/pocopico/tinycore-redpill/issues/48

 

this is the NIC output:

01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5G bE Controller [10ec:8125] (rev 05)

 

check the log about the drivers also r8125, if the extension is there then there should be a message in the log too

the driver use by pocopico is 9.006.04 from 7/2021, the latest is 9.008.00 from 3/2022, as there is no history log in the driver its hard to say if it supports more hardware, next best is the log from loading the driver

[Dvalin21]

Has anyone else experienced synology being installed directly to the hdd?  I noticed it the other when I went to build again, reboot, expecting to use find.synology.com to locate it, but was able to still use the ip address to get to the login screen like it nothing happened. I would have figured it would show up as a migrate or something in the reinstall. I ended up reflashing the usb and tried again and got the same result. It wasn't until I formatted the hdd when I was able to do a fresh install.  If you look at my previous post, you can see that it seems to install it to the my smallest hdd. 

[IG-88]

9 minutes ago, Dvalin21 said:

I ended up reflashing the usb and tried again and got the same result. It wasn't until I formatted the hdd when I was able to do a fresh install.  If you look at my previous post, you can see that it seems to install it to the my smallest hdd. 

dsm installs to all hdd's, in the system, thats how it works and as long as at least one disks is working you have a dsm system

the usb is just the bootloader with the kernel, if you want to "kill" a dsm system you need to remove the 1st partition of all disks or just wipe the partition table of all disks

as long as the loader still finds a system on disks it will try to update and keep settings, its supposed to be like that and needs to be seen from the perspective of a original syno system, if a hardware fails you can insert you disk in a replacement unit and will end up with a system exactly like it was before, the original unit has a usb DOM, same as our usb flash drives for xpenology, if the dom of the new system has a older kernel you can "repair" and the newer kernel from the disk will end on the usb dom and if the usb dom is newer you install the matching *.pat file (or newer) to the disks and updating the system and the result is supposed to behave the same as before, same ip, user, shares, packages (if possible)

everything in jun's and rp loader is still around that base system from synology, jun's loader had a option to "reset" to factory defaults and there is a option like that on original systems, meant to be used when you screw up the config in a way its not supposed to be

 

what makes up a dsm system, its the serial and mac in the (usb) loader and the config files of the dsm system partitons on disk, if you want to get rid of the system config you need to get rid of these config's and one way is to just remove the whole system partition on disk (i usually kill all partitions because dsm might behave different if it finds partitions an a disk that is supposed to be empty - that makes sense to prevent users using a "wrong" disk as replacement

 

[phone guy]

8 minutes ago, IG-88 said:

dsm installs to all hdd's, in the system, thats how it works and as long as at least one disks is working you have a dsm system

the usb is just the bootloader with the kernel, if you want to "kill" a dsm system you need to remove the 1st partition of all disks or just wipe the partition table of all disks

as long as the loader still finds a system on disks it will try to update and keep settings, its supposed to be like that and needs to be seen from the perspective of a original syno system, if a hardware fails you can insert you disk in a replacement unit and will end up with a system exactly like it was before, the original unit has a usb DOM, same as our usb flash drives for xpenology, if the dom of the new system has a older kernel you can "repair" and the newer kernel from the disk will end on the usb dom and if the usb dom is newer you install the matching *.pat file (or newer) to the disks and updating the system and the result is supposed to behave the same as before, same ip, user, shares, packages (if possible)

everything in jun's and rp loader is still around that base system from synology, jun's loader had a option to "reset" to factory defaults and there is a option like that on original systems, meant to be used when you screw up the config in a way its not supposed to be

 

what makes up a dsm system, its the serial and mac in the (usb) loader and the config files of the dsm system partitons on disk, if you want to get rid of the system config you need to get rid of these config's and one way is to just remove the whole system partition on disk (i usually kill all partitions because dsm might behave different if it finds partitions an a disk that is supposed to be empty - that makes sense to prevent users using a "wrong" disk as replacement

 

Great explanation, thanks for that! Makes 100% sense explained.

[Dvalin21]

2 hours ago, IG-88 said:

dsm installs to all hdd's, in the system, thats how it works and as long as at least one disks is working you have a dsm system

the usb is just the bootloader with the kernel, if you want to "kill" a dsm system you need to remove the 1st partition of all disks or just wipe the partition table of all disks

as long as the loader still finds a system on disks it will try to update and keep settings, its supposed to be like that and needs to be seen from the perspective of a original syno system, if a hardware fails you can insert you disk in a replacement unit and will end up with a system exactly like it was before, the original unit has a usb DOM, same as our usb flash drives for xpenology, if the dom of the new system has a older kernel you can "repair" and the newer kernel from the disk will end on the usb dom and if the usb dom is newer you install the matching *.pat file (or newer) to the disks and updating the system and the result is supposed to behave the same as before, same ip, user, shares, packages (if possible)

everything in jun's and rp loader is still around that base system from synology, jun's loader had a option to "reset" to factory defaults and there is a option like that on original systems, meant to be used when you screw up the config in a way its not supposed to be

 

what makes up a dsm system, its the serial and mac in the (usb) loader and the config files of the dsm system partitons on disk, if you want to get rid of the system config you need to get rid of these config's and one way is to just remove the whole system partition on disk (i usually kill all partitions because dsm might behave different if it finds partitions an a disk that is supposed to be empty - that makes sense to prevent users using a "wrong" disk as replacement

 

I appreciate the knowledge