bedna

I'm no expert, but I think what you are talking about here is a function to keep the log in memory and write to disk at shutdown or at timed intervals to minimize writes to disk. I would assume it involves some kind of mount --bind at boot, but I honestly don't know. Please create an issue on the github and continue conversation there if you still think this is something the script is responsible for, and by doing so, please follow the instructions in my previous post here on the forum. As for the "keep the script quiet", sure, make a feature request on the ghub and I'll look into it, does not sound to complicated to fix for you tbh.

Please create an issue on the github providing the logfile and describe your workflow in detail. Make sure the script is up to date, because I think in the past, hdd.log WAS excluded by default. Also provide an example run and show the file is missing by creating a fresh backup, use the `--loop` function of the script and then mount the loop and run ls to show the file is missing. Even if the directory is in ram or similar, and not excluded, it should be in the backup img. Edit. Oh, I see the claim is the file is missing AFTER the autoexpansion, well.. Please still do the original request so there are logs to study. (run the script and include the -l option) If it actually gets removed in the expansion, we have to look deeper into it, because the autoexpansion is made by using armbians systemd autoexpansion. Edit 2 Could also be interesting to see if the file "survives" if you include the -e option, ie do not autoexpand on boot.

Found the login credentials, lets continue on the github where we started. Might as well make the disclaimer here too. The "original" Bedna has passed, I as an extremely close relative have taken over. (Bedna actually came from "Big Edna" a character in the Weird Al movie UHF and we kinda shared that username, twins you know) All credentials for his accounts has been passed on to me so his spirit will live on in shrink-backup. There are TONS of documentation left behind. Please do not make a thing about it. I just wanted to let ppl know that this is still in good hands and will continue to be supported if bugs are found and if changes are needed to be made. But as for getting it into armbian as armbian-backup will have to take a step back. He started with things, but if I do that, it is better to start from scratch again, and my time is a bit limited...

Yes, I am working on that. Whiptail is what I am educating me in closer right now. But it will most likely be it's own script. Trying to implement the script straight up I think would become messy pretty fast, and I don't think anybody is interested in that. But yes, it is happening, sometime.. xD I was honestly hoping it would already be a reality, but my health keeps putting up roadblocks for me.

Try again Thank you! Op now updated to reflect current version.

I am not sure why I do not get email notifications when posts are made here, I thought I fixed that... (lmao, I just realized I had for some reason unclicked "follow topic") Thank you so much, both of you for your feedback! ------------------------------------------------------------------------------------------------------- shrink-backup v1.2 released As per usual, I can not change OP so for full and updated information please visit https://github.com/UnconnectedBedna/shrink-backup A smaller release this time. Added curl install method for users that prefer to have application and configs files in a static location, please see wiki Various QOL updates regarding the interface Bug fixes Thank you for using shrink-backup!

Late to the party... Yes. https://github.com/UnconnectedBedna/shrink-backup - Make a working install - Make an img with shrink-backup - "burn" that img and use on another device Note that the UUID:s will ofc be the same on both systems.

Please see this post (last post in the thread) and tell me if you need/want something from me... After running the update from 6.1 > 6.6 it freezes at boot. I have access to backup img:s from before this update is ran.

@going Interesting.... update-initramfs: Armbian: Symlinking /boot/uInitrd-6.6.31-current-sunxi64 to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-6.6.31-current-sunxi64' update-initramfs: Armbian: done. Remove unused generated file: /boot/initrd.img-6.1.63-current-sunxi64 Remove unused generated file: /boot/uInitrd-6.1.63-current-sunxi64 Armbian: update last-installed kernel symlink to 'Image'... '/boot/Image' -> 'vmlinuz-6.6.31-current-sunxi64' Armbian: Debian compat: linux-update-symlinks install 6.6.31-current-sunxi64 boot/vmlinuz-6.6.31-current-sunxi64 I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.6.31-current-sunxi64 I: /initrd.img.old is now a symlink to boot/initrd.img-6.6.31-current-sunxi64 I: /vmlinuz is now a symlink to boot/vmlinuz-6.6.31-current-sunxi64 I: /initrd.img is now a symlink to boot/initrd.img-6.6.31-current-sunxi64 Armbian 'linux-image-current-sunxi64' for '6.6.31-current-sunxi64': 'postinst' finishing. I wiped the sd-card, but I have access to a backup to before running this update.. You guys need/want something from me?

Yeah, I didn't react to the comment about if I was using bullseye, I was 100% sure I had a bookworm img installed, but that might not be the case, I must have dreamt I installed the only opiPC2 img I had downloaded on my computer. WDYM? I updated that system at least once a week up until it no longer worked. Worked flawlessly up until I made the post. Thank you for providing feedback, but I will reinstall with the latest community img and see what that leads to.

