Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Won’t boot without USB after a successful installation #10

Closed
ghost opened this issue Nov 26, 2018 · 52 comments
Closed

Won’t boot without USB after a successful installation #10

ghost opened this issue Nov 26, 2018 · 52 comments
Assignees
Labels
known bug Something isn't working and that is already been fixed

Comments

@ghost
Copy link

ghost commented Nov 26, 2018

I installed using method 1 successfully, but now cant seem to boot without the usb drive. After the grub menu it hangs at a black screen and once I plug in the usb it startsup. [Surface Pro 3]

@imperador imperador self-assigned this Nov 26, 2018
@imperador imperador added the known bug Something isn't working and that is already been fixed label Nov 26, 2018
@alesimula
Copy link
Collaborator

alesimula commented Nov 26, 2018

Did you remove the USB after installing chromium (before booting for the first time)?

@Wolfley-Matt
Copy link

I have also replicated the issue on a Yoga 2 Pro, it seems that there is a display driver issue somehow. The install doesn't seem to place the necessary display drivers on the machine and USB boots following insertion without restart. This is odd, but I do know that I had to use the special build of Chromium in the first place to even have this process work.

@ghost
Copy link
Author

ghost commented Nov 26, 2018

Yes, I did as instructed.

@Wolfley-Matt
Copy link

To be clear, the OS boots from the USB and not the main disk when it is inserted during the blank screen. It is completely skipping the internal disk for operation.

@imperador
Copy link
Owner

Yes, I did as instructed.

@sajithU

Boot into your USB stick, go to the shell command line and type this command:
curl -L https://goo.gl/HdjwAZ | sudo bash -s /dev/sda

@gmanolo
Copy link

gmanolo commented Nov 29, 2018

Same issue on a old Sony Vaio VPCSB. I followed instructions carefully and not able to boot from internal disk. After grub operations end, screen is on (lighted) but nothing happen. Then, if you insert the USB key, it directly launches the live USB Chrome OS without rebooting. Hope this help for this issue.

Fix command: "curl -L https://goo.gl/HdjwAZ | sudo bash -s /dev/sda" didn't work.

@imperador
Copy link
Owner

imperador commented Dec 2, 2018

Can you post the result of your "lsblk" here?

@djhardrich
Copy link

Just fixed this on a personal machine by making a new img using Arnoldthebat's Vanilla image instead of Special... Had to do the Grub Fix as well that was posted above (curl -L command). Please note that the Grub Fix by itself with an image made with Special was not enough to fix the black screen...

@imperador
Copy link
Owner

I noticed that I never used Special imgs for testing. All my downloaded imgs are Vanilla. I'll see if I can replicate this problem with using the Special this time

@conscript42
Copy link

I have the same problem on my computer. Used the Acer Chromebook 14 (edgar) recovery as it is the closest to my hardware. Tried the grub fix but it still wont boot without inserting the USB drive. Used arnold's Special image, because with vanilla I can't get the touchpad scroll to work.

@xylobol
Copy link

xylobol commented Dec 14, 2018

I am experiencing the same issue. ThinkPad T440p with an i7 and 16GB of RAM. I used method 1 via Eve+Caroline with a Special build from ArnoldTheBat. After selecting local image A from the GRUB menu, it sits on a black screen with a solid white underscore in the upper left.

Nevermind. I re-installed 5 times, tried to boot to CrOS, and ran the GRUB fix command. It worked on the fifth try. Many thanks for the project.

@alesimula
Copy link
Collaborator

alesimula commented Dec 16, 2018

The newest fix_grub.sh script should take care of this once and for all (I hope)

@KoolenDasheppi
Copy link

I was having issues with this too. I fixed it by running the fix_grub.sh script, then booting another USB that had TinyCore Linux on it (I think any Linux distro will do). Then I copy and pasted the root uuid that the script changed from the grub.cfg to usb.A.cfg under syslinux. Maybe the script should change that one too.

@alesimula
Copy link
Collaborator

@kool601 That's already been corrected, but it's not in the releases yet;

Download it from the link above or github master branch for now

This should solve issues with Legacy boot on ATB too

@KoolenDasheppi
Copy link

I did download it from that link, and it didn't work correctly. I had to manually edit the usb.A.cfg file to paste in the partition from the grub.cfg file.

