TinyCore RedPill Loader Build Support Tool ( M-Shell )

[asaf]

2 hours ago, shibby said:

 

Notice:

Storage Manager will no longer display S.M.A.R.T. attributes after DSM 7.2.1-69057. Please consider before updating.

😐

 

Let's hope it's a temporary decision and not a permanent one...

[Peter Suh]

3 hours ago, shibby said:

 

Notice:

Storage Manager will no longer display S.M.A.R.T. attributes after DSM 7.2.1-69057. Please consider before updating.

😐

 

 

This part was already changed yesterday following the modifications to storagepanel, an addon to ARPL-i18n.
If you just rebuild the loader, 69057 will be applied automatically.

 

https://github.com/PeterSuh-Q3/tcrp-addons/commit/22bb62bd61a70bfafb4633c44912195f26a46d86

[Peter Suh]

3 hours ago, tdse13 said:

What are the steps to upgrade from 7.2-64570 to 7.2.1-69057? Thank you.

 

1. Enter the TCRP loader build menu (second selection right below FRIEND) from the USB stick you were previously using.

 

2. Rebuild by selecting the newly added 7.2.1-69057 Loader Build menu.

 

3. During the reboot process, you will be asked to install DSM 7.2.1-69057. Proceed with the installation like this and you are done.

[Trabalhador Anonimo]

22 hours ago, Peter Suh said:

 

 

Distribution of TCRP 7.2.1-69057 revision has been completed.

When you enter the TCRP Loader Build menu, the latest version will be automatically updated.

you will see a new menu for 7.2.1-69057.

Please build using only this new menu.

Building the loader should take priority over installing the pat file from the control panel of previous versions of DSM.

 

I do not know if it is right, but it delete everything of the configuration, include LUN code. I had to reconfigure IP address, load balance and Windows server ISCSI connection. Data is intact. 😭

And forced me to run a data debugging!

 

Edited September 27, 2023 by Trabalhador Anonimo

[coint_cho]

Just upgraded from 7.1.1-42962 to 7.2.1-69057 DS920+ on my Proxmox box. Currently for some reason there are lots of apps that's broken in package manager, and I can't fix or repair any of it without an error message popping up.

 

My file manager is also not working, and the whole UI is just very sluggish in general. Any ways that I can rebuild the whole Redpill image without losing any data?

 

I tried booting into Tinycore to rebuild it again but for some reason none of the 4 terminals comes up and trying to launch it manually doesn't bring up anything

[Trabalhador Anonimo]

30 minutes ago, coint_cho said:

Just upgraded from 7.1.1-42962 to 7.2.1-69057 DS920+ on my Proxmox box. Currently for some reason there are lots of apps that's broken in package manager, and I can't fix or repair any of it without an error message popping up.

 

My file manager is also not working, and the whole UI is just very sluggish in general. Any ways that I can rebuild the whole Redpill image without losing any data?

 

I tried booting into Tinycore to rebuild it again but for some reason none of the 4 terminals comes up and trying to launch it manually doesn't bring up anything

 

I did not have any problems with packages. They are all ready.

[coint_cho]

10 minutes ago, Trabalhador Anonimo said:

 

I did not have any problems with packages. They are all ready.

I think it's because I interrupted the process because it took too long, so I probably need to reinstall and redo everything sadly

[tdse13]

 

1 hour ago, Peter Suh said:

 

1. Enter the TCRP loader build menu (second selection right below FRIEND) from the USB stick you were previously using.

 

2. Rebuild by selecting the newly added 7.2.1-69057 Loader Build menu.

 

3. During the reboot process, you will be asked to install DSM 7.2.1-69057. Proceed with the installation like this and you are done.

 

Thank you. Update went through smoothly. S.M.A.R.T. attributes are still available with e. g. smartctl -a -d sat /dev/sda1

[shibby]

Today i updated my Proxmox VM flawlessly.

 

[carlozo]

for me doesn t work on esxi 7 u3

 

ds3622xs+

 

can t find disks

 

i edit the user config manual        sataportmap  1

 

and diskidxmap  0A00

 

sata 0    0.0

 

sata1     1.0

 

doesnt work cant find disks

 

3 days ago work with  ds1823xs+

 

