Peter Suh Posted October 1, 2023 Author Share #751 Posted October 1, 2023 47 minutes ago, coint_cho said: 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? Do you have more than one bootloader connected to your VM? Please send the result of the command below at the prompt. ls -l /sys/block Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 1, 2023 Author Share #752 Posted October 1, 2023 1 hour ago, coint_cho said: 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? This is the result of testing on my VM with two boot loaders. Do you see the same error? Quote Link to comment Share on other sites More sharing options...
gericb Posted October 1, 2023 Share #753 Posted October 1, 2023 8 hours ago, Peter Suh said: 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. [AFTER BUILD] Thanks! I will get that for you here shortly. What definitely doesn't make sense to me, is that I am starting off with a virgin usb, and creation of the usb. Given the fantastic "hand holding" nature of your great menu system, there is literally nothing I or anyone can do, that I can think of to screw up the process, such that it would be clearly taking up more space. Pick a model, enter SN, MAC, etc. build. I'm not adding anything anywhere besides that... How this space is used and managed is all behind the scenes and pretty much out of control of the keyboard jockey, at least so I think...basically infallible. ALL of your partitions are different sized than mine after the first build, which if we are using the exact same program, doesn't seem like it would be possible, other than if there are additions or failed deletions that are zooming by in the build progress status window. Even more interesting that after my initial build and simply restarting to "build loader" again, and doing nothing there, other than restarting to the normal loading of DSM, the 3rd partition goes from 97 to 99% when nothing was selected or manually changed. Hopefully I am not somehow the 🤪 in what should be a dummy-proof process! Haha Quote Link to comment Share on other sites More sharing options...
coint_cho Posted October 1, 2023 Share #754 Posted October 1, 2023 5 hours ago, Peter Suh said: Do you have more than one bootloader connected to your VM? Please send the result of the command below at the prompt. ls -l /sys/block 4 hours ago, Peter Suh said: This is the result of testing on my VM with two boot loaders. Do you see the same error? I don't have two as far as I'm aware, but I do have this manual args command args: -device 'nec-usb-xhci,id=usb-bus0,multifunction=on' -drive 'file=/var/lib/vz/template/iso/tinycore-redpill.v0.9.5.0.m-shell.img,media=disk,format=raw,if=none,id=drive-disk-bootloader' -device 'usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on' Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 1, 2023 Author Share #755 Posted October 1, 2023 22 minutes ago, gericb said: Thanks! I will get that for you here shortly. What definitely doesn't make sense to me, is that I am starting off with a virgin usb, and creation of the usb. Given the fantastic "hand holding" nature of your great menu system, there is literally nothing I or anyone can do, that I can think of to screw up the process, such that it would be clearly taking up more space. Pick a model, enter SN, MAC, etc. build. I'm not adding anything anywhere besides that... How this space is used and managed is all behind the scenes and pretty much out of control of the keyboard jockey, at least so I think...basically infallible. ALL of your partitions are different sized than mine after the first build, which if we are using the exact same program, doesn't seem like it would be possible, other than if there are additions or failed deletions that are zooming by in the build progress status window. Even more interesting that after my initial build and simply restarting to "build loader" again, and doing nothing there, other than restarting to the normal loading of DSM, the 3rd partition goes from 97 to 99% when nothing was selected or manually changed. Hopefully I am not somehow the 🤪 in what should be a dummy-proof process! Haha I hope the log you attached explains everything. The log is not false. There will definitely be a cause. There are more factors that cause log build errors than the ones you already know. It is my responsibility to try to prevent exceptions like this. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 1, 2023 Author Share #756 Posted October 1, 2023 (edited) 17 minutes ago, coint_cho said: I don't have two as far as I'm aware, but I do have this manual args command args: -device 'nec-usb-xhci,id=usb-bus0,multifunction=on' -drive 'file=/var/lib/vz/template/iso/tinycore-redpill.v0.9.5.0.m-shell.img,media=disk,format=raw,if=none,id=drive-disk-bootloader' -device 'usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on' It looks like you are in the process of changing the ATA loader to USB in the VM. Is the SA6400 the model you want to install? Other than this model, there is no need to go through the USB conversion process as above. If you really want to change USB instead of ATA, make it in the form below. https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/?do=findComment&comment=443077 It looks like you are probably passing through another real USB port. The loader changed to this USB appears as if it does not exist in the captured list. Edited October 1, 2023 by Peter Suh Quote Link to comment Share on other sites More sharing options...
gericb Posted October 1, 2023 Share #757 Posted October 1, 2023 43 minutes ago, Peter Suh said: I hope the log you attached explains everything. The log is not false. There will definitely be a cause. There are more factors that cause log build errors than the ones you already know. It is my responsibility to try to prevent exceptions like this. For my own knowledge verification, let me confirm something before I start this whole process, in case I've missed/misunderstood something previously... in which case you can reach through the net and shake me senseless, and a couple of slaps just for extra measure. (1) I know I can go through the whole process of creating the loader with Line "y" having encoded all of the relevant data in the line options above, successfully booting to my current level of DSM install with no problems. (2) Am I correct that without erasing/recreating the whole usb all over again, I should be able to then reboot the computer to the usb, again selecting "Build Loader" and this time, select Line "p" directly, nothing else, your scripts will do all of the needed backend cleaning/prepping to be update the usb for that version of DSM to be installed - right? I should be able to iteratively repeat Step 2 as needed for successive newer versions as they become available in your menu options - right? Thanks Thanks Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 1, 2023 Author Share #758 Posted October 1, 2023 19 minutes ago, gericb said: For my own knowledge verification, let me confirm something before I start this whole process, in case I've missed/misunderstood something previously... in which case you can reach through the net and shake me senseless, and a couple of slaps just for extra measure. (1) I know I can go through the whole process of creating the loader with Line "y" having encoded all of the relevant data in the line options above, successfully booting to my current level of DSM install with no problems. (2) Am I correct that without erasing/recreating the whole usb all over again, I should be able to then reboot the computer to the usb, again selecting "Build Loader" and this time, select Line "p" directly, nothing else, your scripts will do all of the needed backend cleaning/prepping to be update the usb for that version of DSM to be installed - right? I should be able to iteratively repeat Step 2 as needed for successive newer versions as they become available in your menu options - right? Thanks Thanks Don't you think there was something that was ignored before asking this question? You said in this post that you encountered numerous errors while building the loader. I'm most curious about zlastbuild.log, which contains a lot of these errors. A little while ago you said you could give me this file, but now why has it been replaced with a question? Is it difficult to download the zlastbuild.log file? My native language is also Korean. I am afraid that I may miss something while using a translator. Am I misunderstanding this? Quote Link to comment Share on other sites More sharing options...
gericb Posted October 1, 2023 Share #759 Posted October 1, 2023 15 minutes ago, Peter Suh said: Don't you think there was something that was ignored before asking this question? You said in this post that you encountered numerous errors while building the loader. I'm most curious about zlastbuild.log, which contains a lot of these errors. A little while ago you said you could give me this file, but now why has it been replaced with a question? Is it difficult to download the zlastbuild.log file? My native language is also Korean. I am afraid that I may miss something while using a translator. Am I misunderstanding this? 죄송하지만, 저는 웃기면서도 동시에 진지하려고 노력했습니다. 나는 당신의 멋진 메뉴 도구를 사용하는 단순함을 완전히 이해하고 잘못된 가정을 하지 않았는지 확인하려고 노력했습니다. 곧 여기에서 로그를 가져다 드리겠습니다. 감사합니다 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 1, 2023 Author Share #760 Posted October 1, 2023 죄송하지만, 저는 웃기면서도 동시에 진지하려고 노력했습니다. 나는 당신의 멋진 메뉴 도구를 사용하는 단순함을 완전히 이해하고 잘못된 가정을 하지 않았는지 확인하려고 노력했습니다. 곧 여기에서 로그를 가져다 드리겠습니다. 감사합니다I found you humorous in our conversation over the past few days. However, my more detailed explanation may be boring and serious. I plan to provide this explanation after analyzing the log. I expect that your log analysis will reveal whether your assumptions were incorrect.Sent from my iPhone using Tapatalk Quote Link to comment Share on other sites More sharing options...
gericb Posted October 2, 2023 Share #761 Posted October 2, 2023 1 hour ago, Peter Suh said: I found you humorous in our conversation over the past few days. However, my more detailed explanation may be boring and serious. I plan to provide this explanation after analyzing the log. I expect that your log analysis will reveal whether your assumptions were incorrect. Sent from my iPhone using Tapatalk 미안하지만, USB의 3 개 파티션 중 하나에이 폴더는 어디에 있습니까? 요청한 로그 파일을 찾을 수 없습니다. 정확히 어디인지 명확히 할 수 있습니까? /home/tc folder - zlastbuild.log Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 2, 2023 Author Share #762 Posted October 2, 2023 2 hours ago, gericb said: 미안하지만, USB의 3 개 파티션 중 하나에이 폴더는 어디에 있습니까? 요청한 로그 파일을 찾을 수 없습니다. 정확히 어디인지 명확히 할 수 있습니까? /home/tc folder - zlastbuild.log Quote Link to comment Share on other sites More sharing options...
gericb Posted October 2, 2023 Share #763 Posted October 2, 2023 10 hours ago, Peter Suh said: ᄏ! 그래서 내 구체적인 질문에 따라, 나는 당신의 대답이 아니오를 의미한다고 가정합니다. 파일은 컴퓨터에서 제거되면 3개의 USB 파티션에서 찾을 수 없습니다. 로더 건물 환경에 있는 동안에만 액세스할 수 있으며 종료되면 손실됩니다. Quote Link to comment Share on other sites More sharing options...
shibby Posted October 2, 2023 Share #764 Posted October 2, 2023 On 10/1/2023 at 2:34 PM, coint_cho said: -drive 'file=/var/lib/vz/template/iso/tinycore-redpill.v0.9.5.0.m-shell.img,media=disk,format=raw,if=none,id=drive-disk-bootloader just use vmdk (ATA boot) file instead of img (USB boot) as sata0. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 2, 2023 Author Share #765 Posted October 2, 2023 (edited) 1 hour ago, gericb said: ᄏ! 그래서 내 구체적인 질문에 따라, 나는 당신의 대답이 아니오를 의미한다고 가정합니다. 파일은 컴퓨터에서 제거되면 3개의 USB 파티션에서 찾을 수 없습니다. 로더 건물 환경에 있는 동안에만 액세스할 수 있으며 종료되면 손실됩니다. Korean is translated a little strangely through a translator. It would be better to use English as usual. To roughly infer from what is written in Korean, the file exists in /home/tc on the USB stick, but you don't seem to know how to get the zlastbuild.log file. (This is how to download log files.) Open a command window using cmd in Windows. Try the command as below. [IP address is an example. Use yours] mkdir c:\tmp scp -r tc@192.168.1.1:/home/tc/zlastbuild.log c:\tmp dir c:\tmp The scp command asks for a password, and the password is P@ssw0rd. The 0 after w is the number 0. You will receive a zlastbuild.log file in your Windows c:\tmp. This process should be done in the TCRP Loader build phase, where you will see four windows. Edited October 2, 2023 by Peter Suh Quote Link to comment Share on other sites More sharing options...
gericb Posted October 2, 2023 Share #766 Posted October 2, 2023 7 hours ago, Peter Suh said: Korean is translated a little strangely through a translator. It would be better to use English as usual. To roughly infer from what is written in Korean, the file exists in /home/tc on the USB stick, but you don't seem to know how to get the zlastbuild.log file. (This is how to download log files.) Open a command window using cmd in Windows. Try the command as below. [IP address is an example. Use yours] mkdir c:\tmp scp -r tc@192.168.1.1:/home/tc/zlastbuild.log c:\tmp dir c:\tmp The scp command asks for a password, and the password is P@ssw0rd. The 0 after w is the number 0. You will receive a zlastbuild.log file in your Windows c:\tmp. This process should be done in the TCRP Loader build phase, where you will see four windows. Guilty as charged! I was thinking and hoping the log file might actually be saved for later viewing as needed to one of the 3 USB partitions (maybe a good idea to implement), so I was looking all over the usb using my Mac/Windows/Linux and could not find anything, now I know why - "This process should be done in the TCRP Loader build phase, where you will see four windows." Since the USB process I did yesterday, completely filled partition 3, 100% ... I'll erase and rebuild again, later and get that log, before rebooting. Is the log file lost at reboot, if not saved first? Thanks Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 3, 2023 Author Share #767 Posted October 3, 2023 On 10/1/2023 at 11:05 PM, gericb said: For my own knowledge verification, let me confirm something before I start this whole process, in case I've missed/misunderstood something previously... in which case you can reach through the net and shake me senseless, and a couple of slaps just for extra measure. (1) I know I can go through the whole process of creating the loader with Line "y" having encoded all of the relevant data in the line options above, successfully booting to my current level of DSM install with no problems. (2) Am I correct that without erasing/recreating the whole usb all over again, I should be able to then reboot the computer to the usb, again selecting "Build Loader" and this time, select Line "p" directly, nothing else, your scripts will do all of the needed backend cleaning/prepping to be update the usb for that version of DSM to be installed - right? I should be able to iteratively repeat Step 2 as needed for successive newer versions as they become available in your menu options - right? Thanks Thanks No matter how hard I try, I can't figure out which process is causing the zlastbuild.log file to be lost. I am now becoming confused in my conversation with you. You said you only used the p line in this question. Did you actually use this p line? If I infer a scenario where the zlastbuild.log file is not created, The zlastbuild.log file cannot be created unless you directly command rploader.sh or my.sh. The content at the bottom right of the capture shows the processor calling my.sh within menu_m.sh and leaving a log file /home/tc/zlastbuild.log. Each time you execute the p or y line, the /home/tc/zlastbuild.log file is overwritten and a new file is written. There is no separate erasing process. On newly created USB sticks, SN and MAC will be empty. After going through the process of filling out this part, you must use the p line. SN and MAC must be processed either manually or automatically generated. Is it correct that you finally executed the p line in the upper left menu shown in this capture? 1 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 4, 2023 Author Share #768 Posted October 4, 2023 (edited) [NOTICE] The TCRP-mshell "firmware version cannot be recognized" Issue-related improvements ARPL covers this error with an addon called hdddb. (Probably requires separate selection) TCRP provides the same coverage with an addon called drivedatabase. It's from @007revad's Synology_HDD_db scripts. After installing DSM, you must boot at least once for this message to disappear. This improved addon was created under the new name syno-hdd-db. https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/syno-hdd-db This addon records the firmware version and model in advance in the model management db file (contents are json) upon installation of DSM. So, “The firmware version is not recognized.” I have improved it so that you cannot see the message at all. With a structure roughly like this DB for each model, such as /var/lib/disk-compatibility/ds3622xs+_host_v7.db It is written to the end of the file. Covers both disk and NVMe. If you are curious about the contents inside You can check the contents by executing this command with the root account. jq. /var/lib/disk-compatibility/ds3622xs+_host_v7.db { "key": "SSDSC2BB080G4", --> Model name "value": { "D2010355": { --> Firmware version "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] }, "default": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] } } } TCRP automatically replaces the existing drivedatabase with syno-hdd-db. If you have previously applied it well and have no problems, there is no need to build a new loader. This new addon will be automatically applied to loaders built in the future. Edited October 4, 2023 by Peter Suh 1 1 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 5, 2023 Author Share #769 Posted October 5, 2023 On 10/3/2023 at 7:07 AM, gericb said: Guilty as charged! I was thinking and hoping the log file might actually be saved for later viewing as needed to one of the 3 USB partitions (maybe a good idea to implement), so I was looking all over the usb using my Mac/Windows/Linux and could not find anything, now I know why - "This process should be done in the TCRP Loader build phase, where you will see four windows." Since the USB process I did yesterday, completely filled partition 3, 100% ... I'll erase and rebuild again, later and get that log, before rebooting. Is the log file lost at reboot, if not saved first? Thanks I found the cause of unnecessary consumption of space in the 3rd partition. Because the space occupied by these files was not calculated, an error occurred in which the available space went to 0. There is no need to provide logs. Rebuilding the loader will automatically resolve this issue. https://github.com/PeterSuh-Q3/tinycore-redpill/commit/2930866140dc924eba2b57309cc53616f898cd33 Quote Link to comment Share on other sites More sharing options...
pocopico Posted October 5, 2023 Share #770 Posted October 5, 2023 15 hours ago, Peter Suh said: I found the cause of unnecessary consumption of space in the 3rd partition. Because the space occupied by these files was not calculated, an error occurred in which the available space went to 0. There is no need to provide logs. Rebuilding the loader will automatically resolve this issue. https://github.com/PeterSuh-Q3/tinycore-redpill/commit/2930866140dc924eba2b57309cc53616f898cd33 I've been away for some time. So i've somehow lost track of the progress of the loader. We were always using the same partition size for 1st and 2nd partitions as these are the syno defaults, actually the same ones that someone will find on an original syno device. We never know if thats checked somehow (now or in the future) so the recommendation from TTG was to keep it as is. I know we've changed a lot of things by introducing new method for modules etc, but we still have a lot of spare space in the third partition to store all the required files for the loader. 3 Quote Link to comment Share on other sites More sharing options...
killseeker Posted October 6, 2023 Share #771 Posted October 6, 2023 On 10/4/2023 at 10:27 PM, Peter Suh said: [NOTICE] The TCRP-mshell "firmware version cannot be recognized" Issue-related improvements ARPL covers this error with an addon called hdddb. (Probably requires separate selection) TCRP provides the same coverage with an addon called drivedatabase. It's from @007revad's Synology_HDD_db scripts. After installing DSM, you must boot at least once for this message to disappear. This improved addon was created under the new name syno-hdd-db. https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/syno-hdd-db This addon records the firmware version and model in advance in the model management db file (contents are json) upon installation of DSM. So, “The firmware version is not recognized.” I have improved it so that you cannot see the message at all. With a structure roughly like this DB for each model, such as /var/lib/disk-compatibility/ds3622xs+_host_v7.db It is written to the end of the file. Covers both disk and NVMe. If you are curious about the contents inside You can check the contents by executing this command with the root account. jq. /var/lib/disk-compatibility/ds3622xs+_host_v7.db { "key": "SSDSC2BB080G4", --> Model name "value": { "D2010355": { --> Firmware version "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] }, "default": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] } } } TCRP automatically replaces the existing drivedatabase with syno-hdd-db. If you have previously applied it well and have no problems, there is no need to build a new loader. This new addon will be automatically applied to loaders built in the future. Thank you for all your continued work Peter Do these above fixes have any impact the issues with disk firmware messages for the 918+ or 920+ systems as shared from this post from last month? Many thanks again! Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 6, 2023 Author Share #772 Posted October 6, 2023 6 hours ago, pocopico said: I've been away for some time. So i've somehow lost track of the progress of the loader. We were always using the same partition size for 1st and 2nd partitions as these are the syno defaults, actually the same ones that someone will find on an original syno device. We never know if thats checked somehow (now or in the future) so the recommendation from TTG was to keep it as is. I know we've changed a lot of things by introducing new method for modules etc, but we still have a lot of spare space in the third partition to store all the required files for the loader. you're right. In your opinion, if possible, it would be safer to keep SYNO's original size and not change the size as recommended by TTG. FRIEND is concentrated in the 3rd partition, The existing JOT mode still writes files to the 1st and 2nd partitions. Since these files include compressed integrated modules, there is a high possibility of exceeding the capacity. To maintain the existing partition size, these JOT files should also be written to the third partition. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 6, 2023 Author Share #773 Posted October 6, 2023 Thank you for all your continued work Peter [emoji4] Do these above fixes have any impact the issues with disk firmware messages for the 918+ or 920+ systems as shared from this post from last month? Many thanks again!IMHO, I don't think there is any relationship between the log not finding the sata chipset and the process of adding this disk model and firmware version to the compatibility database. thank you.Sent from my iPhone using Tapatalk Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 6, 2023 Author Share #774 Posted October 6, 2023 [notification] Improvements related to broken 2-byte Unicode characters in TCRP-mshell menu After MSHELL started supporting multiple languages in the menu, we received inquiries about unnecessary Korean characters appearing broken in English-speaking countries, so we made improvements. However, this improvement was carried out without accurately identifying the cause, so inconveniences continued. The cause was an error in the menu.sh script where locale settings related to the URxvt terminal recorded in the /home/tc/.Xdefaults file were duplicated. Now, as you can see in the bottom right, the improvements that are neatly organized to point to only one locale will be automatically reflected in the final version update. However, when using the 0.9.5.0 image from GitHub, the problem persisted because . In the screen you see now, the three windows at the top right, bottom left, and bottom right are aterms that do not support 2-byte Unicode (Korean, Japanese, Chinese, etc.). We have re-uploaded the 0.9.5.0 image to GitHub as an improved version with .Xdefaults cleaned up and Urxvt running in the menu window. Menus default to United States (en_US) codes. The moment you connect to the Internet, the router searches for the area code of the connected country, and if en_US detects a different area code, it asks you to change it. This question will no longer be asked after specifying and saving the country pointed to by the router. When switching from the default installation state of the United States (en_US) to another country such as ko_KR, the language that uses 2-byte Unicode In the case of Korean, Japanese, and Chinese, you will see characters broken into square boxes like this. This is a temporary phenomenon. If you back up TCRP and reboot, the text will no longer be corrupted. Quote Link to comment Share on other sites More sharing options...
gericb Posted October 6, 2023 Share #775 Posted October 6, 2023 On 10/2/2023 at 8:10 PM, Peter Suh said: No matter how hard I try, I can't figure out which process is causing the zlastbuild.log file to be lost. I am now becoming confused in my conversation with you. You said you only used the p line in this question. Did you actually use this p line? If I infer a scenario where the zlastbuild.log file is not created, The zlastbuild.log file cannot be created unless you directly command rploader.sh or my.sh. The content at the bottom right of the capture shows the processor calling my.sh within menu_m.sh and leaving a log file /home/tc/zlastbuild.log. Each time you execute the p or y line, the /home/tc/zlastbuild.log file is overwritten and a new file is written. There is no separate erasing process. On newly created USB sticks, SN and MAC will be empty. After going through the process of filling out this part, you must use the p line. SN and MAC must be processed either manually or automatically generated. Is it correct that you finally executed the p line in the upper left menu shown in this capture? It was ME, @Peter Suh I just assumed that this log file (not lost in the process) would be saved somewhere on the USB itself, so at any point later, someone could go back to the appropriate partition on the USB, and find this log file, if it needed to be referenced for diagnostics (maybe a good idea?). It may was my failure to understand it was only viewable / found while still in the whole build / configuration process....accessible in the green terminal windows BEFORE rebooting to start the loader - now I know. My apologies! 🤠 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.