RedPill - the new loader for 6.2.4 - Discussion

[haydibe]

2 hours ago, T-REX-XP said:

1. modify entrypoint.sh as I mentioned before

2. run  ./redpill_tool_chain.sh build apollolake-7.0-41890  # due to copying entrypoint.sh inside container

3. run  ./redpill_tool_chain.sh auto apollolake-7.0-41890

4. See build logs then check logs inside VM during the boot. I have already checked it on my vm. So my custom modules are loaded during the boot.

 

Seems we are not getting on the same page here. I was not realy asking for any instructions or ways to modify the toochain builder.. 

 

The run action actualy IS the recommended approach at this time, I just wrote about the additional step required to actualy build the bootloader image when using the run action.

 

Update: there is a better alternative, see my next post

Edited October 1, 2021 by haydibe

[pocopico]

26 minutes ago, haydibe said:

Seems we are not getting on the same page here. I was not realy asking for any instructions or ways to modify the toochain builder.. 

 

The run action actualy IS the recommended approach at this time, I just wrote about the additional step required to actualy build the bootloader image when using the run action.

 

 

 

@haydibeThanks for being commited to the project.

 

IMHO, once you have the extensions loaded into "custom" directory and since these get attached to the docker images, you have nothing more to do into the docker.

 

You can just add the ext-manager.sh into the root folder of toolchain builder, to get the ext-manager process outside the containers and attach the custom folder <as you already do> to the containers. It can be part of the build process to fetch the latest ext-manager.sh from the loader repo.

 

*** well, I just remembered that there are includes inside the ext-manager that will be required for ext-manager to run
 

 

You can find some more extensions in my github repository : 

 

https://github.com/pocopico/rp-ext    e.g.  https://github.com/pocopico/rp-ext/raw/main/tg3/rpext-index.json

 

 

Edited October 1, 2021 by pocopico

[urundai]

1 hour ago, urundai said:

Thank you @vbap. Very much appreciated.

 

I tried that and it's not found with find.synology.com. But, I do see that the IP address has been assigned. Interestingly, find.synology.com is not finding my other synology box either. So, need to do some local troubleshooting as to what's going on. Maybe pihole is black holing it. I will some more digging and will post an update.

 

Thank you for the help,

I was able to find the instance using Synology Assistant app on my machine. Thank you @vbap once again. I was really recompiling like crazy, not finding anything the log file. 

[haydibe]

Not sure why I didn't think about it earlier, but in fact you can checkout redpill-load on the host, configure "docker.local_rp_load_use": "true" and "docker.local_rp_load_path": "/path/where/your/local/redpill-load/copy/is" in  global_config.json. And then use the ext-manager inside your local redpill-load copy before you perform your next auto build.

 

This way there is no need to integrate the ext-manager inside the redpill-tool-chain, as it can be directly used inside the local redpill-load folder. 

 

Update: I just checked out of curiousity. This feature was available since v0.6

Edited October 1, 2021 by haydibe

[plarkass]

Le 27/09/2021 à 10:28, imdgg a dit :

 

make sure you chose the SATA boot entry,and add the parameters.

 

Att the end of the installation 
 

1) Enable SSH and ssh into your DiskStation

2) Become root ( sudo -i )

3) Make a mount point ( mkdir -p /tmp/mountMe )

4) cd into /dev ( cd /dev )

5) mount synoboot1 to your mount point ( mount -t vfat synoboot1 /tmp/mountMe )

6) modify grub

7) Profit!

[urundai]

2 hours ago, pocopico said:

 

@haydibeThanks for being commited to the project.

 

IMHO, once you have the extensions loaded into "custom" directory and since these get attached to the docker images, you have nothing more to do into the docker.

 

You can just add the ext-manager.sh into the root folder of toolchain builder, to get the ext-manager process outside the containers and attach the custom folder <as you already do> to the containers. It can be part of the build process to fetch the latest ext-manager.sh from the loader repo.

 

*** well, I just remembered that there are includes inside the ext-manager that will be required for ext-manager to run
 

 

You can find some more extensions in my github repository : 

 

https://github.com/pocopico/rp-ext    e.g.  https://github.com/pocopico/rp-ext/raw/main/tg3/rpext-index.json

 

 

