Replies: 9 comments 2 replies
-
|
I will try to replicate your setup. |
Beta Was this translation helpful? Give feedback.
-
|
/dev/sda7 -- the BATOCERA shared partition was only partially expanded to
116G of what was around 124.xGB available. Does what you say mean that
PINN partially expanded the partition -- I think not, based on
reviewing the batocera partitioning json the batocera boot partition was
identified by the json as 22xxM and the allocated batocera boot partition
is 3.2G (approaching 33% larger). So something possibly the batocera
installer is altering the partition setup appears to have expanded the size
of the first partition that would alter the starting point and size of the
second batocera partition that in this case did not expand to use the whole
amount of the space intended for the partition.. I am not sure what is
responsible for the partial expansion of the second batocera (shared)
partition. I have a feeling it was probably not PINN.
Thanks for checking out the other thing where RasPI Bullseye/32 appears to
be corrupting the partitions allocated to eventually or actually contain
RasPI Bookworm/32 & /64.
…On Mon, Dec 23, 2024 at 6:28 PM procount ***@***.***> wrote:
I will try to replicate your setup.
One point to note is that you should not normally have to worry about
partition expansion scripts. The scripts assume a minimal size image which
needs to be expanded to fill the drive. PINN already provides a fully
expanded partition, into which it copies the file. so the script is
redundant. The error is because the script wants to expand the partition to
fill the whole drive, but it can't because of the other OS partitions.
—
Reply to this email directly, view it on GitHub
<#860 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXK6IIVNZETW4FAGCMHIXD32HCMCBAVCNFSM6AAAAABUDOTVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVGM4TSNY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I have answered your Batocera issues on the other Batocera github issue. |
Beta Was this translation helpful? Give feedback.
-
|
I think I recall something similar happening before. Please forget about partition expansion. It is only required for raw images, which are not relevant here. PINN creates a fully expanded partition and then copies the files from a tarball into it. I used to try and remove any expansion scripts during the conversion, but finding them is not always easy and they generally fail gracefully anyway, |
Beta Was this translation helpful? Give feedback.
-
|
The corruption problem is due to a bug in the initialization scripts in Bullseye (Some lines were removed which meant it no longer catered for multi-boot scenarios). This causes Bullseye to run parted that changes the diskID, so Bookworm (and maybe other installed OSes) can no longer find its root partition. It probably only occurs on USB installations. This was subsequently fixed in Bookworm. |
Beta Was this translation helpful? Give feedback.
-
|
I have updated all the Legacy Raspios Bullseye installations to avoid this in future. To manually fix this without a full reinstall, you would need to restore your original DiskID and modify installed_os.json. |
Beta Was this translation helpful? Give feedback.
-
|
I admitted I was wrong there too and closed the issue,.
…On Tue, Dec 24, 2024 at 4:33 AM procount ***@***.***> wrote:
I have answered your Batocera issues on the other Batocera github issue.
—
Reply to this email directly, view it on GitHub
<#860 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXK6IIRHETGGTCA4BBA22W32HETAJAVCNFSM6AAAAABUDOTVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVGY4TOMQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's an easy mistake to make. These tools are not very consistent. |
Beta Was this translation helpful? Give feedback.
-
|
Reinstallation is probably still the cleanest; since I did a lot of
debugging on the current install.
Thanks for the prompt action.
…On Tue, Dec 24, 2024 at 1:53 PM procount ***@***.***> wrote:
I have updated all the Legacy Raspios Bullseye installations to avoid this
in future.
So, if you do a reinstall of everything it should now work without issue.
To manually fix this without a full reinstall, you would need to restore
your original DiskID and modify installed_os.json.
On your legacy bullseye OS, you would need to update the partuuids to
include the restored diskID in cmdline.txt and etc/fstab
—
Reply to this email directly, view it on GitHub
<#860 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXK6IIUJSEPHNF3C5WSBYKT2HGUQ3AVCNFSM6AAAAABUDOTVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVHE4DCMQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Patching this leads to possible questions about the appropriateness of the
patches. I will do a fresh install. Do you need the info you requested
for debugging purposes or just to guide my recovery? If it is just for my
recovery then as stated a fresh install will eliminate any possibility that
I did not patch the issues correctly. Thanks again for the quick response.
…On Tue, Dec 24, 2024 at 7:02 AM procount ***@***.***> wrote:
The corruption problem is due to a bug in the initialization scripts in
Bullseye (Some lines were removed which meant it no longer catered for
multi-boot scenarios). This causes Bullseye to run parted that changes the
diskID, so Bookworm (and maybe other installed OSes) can no longer find its
root partition. It probably only occurs on USB installations. This was
subsequently fixed in Bookworm.
To fix this, I need to backport the changes into the Bullseye installation.
If you don't want to do a complete re-installation of everything after I
have updated Bullseye, it is possible to fix this manually, but I'd need
the diskID and /settings/installed_os.json files.
An easy way to provide this information is to follow step 6 of the
troubleshooting <https://github.com/procount/pinn/wiki/Troubleshooting>
section on my wiki and post the log here.
—
Reply to this email directly, view it on GitHub
<#860 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXK6IIWZJRIKAYN3QNMEJGL2HFEMPAVCNFSM6AAAAABUDOTVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVG44DAMY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You nailed it; problem solved I did the complete reinstall. I have a
remaining problem to find that expantion script in batocera that runs every
boot it seems throwing out that expansion message. This is probably not
your problem.
it appears that this may be that answer:
Edit the batocera-boot.conf and comment (#) autoresize=true
Thanks again,
…On Tue, Dec 24, 2024 at 7:09 PM David Shuman ***@***.***> wrote:
Patching this leads to possible questions about the appropriateness of the
patches. I will do a fresh install. Do you need the info you requested
for debugging purposes or just to guide my recovery? If it is just for my
recovery then as stated a fresh install will eliminate any possibility that
I did not patch the issues correctly. Thanks again for the quick response.
On Tue, Dec 24, 2024 at 7:02 AM procount ***@***.***> wrote:
> The corruption problem is due to a bug in the initialization scripts in
> Bullseye (Some lines were removed which meant it no longer catered for
> multi-boot scenarios). This causes Bullseye to run parted that changes the
> diskID, so Bookworm (and maybe other installed OSes) can no longer find its
> root partition. It probably only occurs on USB installations. This was
> subsequently fixed in Bookworm.
> To fix this, I need to backport the changes into the Bullseye
> installation.
> If you don't want to do a complete re-installation of everything after I
> have updated Bullseye, it is possible to fix this manually, but I'd need
> the diskID and /settings/installed_os.json files.
> An easy way to provide this information is to follow step 6 of the
> troubleshooting <https://github.com/procount/pinn/wiki/Troubleshooting>
> section on my wiki and post the log here.
>
> —
> Reply to this email directly, view it on GitHub
> <#860 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AXK6IIWZJRIKAYN3QNMEJGL2HFEMPAVCNFSM6AAAAABUDOTVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVG44DAMY>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
This current install us using a RASPI 3 an 256G SSD drive in a USB enclosure and PINN 3.9.2
The BATOCERA item was reported here:
[https://github.com/batocera-linux/batocera.linux/issues/13102]
This is the third attempt at this install the first two used PINN 3.9.3. I created a successful install on a 64GB SD card without BATOCERA, but when I wanted 32GB partitions for RasPI Bullseye/32 and RasPI Bookworm/32 & /64 I tried using a 256GB ssd drive addiing a 128GB BATOCERA OS. BATOCERA as noted in another issue has an expansion problem on the userspace ext4 partition. BATOCERA does not appear to be the problem with the RASPI OS installs based on the second and third attempt to create this environment.
Each attempt starts with PINN installing BATOCERA, RASPI Bullseye/32, Data, ProjectSpace1 and ProjectSpace2. I believe I replaced RasPI Bookworm/32 & /64 into ProjectSpaces1 & 2 respectively. I initially booted BATOCERA (amd probably got the /tmp/resize.log message) I did not resolve the issue at that time. I did the initial boot of RasPI Bullseye/32, no problems. Both RasPI Bookworm/32 & /64 halted in busybox if I am correct, the web pages I saw indicates that the install was probably faulty, tried to reload the OSes and was blocked with an error "Cannot reinstall/replace raspios-arm?? partition is not big enough for new image".
Attempt 2 reverse the boot process; I still install the same 5 items initially. This time I first replace Bookworm/64 into ProjectSpace2, perform initial boot of RasPi Bookworm/64 and reboot RasPI Bookworm/64 -- all successful. I then replace RasPI Bookworm/32 into ProjectSpace1 following the same process as RasPI Bookworm/64 -- success. One additional test reboot RasPI Bookworm/64 to assure it still worked -- success. Next I perform the first boot of RasPI Bullseye/32 (already loaded) and a following reboot -- success. Then attempt to reboot RasPI Bookworm/32 and RasPI Bookworm/64 -- failure for both I am being dropped into busybox again. This I believe is a possible indication that the RasPI Bullseye/32 initial boot is altering the RasPI Bookworm/32 & /64 partitions.
Attempt 3 bypass BATOCERA until last, I still install the same 5 items initially. Switching PINN's 'reserve' for the proper command 'provision' fixed the earlier partition allocation discussion item. I performed the first boot of RasPI Bullseye/32 -- success and the reboot of RasPI Bullseye/32 succeeded. After that boot of RasPI Bullseye/32; ProjectSpace1 would not accept replacement by RasPI Bookworm/32 and ProjectSpace2 would not accept replacement by RasPI Bookworm/64. Both eliciting the error "Cannot reinstall/replace raspios-arm?? partition is not big enough for new image".
Unfortunately the reports below are after the first boot of BATOCERA that followed all the above; if necessary, I can rebuild and redo the testing without the first BATOCERA boot. I also activated SSH and VNC in RasPI Bullseye/32 because it makes assembling this data easier.
RasPI Bullseye/32 reporting
LSBLK reports the following (nothing unexpected):
FDISK reports the following (again nothing unexpected on my part):
The current 'df -h' output
/dev/sda6&7 are BATOCERA
/dev/sda8&9 are /boot & / respectively (RasPI Bullseye/32)
/dev/sda10 is data
/dev/sda11&12 are ProjectSpace1
/dev/sda13&14 are ProjectSpace2
all except /dev/sda7 appear to be fully expanded. The failure of /dev/sda7 to expand completely is another discussion.
One Item I am missing is the 'df -h' output after the initial PINN install. Should the /dev/sda12&14 ext4 partitions be fully expanded at this time before loading RasPI Bookworm/32 & /64 respectively. If I need to test again that is information I intend to gather, because I only know that presently they are expanded. Perhaps you can answer the question whether the error message is because the partitions were expanded too early? Another question is if they were expanded too early what triggered the expansion? Can I shrink the partition size allowing the replacement of the ProjectSpaces with their desired OSes from the current state or will I need to start over a 4th time? Starting over is not an unacceptable option. At this time there is nothing I cannot manually preserve from the current process.
PINN Configuration
Reviewing issue #391 which shares the same error message I am including the following answers.
#391
I reviewed cat /settings/installed_os.json
I believe those are the expected values.
Beta Was this translation helpful? Give feedback.
All reactions