@gmanolo
Copy link

gmanolo commented Dec 18, 2018

@kool601 How did you copy from the grub.cfg to usb.A.cfg? May you give some steps? Thanks in advance to everyone

@alesimula
Copy link
Collaborator

@kool601 Weird, I tested the script right now and it changes the partition UUID correctly on usb.A.cfg; did you install chrome OS on the third partition? Also could you contact me on Telegram? I'm Alex Sim (chromefy telegram group)

@pablotix20
Copy link

I had the same problem on my computer, the sript above only changes the uuid in the uefi boot system, if you are booting in legacy, the system will try to find the usb partition because legay bootloader hasn't been changed. Writing the new UUID inside the syslinux folder of the EFI partition fixed the problem. I believe the script should change that too, I manually did it

@gmanolo
Copy link

gmanolo commented Jan 20, 2019

I stay stuck at the same point. I followed again all steps but again, it only boots from USB.
@pablotis I'd like to try your proposal but my knowledge on this is low, may you help me with a few steps on how to proceed? thanks in advance

@gmanolo
Copy link

gmanolo commented Jan 20, 2019

Back again, no luck! I could edit and modify the usb.a.cfg file with the PARTUUID info from grub.cfg but it doesn't still boot from the hdd.

My lsblk looks like this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 1.8G 1 loop /rofs
loop1 7:1 0 86.9M 1 loop /snap/core/4917
loop2 7:2 0 34.7M 1 loop /snap/gtk-common-themes/319
loop3 7:3 0 140.9M 1 loop /snap/gnome-3-26-1604/70
loop4 7:4 0 2.3M 1 loop /snap/gnome-calculator/180
loop5 7:5 0 13M 1 loop /snap/gnome-characters/103
loop6 7:6 0 14.5M 1 loop /snap/gnome-logs/37
loop7 7:7 0 3.7M 1 loop /snap/gnome-system-monitor/51
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 457.6G 0 part
├─sda2 8:2 0 16M 0 part
├─sda3 8:3 0 4G 0 part
├─sda4 8:4 0 16M 0 part
├─sda5 8:5 0 4G 0 part
├─sda6 8:6 0 512B 0 part
├─sda7 8:7 0 512B 0 part
├─sda8 8:8 0 16M 0 part
├─sda9 8:9 0 512B 0 part
├─sda10 8:10 0 512B 0 part
├─sda11 8:11 0 8M 0 part
└─sda12 8:12 0 32M 0 part /mnt
sdb 8:16 1 7.4G 0 disk
└─sdb1 8:17 1 7.4G 0 part /cdrom
sr0 11:0 1 1024M 0 rom

Both grub.cfg and usb.a.cfg files use "sda3 partuuid" as first option to boot but I still get black screen after booting

Also the usb.a.cfg file wasn't been modified by fix_grub.sh file.

Any help it would be well appreciate... thanks

@alesimula
Copy link
Collaborator

@gmanolo did you install it with the --skip_postinstall option? (you still have to apply fix_grub afterwards)

@gmanolo
Copy link

gmanolo commented Jan 20, 2019

Yes, all times with --skip_postinstall indicated. I didn't do anything different from these instructions.

Actually, I did everything again just now and I could check that at the beginning of the process is said "gpt header is invalid". I cannot say if this could be the problem or just a warning.

My next steps: I'll format again the hdd (dd) and burn again the image on the USB in order to to try a clean and fresh installation. I'll post the result...

Thanks!

@asapkota
Copy link

Anyone found a workaround for this yet? Boots with USB no problem. Installed to SSD. Applied chrome_fix linked above. Verified that the UUID is correct on both grub,cfg and usb.A.cfg. Still gets stuck on "Booting 'local image A'" Thanks

@kiwisibk
Copy link

Can anybode help me?
By applying the fix_grub.sh script I get always the message that there is no EFI partition:

chronos@localhost ~/Downloads $ sudo bash fix_grub.sh /dev/mmcblk1
Disk /dev/mmcblk1 does not have a EFI partition (corrupted?)
cat: /home/chronos/EFI/efi/boot/grub.cfg: No such file or directory
cat: /home/chronos/EFI/syslinux/usb.A.cfg: No such file or directory
sfdisk: /dev/mmcblk1: no partition table found
sed: can't read /home/chronos/EFI/efi/boot/grub.cfg: No such file or directory
sed: can't read /home/chronos/EFI/syslinux/usb.A.cfg: No such file or directory
EFI: Partition UUID changed to
Legacy: Partition UUID changed to
You can reboot your PC!