checked the mpt2sas and mpt3sas. In the json, looks like the version numbers are incorrect for DS3615xs (14222 points 25556 like "ds3615xs_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt2sas/releases/ds3615xs_41222.json"). Is this intentional or a typo?

[pocopico]

4 minutes ago, urundai said:

checked the mpt2sas and mpt3sas. In the json, looks like the version numbers are incorrect for DS3615xs (14222 points 25556 like "ds3615xs_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt2sas/releases/ds3615xs_41222.json"). Is this intentional or a typo?

A typo, thanks, I’ll look at this tomorrow 

[Schyzo]

Hi,

Thx for your work, but it seem impossible to work for me.

I tried to compile 7.0, 7.0.1, 6.2.4, and visibly the .img file is well created (with DS3615xs).

Once copied with Rufus, my Hp Gen 8 don't boot while Jun's loader works fine on 6.2.3

Someone had to works Redpill wit HP Gen 8 ?

 

Don't know what I'm doing bad...

Have a nice day, thanks !

Edited October 2, 2021 by Schyzo

[coint_cho]

13 hours ago, paro44 said:

 

I had a similar issue some weeks ago with only 1 of4 disks recognised. My baremetal is old, too (Intel SS4200, core2duo, ICH7R, mbr, no uefi). I started from scratch with tool-chain 0.11 and DS3615xs. Before starting I cleaned old tool-chain and cache, then put pid, vid, s/n and mac and it worked (it is PID first, then VID, i mixed that up on first try I think or the order was changed).

What hardware do you have (chipset southbridge)?

I just have an ASUS P5G41T-M LX

[WiteWulf]

35 minutes ago, Schyzo said:

I tried to compile 7.0, 7.0.1, 6.2.4, and visibly the .img file is well created (with DS3615xs).

Once copied with Rufus, my Hp Gen 8 don't boot while Jun's loader works fine on 6.2.3

Someone had to works Redpill wit HP Gen 8 ?

This has been covered a few times in this thread. You need to mark the first partition as "active" using something like fdisk. The Gen8 BIOS is a bit weird and needs this to be able to boot from USB sticks.

[RedwinX]

Hi ! 
 

Have a little question, I’m a little bit confused with the SataPortMap option. Currently, have a img/vmdk as redpill loader to sata 0:0 (esxi). Passthrough the lsi card. Have installed the mpt2sas extension, and my syno see only 6 disk of 8 (on the LSI). Try different number of sataportmap, only the 1 value see 7 disk of 8. What’s I messed up ? With diskidxmap, other results but not working…

 

ty in advance for your help.

 

red

[akh1]

23 minutes ago, RedwinX said:

Hi ! 
 

Have a little question, I’m a little bit confused with the SataPortMap option. Currently, have a img/vmdk as redpill loader to sata 0:0 (esxi). Passthrough the lsi card. Have installed the mpt2sas extension, and my syno see only 6 disk of 8 (on the LSI). Try different number of sataportmap, only the 1 value see 7 disk of 8. What’s I messed up ? With diskidxmap, other results but not working…

 

ty in advance for your help.

 

red

did you read ?

 

[AnhLai]

Hi any one got issue that not all ram are usable? I have 8GB installed, but only 4GB usable

[RedwinX]

19 minutes ago, akh1 said:

did you read ?

 

Yeah sure, if I read and understand, have to make diskidxmap=0C00 (13th disk is redpill vmdk, and 1th for sas card) and SATAPORTMAP=18 (1 port for redpill and 8 for sas) but always only 7 disk of 8 on sas card 

[pigr8]

So i made some trials, this is what i got. (7.0.1-42218 on ds3615xs - ESXi VM on HP Gen8 - using @pocopico extension - forked both pocopicos repo and redpill repo to work with 7.0.1).

 

Since i have an LSI hba card i had to load the card using mpt2sas.ko, and we have 2 ways of doing that: one is to leave the stock .ko (v20.0) and enable the load of that driver enabling "supportsas= yes" in synoinfo.conf (using the user config file) or loading manually the .ko using insmod.

Both of the ways, with the stock v20.0 driver, wont work.

