03-20-2025, 01:52 AM
(This post was last modified: 03-20-2025, 04:34 AM by macmartin.
Edit Reason: a bit more details
)
the last one didn't cut it.
I was not successfull transfering files via UART/serial from u-boot using minicom. There are some things I don't understand yet (how to load a file into memory and where to find/how to get the "loadaddress" and find the destination to send it via kermit/ymodem *shrug*
I went the rdeveloptool route and used that also as a chance to backup all the partitions (see https://github.com/PNDeb/pinenote-debian...ion_tables) (except the data partition, thats a bit much).
So after I transferred the os1 partition from the PN to my notebook (linux/debian-based), I mounted it via `sudo mount -o loop part_os1.img /tmp/some_dir_you_have_to_create_first` - then I was able to put "user" back into the "sudo" group (via editing `/etc/group`) and optionally removing the passwords from `/etc/shadow`).
After un-mounting (`sudo umount /tmp/some_dir...`) I put that partition back to the device and I was able to login.
So now I can fix the crapped update and have a better idea how to investigate those regular unsatisfying reboots in the future
(and yes, I did note the password down directly after setting it to not get some phonecall or whatever in the way. but just to be sure, it's: ***********
)
cheers
I was not successfull transfering files via UART/serial from u-boot using minicom. There are some things I don't understand yet (how to load a file into memory and where to find/how to get the "loadaddress" and find the destination to send it via kermit/ymodem *shrug*
I went the rdeveloptool route and used that also as a chance to backup all the partitions (see https://github.com/PNDeb/pinenote-debian...ion_tables) (except the data partition, thats a bit much).
So after I transferred the os1 partition from the PN to my notebook (linux/debian-based), I mounted it via `sudo mount -o loop part_os1.img /tmp/some_dir_you_have_to_create_first` - then I was able to put "user" back into the "sudo" group (via editing `/etc/group`) and optionally removing the passwords from `/etc/shadow`).
After un-mounting (`sudo umount /tmp/some_dir...`) I put that partition back to the device and I was able to login.
So now I can fix the crapped update and have a better idea how to investigate those regular unsatisfying reboots in the future
(and yes, I did note the password down directly after setting it to not get some phonecall or whatever in the way. but just to be sure, it's: ***********

cheers