Here is my lsblk:

chronos@localhost ~/Downloads $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 1.2G 0 loop
-encstateful 254:0 0 1.2G 0 dm /mnt/stateful_partition/encrypted sda 8:0 1 28.9G 0 disk |-sda1 8:1 1 4G 0 part /mnt/stateful_partition |-sda2 8:2 1 64M 0 part |-sda3 8:3 1 2G 0 part / |-sda4 8:4 1 64M 0 part |-sda5 8:5 1 2G 0 part |-sda6 8:6 1 512B 0 part |-sda7 8:7 1 512B 0 part |-sda8 8:8 1 16M 0 part /usr/share/oem |-sda9 8:9 1 512B 0 part |-sda10 8:10 1 512B 0 part |-sda11 8:11 1 8M 0 part -sda12 8:12 1 128M 0 part
mmcblk1 179:0 0 58.2G 0 disk /media/removable/External Drive
mmcblk1boot0 179:16 0 4M 1 disk
mmcblk1boot1 179:32 0 4M 1 disk
mmcblk1rpmb 179:48 0 4M 0 disk
zram0 253:0 0 5.4G 0 disk [SWAP]

Many thanks for any support in this matter!!

@oneguynick
Copy link

I have the same issue as @kiwisibk on an EFI GPD Pocket 2. EFI works fine on cloudready and any other Linux install.

@mattvoss
Copy link

mattvoss commented Feb 15, 2019

I have run into the same issue. It appears that the EFI partition (/dev/sda12) is corrupted and the EFI information is not copied over. On further inspection I determined that the EFI partition is too small. It was only allocating 32MB to the partition. The EFI partition on the USB is 128MB. The main partition (/dev/sda1) looks to be oversized and was using up some of the space on the drive the EFI needed. So there is some issue with the partitioning script determining how much space to allocate to each partition.

Source files I used to create an image for a Dell Venue 11 Pro 7140:

ArnoldTheBat's enhanced special build – R72-11316.B
Eve R71 recovery
Caroline R71 TPM
Method 1 Automated

I solved it by doing the following:

  1. e2fsck main partition /dev/sda1
  2. resize2fs the main partition /dev/sda1 to a bit smaller size (reducing it by 1GB)
  3. deleted the main partition /dev/sda1 in fdisk
  4. added a new main partition /dev/sda1 with a new ending sector reflecting its smaller size and making sure to keep the ext4 signature
  5. removed the efi partition /dev/sda12 in fdisk
  6. added a new efi partition /dev/sda12 and specified to use all remaining space
  7. set new efi partition /dev/sda12 to file system type of 1 EFI Filesystem
  8. quit fdisk
  9. copied usb efi partition to local efi partition dd if=/dev/sdb12 of=/dev/sda12 bs=1M
  10. downloaded and ran fix_grub curl -L https://goo.gl/HdjwAZ | sudo bash -s /dev/sda

I was able to successfully boot with UEFI mode.

So the questions is: Why is the efi partition too small when using these source files?

@kiwisibk
Copy link

Question is: can anybody modify/correct the cromefy.sh script with your hints/suggestions? In order that non professional Linux unsers like me can use it? That would be really great!! :)

@mattvoss
Copy link

Yes I think this should be able to be fixed.

However I do not understand exactly why it is occuring. The issue more than likely is being caused by the chromeos-install script in the recreate_nand_partitions() function. Now it's very possible and probably likely that something the chromefy script is doing to the images is causing the issue in the install script.

In the meantime it should be possible to alter the fix_grub.sh script to handle the corrupted partition error. It prints out an error line when it encounters this issue but it proceeds with the rest of the script assuming naively that everything is fine. Obviously it is not ok. Instead it can run e2fsck, then use resize2fs and sfdisk to resize the partitions to the appropriate sizes, dd over the efi partition from the usb drive and finish fixing the efi boot configuration. This should allow someone with less experience to run this script after install and ensure the drive is bootable.