Using supportsas enables the hba card on boot (i mean first boot, before even installing DSM), but the driver loads the disks attached to the card as /dev/sas* and DSM wont use them to install itself.

Not using supportsas on boot the card (and so the disks) are not present, DSM says no disks attached, if you try to use insmod /lib/modules/mpt2sas.ko the cards loads and disks show up but always as /dev/sas*, so DSM refuses to use them.

 

A way to fix /dev/sas* in /dev/sd* is to use @pocopicocompiled mpt2sas.ko that is v14.1, it can be overwritten on the stock v20.0 one in /lib/modules, but then: method 1 enabling supportsas loads the card and the disks as /dev/sd* but DSM wont use them, dunno why.. method 2 by insmod loads card and disks and DSM will install fine but it wont survive reboot since no insmod is redone after install.

 

The latest redpill offers to use extensions that are placed in custom.gz (i guess) and loaded on boot.. so i did that with @pocopico repo, using v7.0-41222 as a base; the extension/image works great so we have now the v14.1 driver on the system.. using supportsas gives again the original problem and DSM wont use the disks even if they are /dev/sd*, but ditching supportsas DSM will install fine and the perk is that the new driver will survive the reboot fine.

 

The next step is to upgrade to 7.0.1-42218.. but redpill loader still doesnt have that version on github, so i badly forked @jumkey repo and added 42218 to redpill, editing the needed files to make @haydibe tool work.. redpill has modded some files to integrate the extension manager that @jumkey repo doesnt have, by combining that all together the new image can be generated.

 

Rebooting from 7.0 to 7.0.1 sees the old installation, asks for upgrade (mantainin the files and config) with the new pat and on reboot everything comes back online.

 

 

 

 

So, problem about disks name: every combo i tried with DiskIdxMap and SataPortMap could not make it work having the hdd on /dev/sda, the best i can do is /dev/sdb - so slot 2.. redpill is on sata 0:0, no other controller is on the VM only the LSI in passthrough, if i set SataPortMap = 4 the disk shows up as /dev/sde, if i set SataPortMap = 1 it shows as /dev/sdb.. is like redpill binds itself to /dev/sda and the LSI stays after that no matter what 😕 

[RedwinX]

12 minutes ago, pigr8 said:

So i made some trials, this is what i got. (7.0.1-42218 on ds3615xs - ESXi VM on HP Gen8 - using @pocopico extension - forked both pocopicos repo and redpill repo to work with 7.0.1).

 

Since i have an LSI hba card i had to load the card using mpt2sas.ko, and we have 2 ways of doing that: one is to leave the stock .ko (v20.0) and enable the load of that driver enabling "supportsas= yes" in synoinfo.conf (using the user config file) or loading manually the .ko using insmod.

Both of the ways, with the stock v20.0 driver, wont work.

Using supportsas enables the hba card on boot (i mean first boot, before even installing DSM), but the driver loads the disks attached to the card as /dev/sas* and DSM wont use them to install itself.

Not using supportsas on boot the card (and so the disks) are not present, DSM says no disks attached, if you try to use insmod /lib/modules/mpt2sas.ko the cards loads and disks show up but always as /dev/sas*, so DSM refuses to use them.

 

A way to fix /dev/sas* in /dev/sd* is to use @pocopicocompiled mpt2sas.ko that is v14.1, it can be overwritten on the stock v20.0 one in /lib/modules, but then: method 1 enabling supportsas loads the card and the disks as /dev/sd* but DSM wont use them, dunno why.. method 2 by insmod loads card and disks and DSM will install fine but it wont survive reboot since no insmod is redone after install.

 

The latest redpill offers to use extensions that are placed in custom.gz (i guess) and loaded on boot.. so i did that with @pocopico repo, using v7.0-41222 as a base; the extension/image works great so we have now the v14.1 driver on the system.. using supportsas gives again the original problem and DSM wont use the disks even if they are /dev/sd*, but ditching supportsas DSM will install fine and the perk is that the new driver will survive the reboot fine.

 

The next step is to upgrade to 7.0.1-42218.. but redpill loader still doesnt have that version on github, so i badly forked @jumkey repo and added 42218 to redpill, editing the needed files to make @haydibe tool work.. redpill has modded some files to integrate the extension manager that @jumkey repo doesnt have, by combining that all together the new image can be generated.

 