Yeah, I didn't react to the comment about if I was using bullseye, I was 100% sure I had a bookworm img installed, but that might not be the case. Thank you for providing feedback, but I will reinstall with the latest community img and see what that leads to.

Oh crap! I missed these repliess, I must make sure to activate email notification, I'm sorry! I honestly just left it unupdated, it's not a huge issue for me, I don't really use it for other than testing a script. The img it was installed from was "Armbian_community_24.5.0-trunk.93_Orangepipc2_bookworm_current_6.6.18_minimal" and I am aware it IS a "community release", that's why I didn't put a massive amount of investigation. Close.. "bedna".. xD But yes, bedna is UID 1000, the ONLY sudo user. 1003 is a system user, no home, no login shell IIRC. Edit. I made a check, and it actually is supposed to have a home in /home/unifi (MY BAD.. xD unifi:x:1003:1003:System user for Unifi,,,:/home/unifi:/usr/sbin/nologin So that is on me, I probably forgot to use the --system option or smthn, it is not a big deal and most likely not connected to the network failing at boot anyway. And the zsh is just super strange, I never use it even though I know it comes with the img. (I now realize, the option in the installation is just selecting the shell, there is absolutely a zsh installed on the opi, I have just not noticed it) I will try with a fresh image and come back with results, when I get time... Edit 2: https://github.com/armbian/build/blob/2a2e609e3c5e55404759ea9a2cf010b268c2f356/lib/functions/compilation/packages/armbian-zsh-deb.sh#L49C3-L49C129 awk -F'[:]' '{if (\$3 >= 1000 && \$3 != 65534 || \$3 == 0) print ""\$1":"\$3" "\$6"/.zshrc"}' /etc/passwd | xargs -n2 chown -R Is the "culprit". In this situation it IS my bad as shown above, not sure what I did because the directory was not created, but the entry in /etc/passwd clearly exist. A solution would be to run [-d <user-home-path found in passwd> ], but tbh, babysitting at that level is imho a bit too far... This is on me.. But the system freezing at boot trying to connect to network, I will look deeper into.

==> shrink-backup 1.1 release <== With this release versioning is changed from x.x.x to x.x The most noticeable change is the UI with coloring. But small efficiency increases to the code has also been made. Support for dietPi and webmin. Also created a way to convert your systems ext4 filesystem into f2fs on the img file. Downside is f2fs can not be resized while mounted unlike with ext4 so the user have to manually expand the img to cover the entire storage medium manually before booting. Increasing size while updating the img is also not yet covered, but should be doable so this feature will be implemented in a future release. A loop function to retry 3 times after looping the img file within the script has been implemented because bug reports started coming in about the UUID on the loop not being found, therefore failing the backup. Giving the system some time seems to resolve the issue. This seems to be related to if img file is located on a network storage. Usually, but not always, wifi network. Features in the release: UI improvements in form of coloring and other formatting New funcionality: --f2fs convert ext4 on root into f2fs on img file Added support for f2fs Added support for DietPi Added support for webmin --version option added Added .gitignore to github repo for users that change exclude.txt and want to use git pull without issues. Thank you for reading.

I ran an update on my orangpi PC2. Setting up armbian-zsh (24.5.1) ... cp: cannot create directory '/home/unifi/.oh-my-zsh': No such file or directory cp: cannot create regular file '/home/unifi/.zshrc': No such file or directory chown: cannot access '/home/unifi/.oh-my-zsh': No such file or directory chown: cannot access '/home/unifi/.zshrc': No such file or directory Witch is to be expected to fail, because that is a system user I accedentally gave an above 1000 UID Unifi is UID 1003, my regular user bedna (1000) is the owner of /home/bedna I don't mind, I don't use zsh anyway, but figured you would want to know about this. Edit I spoke to early, the update actually breaks the system. Seems to be network related because it gets stuck at that if I connect a display to the device. I have restored a backup and retried 2 times, same thing, so there is presumably something wrong on your side here. This is what the terminal gave during the update, and as you can see, it looks like it all goes smooth, something in the firmware or kernel?

Except what? You open up a flood door like that, you have to explain to op and hold his hand in how to find out what different users/groups are supposed to own different files. And since I have no idea what op has installed on his system, and how he did it, and what user he was when he did (sudo and root is NOT the same) I recommend op reinstall and do everything the correct way. Example from a system with docker running, nothing out of the ordinary. 3 cointainers the correct way, user in docker group and never using sudo with docker. $ sudo find . -group root -printf '.'| wc -c 153 153 files/directories just for root inside ~/. And this is only a quick search for root group, there are obviously other users and groups owning a whole bunch of stuff too. Probably a GREAT idea to "sudo chown -R 1000:1000 ~/"... Remember, op stated: And this is just an example of what can happen. Blows my mind an armbian admin thinks blindly taking ownership is a good idea... 😮