Perhaps I can get a pull request together for fix_grub.sh that would add this functionality in the next few days. I have to muck around with sfdisk to figure this out but it all looks straightforward.

@macstibs
Copy link

I was able to fix the problem for myself by the following

Confirmed this worked for me.

Thanks.

@david-schopf
Copy link

Thank you campbebj for this fix! Works perfectly.

@kiwisibk
Copy link

Looking really forward for a modified chromefy.sh script, which implements all mentioned optimizations!!

@pitiso
Copy link

pitiso commented Mar 4, 2019

  1. changed to a better size for partition 12 (i used 134217728 it ended up being a bit oversized but only by a few bytes) if you dont know how to use Vim this might give you a headache
    It almost did... except I found a nice tutorial that may help other people too: https://www.linux.com/learn/vim-101-beginners-guide-vim

As an aside, the solution was awesome and I was finally able to reboot from HDD. Too bad Google Play Store isn't working though... Is anybody able to have Google Play running?

@kiwisibk
Copy link

kiwisibk commented Mar 5, 2019

I managed it finally by applying this tutorial:

https://forum.xda-developers.com/hardware-hacking/chromebooks/guide-installing-official-chrome-os-pc-t3865697

Really happy with my Chromebook!!! :) :) :)

@pitiso
Copy link

pitiso commented Mar 9, 2019

I managed it finally by applying this tutorial:

https://forum.xda-developers.com/hardware-hacking/chromebooks/guide-installing-official-chrome-os-pc-t3865697

Really happy with my Chromebook!!! :) :) :)

kiwisibk, can you please share wich chromiumos.img, recovery, and caroline/TPM versions you used?

@kiwisibk
Copy link

kiwisibk commented Mar 9, 2019

Arnoldthebat special build V72 x64
Eve.bin
Caroline.bin

Deleted via GParted USB Live Stick Partition 5 and enlarged Partition 3 from 2 to 4 GB.

Then applied the above linked tutorial.

Good luck!! 😉

@pitiso
Copy link

pitiso commented Mar 10, 2019

Arnoldthebat special build V72 x64
Eve.bin
Caroline.bin

Deleted via GParted USB Live Stick Partition 5 and enlarged Partition 3 from 2 to 4 GB.

Then applied the above linked tutorial.

Good luck!! 😉

Thanks kiwisibk, you gave me energy to to for it one last time... I tried so many different combinations and methods. It's working now like a charm though!

@kiwisibk
Copy link

Happy that it worked for you!! 😊

Believe me, I had the same odyssey... 😬😄😄

@elkinsja0419
Copy link

I took a slightly different approach after many failed attempts. My partitions were setup basically the same as everybody in this thread. This what they look like after.
Device Start End Sectors Size Type
/dev/sda1 9097216 1465149134 1456051919 694.3G Microsoft basic data
/dev/sda2 20480 151551 131072 64M ChromeOS kernel
/dev/sda3 716800 9097215 8380416 4G ChromeOS root fs
/dev/sda4 151552 282623 131072 64M ChromeOS kernel
/dev/sda5 708608 716799 8192 4M ChromeOS root fs
/dev/sda6 16448 16448 1 512B ChromeOS kernel
/dev/sda7 16449 16449 1 512B ChromeOS root fs
/dev/sda8 282624 315391 32768 16M Microsoft basic data
/dev/sda9 16450 16450 1 512B ChromeOS reserved
/dev/sda10 16451 16451 1 512B ChromeOS reserved
/dev/sda11 64 16447 16384 8M unknown
/dev/sda12 446464 708607 262144 128M EFI System

  1. Created live boot USB using most recent versions of ATB Vanilla, Caroline, Eve, and Cromefy.sh.
  2. Booted up using Live USB, in my case USB=sdb and HDD=sda
  3. Deleted all partitions. I used Lubunutu, also from a Live Boot. I believe you could also use
    sudo dd if=/dev/zero of=/dev/sda
  4. Copy sdb to sda using
    sudo dd if=/dev/sdb of=/dev/sda
    sudo fdisk -l # Just to make sure the partitions match.
  5. Deleted sda1 and recreated using fdisk. Don't think this was actually necessary.
  6. Fixed Grub
    curl -L https://goo.gl/HdjwAZ | sudo bash -s /dev/sda
  7. Reboot and remove USB
  8. Powerwash from the settings menu. This will delete all user data and update to the newest version on the stable channel.
  9. Now in Chromebook with functioning Play Store and using most current OS version.