Rebooting from 7.0 to 7.0.1 sees the old installation, asks for upgrade (mantainin the files and config) with the new pat and on reboot everything comes back online.

 

 

 

 

So, problem about disks name: every combo i tried with DiskIdxMap and SataPortMap could not make it work having the hdd on /dev/sda, the best i can do is /dev/sdb - so slot 2.. redpill is on sata 0:0, no other controller is on the VM only the LSI in passthrough, if i set SataPortMap = 4 the disk shows up as /dev/sde, if i set SataPortMap = 1 it shows as /dev/sdb.. is like redpill binds itself to /dev/sda and the LSI stays after that no matter what 😕 

Lol, happy to read that, because have exactly the same issue !! Maybe try with rdm instead of lsi passthrough 

Edited October 2, 2021 by RedwinX

[pigr8]

7 minutes ago, RedwinX said:

Lol, happy to read that, because have exactly the same issue !! 

 

yeah and that seems to happen even if i remove the passthrough the LSI and add a Virtual disks on sata controller 1:0.. the virtual disk shows up as /dev/sdb.

to fix this i moved redpill on 1:0 and the virtual disk to 0:0, that way the virtual disk shows up on /dev/sda, but leaving the sata controller 1 in place and adding the LSI the drivers on the LSI show up with 4 letters name, like /dev/sdam :S sooo...

[altas]

What is better barmetal installation or an ESXi??

[pigr8]

OORRR..


 

 

one could move the redpill not on a sata controller but on a sas controller, let it boot from there and that gives the LSI the ability to set the drive as /dev/sda.

 

done.

 

but i dont know if it's supported by TTG doing this way 

 

 

 

EDIT: nope, doing so no /dev/synoboot is created so install will fail @55%, if the system is installed it will boot fine but no clean install.

Edited October 2, 2021 by pigr8

[RedwinX]

12 minutes ago, pigr8 said:

OORRR..


 

 

one could move the redpill not on a sata controller but on a sas controller, let it boot from there and that gives the LSI the ability to set the drive as /dev/sda.

 

done.

 

but i dont know if it's supported by TTG doing this way 

Cool ! Works also with rdm on SATA controller (1:x) with redpill 0:0

Works fine with DiskIdxMap=0C00 SataPortMap=18 (have 8 disk)

now have to find a solution with VMXNET3 driver and broken universal search lol

 

Edited October 2, 2021 by RedwinX

[Orphée]

@pigr8 If you look my earlier posts, I faced the same issue with HBA LSI card, can't set it to /dev/sda. It seems DiskIdxMap is ignored. Whereas same conf with virtual SATA1 controller works.

 

 

and 2 posts after.

Edited October 2, 2021 by Orphée

[pigr8]

12 minutes ago, Orphée said:

@pigr8 If you look my earlier posts, I faced the same issue with HBA LSI card, can't set it to /dev/sda. It seems DiskIdxMap is ignored. Whereas same conf with virtual SATA1 controller works.

 

 

and 2 posts after.

 

it has something to do with where the loader sits, synoboot is always the first choice it seems no matter what 😕

[Orphée]

@pigr8 By the way if you set SataPortMap=1 (to have /dev/sdb for LSI)

Install fresh DSM fails. no /dev/synoboot* available with fdisk -l. At least for me.

Edited October 2, 2021 by Orphée

[pigr8]

3 minutes ago, Orphée said:

@pigr8 By the way if you set SataPortMap=1 (to have /dev/sdb for LSI)

Install fresh DSM fails. no /dev/synoboot* available with fdisk -l. At least for me.

 

well i have DiskIdxMap 0C and SataPortMap 18 atm in the loader, the redpill satadom is on /dev/synoboot and the first disk in the LSI is /dev/sdb, install works on 7.0 and 7.0.1 fine, even upgrades between them. 

[Orphée]

1 minute ago, pigr8 said:

 

well i have DiskIdxMap 0C and SataPortMap 18 atm in the loader, the redpill satadom is on /dev/synoboot and the first disk in the LSI is /dev/sdb, install works on 7.0 and 7.0.1 fine, even upgrades between them. 

Ok I'll check, thanks