A friendly warning about doing above. MAKE SURE YOU DO NOT CHANGE OWNERSHIP OF FILES IN YOUR HOME THAT SHOULD STILL BELONG TO ROOT OR OTHER USERS/GROUPS!!!! As I stated before, just blindly changing everything in your userspace to belong to you MIGHT work, but I recommend against it since this seems to be something that happened immediately after you wrote the img. Safest way is to reinstall and follow the correct procedure.

Necro thread, but wanted to clarify since not mentioned. The raspberry pi imager does way more than just "write the img to the sd card". It is aimed for use with rpiOS not "any img file". Use something other than that.

Yes, use docker... xD I don't think there is any problem achieving that, I think it just takes a few entries in a docker-compose.yml where you set up the networking. Not multiple ip:s though, not sure how you would achieve that on anything, but you use different ports and define what can communicate with what, bridging and so on. With docker you have to open up, it is completely containerized by default, even between other docker containers on the same machine. Futher reading here: https://docs.docker.com/network/ And for docker compose: https://docs.docker.com/compose/networking/ I highly recommend you familiarize yourself with docker compose, it makes everything sooo much easier.

I do not know what software you use to create the virtual machine, but this is question for them to answer.

Using apt, sudo is needed, but you having to use sudo in your USERSPACE sounds like something has gone horribly wrong. AFAIK if you write an armbian image, then boot, log in with root and follow the installation script that should start (I think) it will ASK you to create your username etc and set up everything for you. You do NOT do the userconf.txt thing like you would do with a headless rpi setup, you log in as root and run the setup script. It sounds like you did not do that, so your userspace (your ~/) never got created correctly with correct credentials. Or maybe you did not reboot and login as your user after the script created your user, but instead kept running as root and setting everything up on your system, witch then means it is all owned by root (sudo is needed). If this is the case, yes, you can take ownership easily by using a few commands, but that might not solve everything. I would recommend you restart from scratch, making sure everything is set up correctly.

Since nobody mentioned it. I don't know what desktop env that is, but I think using those prefixes is not connected to the packages you get for installing for example cifs-utils. I more think this has to do with fuse or something similar. If you provide a bit more info of your system, more help might be provided by users. I have never used any graphical env on any of my armbian installs so I simply have no idea what is on them. 😮 It looks like gnome, so I think you can google using Ubuntu in your searches, and that might give you the solution of what you have to install. Never the less, you can always mount the share using `mount` in cli and they will become accessible that way.

Seems to be a kernel thing that has changed... Made me curious and I found this: https://forums.raspberrypi.com/viewtopic.php?t=325309 Obv not a solution for you since the tread is about rpi OS (but other hardware outside of rpi is actually mentioned). You might get some good info on how to move forward reading that. I do not know how to do this on armbian. Maybe you can use x11vnc (I have no idea if this exists in the repos) and set the resolution as described here (very old thread): https://stackoverflow.com/questions/12050021/how-to-make-xvfb-display-visible/40678605#40678605 Or maybe you can do the solution mentioned here, where you get a cheap usb > hdmi adapter for a few $$ that fools the SBC that it has a monitor connected.

==> shrink-backup v1.0 <== I have made the decision to not deal with other partitions than boot and root for the 1.0 release. Instead I introduced the --loop function to let the user expand the img file using the [extra space] option and then manually create partitions by running for example: sudo gparted /dev/loop0 in a terminal to edit partitions in a graphical interface using gparted. I want to give the user freedom, but I also have to stay true to my initial plan with this script: a very fast utility to create a bootable img file from the system and subsequently keep it updated. I haven't dropped the idea of at least handling /home completely, but the script goes from "kinda basic functionality" to "advanced script" pretty fast when I start working on the feature. If I do this, I still want the script to be as easy as possible to use, but at the same time give power users the ability to fine tune, ie a lot of work. Features in the release: Introduction of --loop, --fix & -z (zoom speed) Now crosschecks fstab with lsblk for certain operations. Changed MB to MiB etc. Old habits die hard. Will now, if needed, check and/or ask for installing gdisk on debian and arch based systems. GPT partition table now supported Various bug fixes. I hope you find it useful!

9 out of 10 times this is better to configure on your dhcp server, usually your router. Set a static ip on your router for the MAC adress on your board. WAY less headaches than starting configuring only the client. :)

The problem here I suspect is the sd-card got tear and wear, hence the capacity might drop, but if you ran a full dd of the entire card, the iso might become bigger than what fits on the sd-card (that now is a tiny bit smaller). It's not unusual that the cells are still readable but not writable, ie you can not modify the data. So when you create the img file, it is a complete one, but your card can no longer fit that img. Let me shamelessly invite you to use my little project: shrink-backup That way your img file becomes the size of the DATA on the device, not the entire thing. Then it will get re-expanded to use the entire sd-card when you boot it the first time after restoration. (if your os is supported, armbian is)