I hope this helps somebody else.

@Masterioda
Copy link

Many thanks, this worked for me, even without running the fixed Grub script nor the powerwash !
I just changed the size of sda partition to occupy the full sdd free space.

@Masterioda
Copy link

Only thing now... media keys are not at their place... (mapped to standard chromebook places)
and track pad acting like a mouse (no multi point, no scolling.......) if anyone has an idea, it is welcome !

@Masterioda
Copy link

media keys are ok now... But still no multipoints gestures using the trackpad. I'm using a HP Spectre x360 i7

@4ft35t
Copy link

4ft35t commented Jun 8, 2019

I was able to fix the problem for myself by the following

  1. creating a usb device using method 1
  2. booting the usb device
  3. remounting the / folder (for me it was device /dev/sdb3) so it would be writable
    sudo mount -o remount,rw /dev/sdb3 /
  4. openingthe write_gpt.sh file to change the partition size
    sudo vi write_gpt.sh
  5. went to line 119 (use :set number if you want to see line numbers) the line is 4 lines above the one where it writes partition 12 so you can search for "add -i 12" or "EFI-SYSTEM" and go 4 lines up to the one you need to modify to update the size
    it should look like
    blocks=$(( 33554432 / block_size ))
  6. changed to a better size for partition 12 (i used 134217728 it ended up being a bit oversized but only by a few bytes) if you dont know how to use Vim this might give you a headache
    it should look like
    blocks=$(( 134217728 / block_size ))
  7. saved the file
  8. installed using chromeos-install as per normal

this resulted in me booting without having to run any fix grub scripts.

i dont seem to know why the chromefy image has a larger EFI directory than the chromium installer expects, is the chromefy script changing the size of partition 12?

Works for me. Thanks.

@abdelmksoud
Copy link

Hi campbebj, i tried your solution but when i write the second command " sudo vi write_gpt.dh " it shows black screen with " new file " in the end. Could you please help me

@campbebj
Copy link

that means you weren't in the right folder, i'm not sure now which folder you need to be in, but there is an existing file called write_gpt.dh and you'll need to find it. and then once you're in the folder with that file then try the command.

@abdelmksoud
Copy link

Thanks campbebj, i found the location and modified the file and it is working now. for people like me, the file location is /usr/sbin. just write the following commands :

sudo mount -o remount,rw /dev/sdb3 /
cd /usr/sbin /
sudo vi write_gpt.sh

it will open the file and once opened write this command and click enter :

:set number

it will show line numbers, go to line 119 and follow campbebj instructions above.

Thanks again campbebj, i finally got chromebook. 👍

@ZDTaylor
Copy link

Another confirmation for @campbebj's answer

@dragon788
Copy link

i dont seem to know why the chromefy image has a larger EFI directory than the chromium installer expects, is the chromefy script changing the size of partition 12?

I believe the reason might be that Chromefy has to store a bit more information in that partition, especially to include Grub's .efi files and if you are dual booting possibly other files as well. ChromeOS uses a much slimmer boot process called depthcharge that takes little space, and previously it used U-Boot and SeaBIOS.

@dragon788
Copy link

@campbebj you are my hero, although I had to hack the write_gpt.sh script a little further to get it to work properly, I stood on the shoulders of giants.

The trouble I'd run into was even with the tweak to the EFI partition, it didn't want to boot properly. After looking at the chromeos-install output from another run I figured out why. For whatever reason the write_gpt.sh script is also NOT creating the ROOT-A or ROOT-B partitions as 4GB, which is a problem given the fact that on a pretty much perfectly fresh system after I tweaked the sizes, I had 2.2GB used in / aka the root partition...

To be fair this isn't entirely an issue with Chromefy, as from what I can tell the write_gpt.sh script actually gets generated at "build" time when the ArnoldTheBats or any other image first gets created, and it uses a fairly default partition layout for ChromiumOS/ChromeOS, which would work if Chromefy weren't dropping extra stuff into the root from the ChromeOS image.

