haydibe
-
Posts
705 -
Joined
-
Last visited
-
Days Won
35
Posts posted by haydibe
-
-
The output indicates that you have one sata controller with 5 ports (all 5 ports on /sys/devices/pci0000:00/0000:00:1f.2).
Try this values in extra_cmdline in your user_config.json:
"SasIdxMap": "0", "SataPortMap": "5", "DiskIdxMap": "00"-
1
-
-
if you provide the output of `lsscsi -Hv` from tinycore, we can assist.
I assume you use an usb stick to boot.
-
You might want to take a look at this thread:
I posted the required commands to download the rploader, create the vm, create a sata0 on lvm-thin, the user_config.json required for proxmox and commands on how to "bring your own configurations" to the rploader. You basicly need to build your own bootloader using a script that does almost everything for you.
Warning: rp-lkm is officialy in alpha state and it is not yet ment for production - even though some people already use it productive already. There is always a possibility of data loss.
-
For time beeing you need to bring your own custom_config.json where you use jumkey's develop branch for bromolow 7.0.1, instead of unknown-o's master repo and you should be fine.
-
@Err0r you didn't read the first page of this thread, did you?
-
The beauty of the tinycore image is that it actualy is supposed to be used on the target system, allowing to detect the required drivers right away - configure, test, repeat -> until things are sorted out. No need to "burn" an usb-stick on each attempt or to copy vmdk files or img files to hypervisiors.
-
17 hours ago, seanone said:
Could you recommend a 7.0.1 fork
rp-load now has 160 forks - it's impossible to track who is doing what or even recommend one of them.
I personly only went with TTG's official rp-load master branch and jumkey's development branch - and of course unknown-o's bromolow 7.0 when it first came out.
-
... whoever gets the idea to build a web ui: make sure the runtime it needs is available/works on tiny core and fits into the bootloader image.
-
Extension handling is not implemented so far, except listing detected devices.
You will have to do this manualy. Something like this should do the trick:
./rploader.sh download bromolow-7.0.1-42218 ./redpill-load/ext-manager.sh add https://raw.githubusercontent.com/pocopico/rp-ext/master/qla2xxx/rpext-index.json ./rploader.sh build bromolow-7.0.1-42218 staticIf I am not mistaken, @pocopico is researching on how to auto detect required drivers and add extensions for them automaticly. This might explain why the "ext" action is not simply wired to ext-manager, like it is in rp-helper.
-
1
-
-
Why bother with modding pve, when you could add IG-88's extra.lzma to your loader image and use the vmxnet3 nic instead?
As a bonus, you won't be limited with 1gbps speed with vm's on the same host (given they use vmxnet3 or virtio based nics) anymore.
Each of my three pve hosts has a 10gbps nic and get close to 10gbps from my Jun's 6.2.3 instance that uses vmxnet3, expect with the vm's on the same host, which tend to be around 25gbps.
-
41 minutes ago, Aigor said:
That's strange, i use config from tinycore images without any modification
It is not
I used apollolake 7.0.1., which points to jumkey's repo, while you used bromolow 7.0.1, which points to unknown-o's repo.
When I tried bromollow 7.0.1 as well, I had the same problem as you. Make sure to bring your own custom_config.json.
Assuming you have a health configuration for custom_config.json and user_config.json, you can copy over "good files" from a ssh host to tc:
1. in tc: open a terminal
2. in tc (in terminal): passwd # to change the password
3. in tc (in terminal): ifconfig # to see the ip of tc
4. ssh host: scp custom_config.json tc@ip-of-tc:~/custom_config.json
5. ssh host: scp user_config.json tc@ip-of-tc:~/user_config.json
6. ssh host: ssh tc@ip-of-tc
7. ssh-host (while connected to tc): sudo ./rploader.sh update now # wasn't working without sudo for me.
8. ssh-host (while connected to tc): ./rploader.sh build bromolow-7.0.1-42218 static
9. ssh-host (while connected to tc): ./rploader.sh clean now # required, otherwise the next command will fail
10. ssh-host (while connected to tc): filetool.sh -b sdb3 # persist tc configuration back to tc partition. Your tc partition might be on a different disk.. change sdb to your device if needed.
11. ssh-host (while connected to tc): sudo reboot
-
2
-
-
The rp-load repo for bromollow 7.0.1 in custom_config.json causes the issue. From the past I know how impossible it is to keep track of all the different repositories. So I guess we will have to use our own configuration there.
I started to scp the user_config.json to tc already. Now I am going to do the same for the custom_config.json.
The issue itself is unrelated weather the rploader works or not. The same will happen with rp-helper, if the same custom_config.json is used to build an image.
-
@Aigor Is it safe to assume that you use your own configuration files? I have never seen that URL in any of my attempts...
If I run with the default packaged ones (+updating the script itself of course), none of my downloads points to those urls...
[#] Extension thethorgroup.boot-wait index is already up to date [#] Updating thethorgroup.virtio extension... [#] Downloading remote file https://github.com/jumkey/redpill-load/raw/develop/redpill-virtio/rpext-index.json to /home/tc/redpill-load/custom/extensions/_new_ext_index.tmp_json ############################################################################################################################################ 100.0%Are you sure it's not a problem of your configuration or the repo you are pointing to?
Update: the problem originates in https://github.com/unknown-o/redpill-load/blob/master/bundled-exts.json. as unknown-o's repository is used bromolow-7.0.1-42218
-
I had to prefix update with sudo in order to work`sudo ./rploader.sh update now` to update the script.
This time I used my own user_config.json (of course I replaced my real sn and mac1 with dummy values):
{ "extra_cmdline": { "vid": "0x46f4", "pid": "0x0001", "sn": "1510LWN123456", "mac1": "00123456789A", "SasIdxMap": "0", "SataPortMap": "66", "DiskIdxMap": "0600" }, "synoinfo": { "internalportcfg": "0xffff", "maxdisks": "16" }, "ramdisk_copy": {} }And directly run the build `./rploader.sh build apollolake-7.0.1-42218 static` and it worked like a charm.
Then I rebooted again with `sudo reboot`.
This time the installation went fine
After setting up the admin account, the "Storage Manager" popped up. The 100gb sata block device was recognized as drive 1 and I could create a volume.
The only annoyance is Synology's drive compatibility warning they build-in into DSM. It can be easily skipped.
For the first time setup on Promox, it works like a charm.
Though, follow up modifications are not possible yet, as ./rploader.sh disappeared again.
-
I made a test run and of course forgot to change the user_config.json 🤦♂️.
After rebooting tc with `sudo reboot`, grub showed the expected bootloader, Synology Assistent did find the new instance, but of course It immediatly threw an error.
Then I rebooted into tc, but ./rploader.sh is gone.
I did a shutdown with `sudo exitcheck.sh shutdown` this time.
Time to re-fetch the image and start over
Update: I added --keep to the gzip command, so that whenever the image needs to be replaced, it can be simply extracted again - just make sure the vm was shutdown before! Otherwise the extracted image wil be corrupt!
-
@pocopico forgive me that my first post is about how to make it run in Proxmox.
These commands are tested on PVE7.1 and can be used as is. If you want a different id, make sure to modify the value before pasting everyhing into the PVE root shell:
# set vm id id=930 # create image directory, download and uncomporess mkdir -p /var/lib/vz/images/${id} curl --location https://github.com/pocopico/tinycore-redpill/raw/main/tinycore-redpill.img.gz --output /var/lib/vz/images/${id}/tinycore-redpill.img.gz gzip --decompress /var/lib/vz/images/${id}/tinycore-redpill.img.gz --keep # create vm qm create ${id} \ --args "-drive 'if=none,id=synoboot,format=raw,file=/var/lib/vz/images/${id}/tinycore-redpill.img' -device 'qemu-xhci,addr=0x18' -device 'usb-storage,drive=synoboot,bootindex=5'" \ --cores 2 \ --cpu host \ --machine q35 \ --memory 2048 \ --name DSM \ --net0 virtio,bridge=vmbr0 \ --numa 0 \ --onboot 0 \ --ostype l26 \ --scsihw virtio-scsi-pci \ --sata0 local-lvm:vm-${id}-disk-0,discard=on,size=100G,ssd=1 \ --sockets 1 \ --serial0 socket \ --serial1 socket \ --tablet 1 # create disk for sata0 pvesm alloc local-lvm ${id} vm-${id}-disk-0 100GThe last comand allocates 100GB on the local thin-lvm partition. Once the commandes are done, just start the vm
Update: virtio network driver works in tc ootb (of course you need to use bridge that is connected to a network with dhcp to see an ip)
Update2: you definitly want to follow @pocopico's suggestion and open a terminal once TinyCore is started, change the password for the user tc with `passwd tc` and then do the rest of the action using a comfortable ssh connection
-
2
-
-
I realy love the idea that people are going to configure their loaders on the system they will be running later on!
It's time to take this baby to a spin drive
-
2
-
-
Works flawless on PVE 7..x with IG-88's extra.lmza and the vm's nic set to vmxnet3.
Note: even though DSM shows a 1000mbps connection, transfer speeds are actual close to the pyhisical's nic bandwith of 10gbps
-
9 hours ago, jukito said:
But... If I cannot put more than 9 on sataportmap, how can I set to my 10 disks?
My suggestion was to remove the A and test, as I doubt that it actualy has any effect. It's a pitty that the comments with documentation in the file `synoconfigs/Kconfig.devices` are removed in the current kernel sources - though older versions of the kconfig.devides came with documentation and pointed out what I wrote: SataPortMap is a single decimal digit from 1 to 9. The information could either still apply or be outdated.. Thus said: please test and report back!
The most important part is to trim down the first controller to a single port and "map it out of the way", like you did.
If memory serves right, the virtual sata controllers in ESXi have 32 ports by default and can't be changed.
Appart of that, all additional controllers and their ports will be still detected - with settings the first drive of the second controller to 00 you made sure they start as disk 1.
-
10 hours ago, jukito said:
Eureka!
DiskIdxMap=0C00 SataPortMap=1A SasIdxMap=1
This works at least!!!!!
I am surprised this works as SataPortMap is supposed to be a single decimal digit number from 1 to 9 (A can't be right for the 2nd controller), DiskIdxMap is a two digit hex value (which is used correct)..
i imagine the A was ignored all along and would work with SataPortMap=1 as well. The first controller is the one with the bootloader, which you set to a single slot and assigned the first drive on the controller to disk 13. Better to have a clean configuration that exactly reflects what it does than a "coincidental" configuration that just happens to work.
-
@Hammerfine you have to add a custom config for 7.0.1 yourself. rp-tool-chain/rp-helper support whatever is supported from the TTG rp-load repository.
-
15 minutes ago, asiawatcher said:
hey @haydibe not all people know how to compile the image!! we just want to use it why jun shared his loader then if there were legal problems?.
Yep, that totaly fixes the problem! Jun's loader was and still is not open source and a one shot contribution. The difference is that TTG open sourced the whol effort. This is a whole different situation. So, your argument is for that sake of some, we shouldn't care that it risks everything for everyone. I am not sure if I am able to understand that spirit.
This is not a finished and polished product. At this stage RP targets an audience that provides some skills.. so if someone lack that skills, then I frankly feel those people should wait until the final product (or at least a beta) is available.
-
2
-
-
Guys, are you serious?! It is unwanted that prebuild bootloader images are shared as they include proprietary code by Synology and are NOT opensource.
When I see how careless people treat the warning of TTG to not share prebuild bootloader images due to them containting proprietary Synology code, it kind of makes me regret that I ever have shared the rp-helper/rp-toolch-chain with the public.
I don't understand why it's imposible for some people to respect the wishes of the authors. Thus said, please stop publishing any prebuild images!
Maybe TTG not beeing around is already the consequence of people publishing prebuild images and attract attention causing legal claims..
-
7
-
-
10 hours ago, WiteWulf said:
To be clear: those screenshots I provided of a NIC with MTU set to 9000 were on a DS918+ with DSM 7.0-41890 VM, running on ESXi 7.0U2 with a VMXNET3 NIC connected to a vSwitch, set to 10GbE. The vSwitch also has its MTU set to 9000 and has two physical 1GbE NICs on the host attached using the igbn driver.
Thanks for the clearification! At least I know now it is not because of DS918+ or DSM7.0 in general 😭 😭 😭 😭 Ofc the pyhysical 10gpbs interface of the Proxmox host and the linux bridge (which does what the vSwitch does) were set to mtu9000 - it works without issues for everything else. Probably it's the virtio network driver then.
But I kind of lost interesst as I found no way to run my Swarm Cluster with mtu9000 - even though the container networks can be set to mtu 90000... the docker0 and docker_gwbridge interface used for the communication can not be change from mtu1500 to something else. As I am not eager to have a bag full of surprises, I reverted evertything back to mtu1500.... I didn't even bother to check if my Kubernetes cluster works with mtu9000..
TinyCore RedPill Loader (TCRP)
in Loaders
Posted
What what? I have never seen anything else than a one to one mapping of host to port and multiple ports to a single controller.
Learned something new today, thanks @pocopico!