i start the vm and look to the user config the network cars stay the same but   sataportmap and diskidxmap go back to """,

 

look like after i made changes manual and after i build and reboot don t keep what i change

 

[carlozo]

can you please tell me the difference between DDSML   EUDEV    and DDSML+EUDEV

 

 

for me works when i use DDSML+EUDEV

 

please

[gericb]

On 9/27/2023 at 8:05 AM, Peter Suh said:

 

1. Enter the TCRP loader build menu (second selection right below FRIEND) from the USB stick you were previously using.

 

2. Rebuild by selecting the newly added 7.2.1-69057 Loader Build menu.

 

3. During the reboot process, you will be asked to install DSM 7.2.1-69057. Proceed with the installation like this and you are done.

Fun times!  Previously been using 0.9.4.3-2 no issues.  I figured it was safe to reboot and rebuild the loader for the 7.2.1-69057,  selected from the menu, and despite having a 16GB USB, it complained at some point, not having enough free space, went through the build, once it reboots, found a new FRIEND, but also couldn't process, complaining about free space.  Of course it upgraded automatically the loader to 0.9.5, now it's back to the TCRP basic blue screen and lost my whole configuration, MAC addresses, SN, Model, etc.

 

Looking at the USB layout, it's MBR style - 71MB (FAT), 75MB (FAT), 877MB (FAT32), 13.3GB (FREE)

 

No doubt thanks to @Peter Suh I have found the multiple renamed/archived user_config.jsonYearMonthDay files which contains all of the relevant SN/MAC/etc. info. 

 

What's the best way to go here, just record that relevant data from the user_config, totally rebuild the USB from scratch manually encoding the data for the build... or some minor slight of hand with saving and restoring one of the user_config.json files?

 

Curious too, I noticed on my Windows 11 Pro machine, when the USB is plugged in, none of the partitions show up in File Explorer, but on my Windows 10 Pro, no problem the 2nd (75MB) and 3rd (877MB) partitions show up just fine and accessible...  I don't think this is do to the previous install of OSFMount program, but it could be.  Just found it interesting. 🤔

 

 Thanks

Edited September 28, 2023 by gericb

[Peter Suh]

5 hours ago, gericb said:

Fun times!  Previously been using 0.9.4.3-2 no issues.  I figured it was safe to reboot and rebuild the loader for the 7.2.1-69057,  selected from the menu, and despite having a 16GB USB, it complained at some point, not having enough free space, went through the build, once it reboots, found a new FRIEND, but also couldn't process, complaining about free space.  Of course it upgraded automatically the loader to 0.9.5, now it's back to the TCRP basic blue screen and lost my whole configuration, MAC addresses, SN, Model, etc.

 

Looking at the USB layout, it's MBR style - 71MB (FAT), 75MB (FAT), 877MB (FAT32), 13.3GB (FREE)

 

No doubt thanks to @Peter Suh I have found the multiple renamed/archived user_config.jsonYearMonthDay files which contains all of the relevant SN/MAC/etc. info. 

 

What's the best way to go here, just record that relevant data from the user_config, totally rebuild the USB from scratch manually encoding the data for the build... or some minor slight of hand with saving and restoring one of the user_config.json files?

 

Curious too, I noticed on my Windows 11 Pro machine, when the USB is plugged in, none of the partitions show up in File Explorer, but on my Windows 10 Pro, no problem the 2nd (75MB) and 3rd (877MB) partitions show up just fine and accessible...  I don't think this is do to the previous install of OSFMount program, but it could be.  Just found it interesting. 🤔

 

 Thanks

 

Probably you are using 2 USB sticks before/after. In fact, the only items that need to be imported from the previous stick are Synology SN, SataportMap DiskIdxMap, etc. An easy way is to take good notes and then copy them down in the same way.

[gericb]

7 hours ago, Peter Suh said:

 

Probably you are using 2 USB sticks before/after. In fact, the only items that need to be imported from the previous stick are Synology SN, SataportMap DiskIdxMap, etc. An easy way is to take good notes and then copy them down in the same way.

TBH, I am more concerned why it blew up on me, a USB, loader working perfectly fine for many previous updates, as evident by the numerous archived user.config files.  This is a 16GB USB, so more than enough free space on the device itself, but with the partitions created, obviously not.  I think it would be relevant to know why, since it wasn't anything weird or unusual on my part, just followed the normal sequence of things in your 4 screens menu/build system to upgrade to 7.2.1-69057.  

 

Are there any log files that I can provide you from the USB so you can see the path of failure and make any corrections to avoid future glitches? 😉

 

Can I just create a new USB and then transfer the user_conf file that was previously working, into the correct location on the USB and then "build loader" once that is in place? (Seemingly more logical then having to manually transcribe old info into a new USB data fields)

 

What I am concerned about is that I was using 0.9.4.3-2 and your process upgraded me to 0.9.5.0 as a by product of rebuilding to 7.2.1-69057 w/Friend, but yet on your GitHub, you indicate that 0.9.5.0 is only "This is a testing version. Do not use unless you are certain you have no data to lose." so then why is the loader updating automatically upgrading to this, if it's not total stable and instead maintaining the 0.9.4.3-2 instead?

 

Thanks

Edited September 29, 2023 by gericb

[Netizen1]

1 hour ago, gericb said:

TBH, I am more concerned why it blew up on me, a USB, loader working perfectly fine for many previous updates, as evident by the numerous archived user.config files.  This is a 16GB USB, so more than enough free space on the device itself, but with the partitions created, obviously not.  I think it would be relevant to know why, since it wasn't anything weird or unusual on my part, just followed the normal sequence of things in your 4 screens menu/build system to upgrade to 7.2.1-69057.  

 

The other project, ARPL I believe, increases the third partition to use more of the free space on the USB, but I don't think TCRP or Mshell have that function built in.

 

You could modify the third partition of your USB using some partitioning software before you try again. However, it would be cool if pocopico and Peter Suh adopted the repartition step in their respective projects 😇

[coint_cho]

On 9/27/2023 at 9:11 PM, coint_cho said:

Just upgraded from 7.1.1-42962 to 7.2.1-69057 DS920+ on my Proxmox box. Currently for some reason there are lots of apps that's broken in package manager, and I can't fix or repair any of it without an error message popping up.

 

My file manager is also not working, and the whole UI is just very sluggish in general. Any ways that I can rebuild the whole Redpill image without losing any data?

 

I tried booting into Tinycore to rebuild it again but for some reason none of the 4 terminals comes up and trying to launch it manually doesn't bring up anything

Anyone? 😕

[gericb]

7 hours ago, Netizen1 said:

 

The other project, ARPL I believe, increases the third partition to use more of the free space on the USB, but I don't think TCRP or Mshell have that function built in.

 

You could modify the third partition of your USB using some partitioning software before you try again. However, it would be cool if pocopico and Peter Suh adopted the repartition step in their respective projects 😇

Definitely sounds like they need to!  I tried your suggestion, unfortunately it didn't work, it got so badly self-flummoxed, it doesn't boot normally or in build mode anymore, basically short of an epic fail.  At least I know where to get my key variables, so I can record those for later additional failures, hehehe.  Definitely would seem to suggest that the 0.9.5 loader isn't stable and shouldn't be automatically upgrading in the process, given the warning Peter Suh has posted on his GitHub for it.  I would have thought he might have wanted some logs from the USB at least out of curiosity, to possibly spot WTF happened...but seems not.   You learn something new every day...hopefully. 👍🏻

Edited September 29, 2023 by gericb

[Peter Suh]

The three FAT partitions on the USB stick were originally designed by pocopico, and I began to slightly change their size. Even at this time, pocopico had negative opinions about variations in the default size. For several reasons, such as when modules are integrated, the capacity limit may be exceeded unstable. If this happens, the loader may be destroyed and cannot be repaired. It is not easy to predict such an event in advance.
pocopico seems to have been concerned about partition instability due to expanding the partition size according to the capacity of the USB stick.

I have implemented a script in MShell to prevent the third partition from exceeding its capacity.

[gericb]

11 minutes ago, Peter Suh said:

The three FAT partitions on the USB stick were originally designed by pocopico, and I began to slightly change their size. Even at this time, pocopico had negative opinions about variations in the default size. For several reasons, such as when modules are integrated, the capacity limit may be exceeded unstable. If this happens, the loader may be destroyed and cannot be repaired. It is not easy to predict such an event in advance.
pocopico seems to have been concerned about partition instability due to expanding the partition size according to the capacity of the USB stick.

I have implemented a script in MShell to prevent the third partition from exceeding its capacity.

Would any logs from my USB be helpful to you?

 

"This is a testing version. Do not use unless you are certain you have no data to lose."

👆🏼 Why does an existing 0.9.4.3-2 loader upgrade automatically to 0.9.5 given your warning statement here?

 

Please note that minimum recommended memory size for configuring the loader is 2GB"

👆🏼 What is this referring to, the total size of the USB, or the 3rd partition?

 

"I have implemented a script in MShell to prevent the third partition from exceeding its capacity."

👆🏼 When was this implemented?  I built the 0.9.4.3-2 loader some time ago, and done at least 4 DSM upgrades with it, would seem like your script failed, since I was 

      exactly getting out of space warnings.

 

Thanks

 

[Peter Suh]

26 minutes ago, gericb said:

Would any logs from my USB be helpful to you?

 

"This is a testing version. Do not use unless you are certain you have no data to lose."

👆🏼 Why does an existing 0.9.4.3-2 loader upgrade automatically to 0.9.5 given your warning statement here?

 

Please note that minimum recommended memory size for configuring the loader is 2GB"

👆🏼 What is this referring to, the total size of the USB, or the 3rd partition?

 

"I have implemented a script in MShell to prevent the third partition from exceeding its capacity."

👆🏼 When was this implemented?  I built the 0.9.4.3-2 loader some time ago, and done at least 4 DSM upgrades with it, would seem like your script failed, since I was 

      exactly getting out of space warnings.

 

Thanks

 

 

If it was the 1st or 2nd partition, we know roughly where the size oversize occurs. This is related to what I mentioned above about the difficulty of predicting.

The mention of a test version seems to have followed the starting point of forking pocopico's github repo. I think I need to check again and fix it.
Shouldn’t we consider it to be no longer in the testing phase?

Unlike pocopico's TCRP, MShell always automatically updates the menu script to the latest version.
When looking only at the version of menu_m.sh, 0.9.5.0 has already passed.

2GB is the minimum amount of RAM.
It has nothing to do with USB.

In the case of bare metal, about 2 dsm pats can be stored in about 850MB of space. But now the size of this file is getting bigger. Since TC backup files must also be stored together, vacant records must be managed more efficiently.
(Perhaps the script may need to be adjusted to predict the size of the pat file, which has become larger in 7.2.1.)

For Vmdk, 3GB more was given to the 3rd partition. However, it is best to avoid storing too many dsm pats. Eventually, I experienced this partition being broken.

[gericb]

20 hours ago, Peter Suh said:

 

If it was the 1st or 2nd partition, we know roughly where the size oversize occurs. This is related to what I mentioned above about the difficulty of predicting.

The mention of a test version seems to have followed the starting point of forking pocopico's github repo. I think I need to check again and fix it.
Shouldn’t we consider it to be no longer in the testing phase?

Unlike pocopico's TCRP, MShell always automatically updates the menu script to the latest version.
When looking only at the version of menu_m.sh, 0.9.5.0 has already passed.

2GB is the minimum amount of RAM.
It has nothing to do with USB.

In the case of bare metal, about 2 dsm pats can be stored in about 850MB of space. But now the size of this file is getting bigger. Since TC backup files must also be stored together, vacant records must be managed more efficiently.
(Perhaps the script may need to be adjusted to predict the size of the pat file, which has become larger in 7.2.1.)

For Vmdk, 3GB more was given to the 3rd partition. However, it is best to avoid storing too many dsm pats. Eventually, I experienced this partition being broken.

So the saga continues...

 

I decided a few minutes ago, to download the new 0.9.5, completely delete all partitions and data on the old USB, documenting my old relevant data, SN/MAC's and build a new loader with the same USB.

 

Numerous errors along the way, can't find this, can't do that, too much space can't use it all, etc. etc.

 

Went through all the key steps, and to the point of "Reboot Loader" it goes to boot the USB, and I am presented with only "Build the Loader" option, and when I click on that, it's the same failure as before, back to the basic TCRP blue background (icons at the bottom) and 4 windows, 2 of which are filled with numerous error messages.

 

So given I've not used a different USB, nothing else has changed but the new loader, I'd venture to say it's unreliable, which sadly leaves me currently dead in the water.

 

At this point, I think I'm in an endless loop.  Even if I build the loader again with 0.9.4.3-2 (which worked perfectly), won't it automatically upgrade to 0.9.5 again?

 

** So I ask you again, are there any logs I can provide you from the USB, to give you insight as to what is going on? **

 

Also, never previously included the fact that this is the Baremetal 920+ model, 2 Intel NIC, 2 HDD, so not a complex build (all been working fine for some time now, no other changes) 😵‍💫

 

UPDATE: Looking at the USB with MiniTool, it would appear the 877MB 3rd Partition is completely FULL, 100% Used.  The 1st/2nd Partitions are virtually empty, lots of free space left.

 

How can I help you?

 

Thanks

Edited September 30, 2023 by gericb

[gericb]

Just having created the latest TCRP 9.4.9C and then examining the partition sizes:

 

Partition 1 - 48MB

Partition 2 - 75MB

Partition 3 - 900MB

 

Seems like a razor thin difference, but it is 23MB effectively removed from Partition 1 and enlarged to Partition 3, compared to 0.9.4.3-2 or 0.9.5 values.

 

Do you think this restructuring would help with your loader and this issue?

 

UPDATE: So I just rebuild the USB fresh with 0.9.5, but only building with DSM 7.2-64570, which is what is currently installed on my setup, and I have revived the installation.  So I would say that puts it squarely as being an issue with the 7.2.1-69057 and the space it ultimately takes on the USB.

 

Here is my 16GB USB partition layout and free/used space at the time of the build and initial reboot.  Also after the 2nd reboot, I presume some backup was made consuming the extra space.

 

Interesting that 3 of the installed packages had to be repaired, upon starting up from the initial rebuilt loader and first boot, which went just fine, but still not sure what would have caused the need for this.

 

So now just a matter of figuring out how to get 7.2.1-69057 and beyond installed without totally crashing the loader USB. 

Edited September 30, 2023 by gericb

[Peter Suh]

3 hours ago, gericb said:

Just having created the latest TCRP 9.4.9C and then examining the partition sizes:

 

Partition 1 - 48MB

Partition 2 - 75MB

Partition 3 - 900MB

 

Seems like a razor thin difference, but it is 23MB effectively removed from Partition 1 and enlarged to Partition 3, compared to 0.9.4.3-2 or 0.9.5 values.

 

Do you think this restructuring would help with your loader and this issue?

 

UPDATE: So I just rebuild the USB fresh with 0.9.5, but only building with DSM 7.2-64570, which is what is currently installed on my setup, and I have revived the installation.  So I would say that puts it squarely as being an issue with the 7.2.1-69057 and the space it ultimately takes on the USB.

 

Here is my 16GB USB partition layout and free/used space at the time of the build and initial reboot.  Also after the 2nd reboot, I presume some backup was made consuming the extra space.

 

Interesting that 3 of the installed packages had to be repaired, upon starting up from the initial rebuilt loader and first boot, which went just fine, but still not sure what would have caused the need for this.

 

So now just a matter of figuring out how to get 7.2.1-69057 and beyond installed without totally crashing the loader USB. 

 

I am also preparing to replicate the same process as you.
I will report when the test is over.

[Peter Suh]

@gericb

 

This is the result of building DS920p-69057 using the model and revision you provided and a newly recorded USB stick.
As you can see, there is nothing special about it.

 

[BEFORE BUILD]

 

 

[AFTER BUILD]

 

 

I am sharing my zlastbuild.log file created during this process.

 

zlastbuild.log

Please share yours too. Let's compare the problems.

You will see it at the end of the /home/tc folder.

The spatial distribution of the third partition does not seem to be too difficult.
There is one pat file, and additional files are taking up space.

 

 

Edited October 1, 2023 by Peter Suh

[coint_cho]

Tried to remake a completely new VM in Proxmox for Xpenology.

 

Current face with these two issues. The built is done and I can see the boot entries on Grub

 

But booting into it gives me

 

Tried to rebuilt on DS920 and other models as well to no avail, any advices on this?

Edited October 1, 2023 by coint_cho