I like having one-liners or copy and paste-able snippets, and I may end up having to put this fix into a gist or similar so I can just curl and run it easily until the Chromefy script maybe incorporates tweaking the write_gpt.sh that exists in the image.

On the ArnoldTheBat images (and maybe in Dev Mode in general) you can login with chronos and sudo everything, or you can just login as root and not have to call sudo all the time. I'm assuming you like typing less and use the root option for the commands below.

mount -o remount,rw /dev/sdb3 / && \
sed -i -e's/33554432/134217728/' -e's/2147483648/4294967296/' /usr/sbin/write_gpt.sh && \
chromeos-install --dst /dev/sda --skip_postinstall

This has done the trick for me, and luckily after doing it to the Chromefy USB the change stays in place (at least until I drop a newer version into the stick, which I haven't tested yet), so I can simply copy the USB using dd to another USB if I want to make a backup that includes my customizations/fixes.

I actually never knew that there was a really nice message at the end of the installer, because I had never gotten to that point previously.

@akrajilwar
Copy link

I was able to fix the problem for myself by the following

  1. creating a usb device using method 1
  2. booting the usb device
  3. remounting the / folder (for me it was device /dev/sdb3) so it would be writable
    sudo mount -o remount,rw /dev/sdb3 /
  4. openingthe write_gpt.sh file to change the partition size
    sudo vi write_gpt.sh
  5. went to line 119 (use :set number if you want to see line numbers) the line is 4 lines above the one where it writes partition 12 so you can search for "add -i 12" or "EFI-SYSTEM" and go 4 lines up to the one you need to modify to update the size
    it should look like
    blocks=$(( 33554432 / block_size ))
  6. changed to a better size for partition 12 (i used 134217728 it ended up being a bit oversized but only by a few bytes) if you dont know how to use Vim this might give you a headache
    it should look like
    blocks=$(( 134217728 / block_size ))
  7. saved the file
  8. installed using chromeos-install as per normal

this resulted in me booting without having to run any fix grub scripts.

i dont seem to know why the chromefy image has a larger EFI directory than the chromium installer expects, is the chromefy script changing the size of partition 12?

Works for me 👍

alesimula added a commit that referenced this issue Dec 24, 2019
@pxsepulv
Copy link

pxsepulv commented Jun 3, 2020

@campbebj you are my hero, although I had to hack the write_gpt.sh script a little further to get it to work properly, I stood on the shoulders of giants.

The trouble I'd run into was even with the tweak to the EFI partition, it didn't want to boot properly. After looking at the chromeos-install output from another run I figured out why. For whatever reason the write_gpt.sh script is also NOT creating the ROOT-A or ROOT-B partitions as 4GB, which is a problem given the fact that on a pretty much perfectly fresh system after I tweaked the sizes, I had 2.2GB used in / aka the root partition...

To be fair this isn't entirely an issue with Chromefy, as from what I can tell the write_gpt.sh script actually gets generated at "build" time when the ArnoldTheBats or any other image first gets created, and it uses a fairly default partition layout for ChromiumOS/ChromeOS, which would work if Chromefy weren't dropping extra stuff into the root from the ChromeOS image.

I like having one-liners or copy and paste-able snippets, and I may end up having to put this fix into a gist or similar so I can just curl and run it easily until the Chromefy script maybe incorporates tweaking the write_gpt.sh that exists in the image.

On the ArnoldTheBat images (and maybe in Dev Mode in general) you can login with chronos and sudo everything, or you can just login as root and not have to call sudo all the time. I'm assuming you like typing less and use the root option for the commands below.

mount -o remount,rw /dev/sdb3 / && \
sed -i -e's/33554432/134217728/' -e's/2147483648/4294967296/' /usr/sbin/write_gpt.sh && \
chromeos-install --dst /dev/sda --skip_postinstall

This has done the trick for me, and luckily after doing it to the Chromefy USB the change stays in place (at least until I drop a newer version into the stick, which I haven't tested yet), so I can simply copy the USB using dd to another USB if I want to make a backup that includes my customizations/fixes.

I actually never knew that there was a really nice message at the end of the installer, because I had never gotten to that point previously.

I'd like to have more details about how to do this solution, if it's possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
known bug Something isn't working and that is already been fixed
Projects
None yet
Development

No branches or pull requests