Jump to content

jba

Members
  • Posts

    22
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Finally found the better answer to my initial question. The process is described in the wiki: https://docs.armbian.com/User-Guide_Recovery/#flashing-boot-loader However, there is one mistake. Instead of the last line ~ $ bash pack/usr/lib/u-boot/platform_install.sh pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device you need to run ~ $ source pack/usr/lib/u-boot/platform_install.sh ~ $ write_uboot_platform pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device /dev/sdb In addition it is important to start the partition at block 8192 (at least for my odroid HC2, may be a differnet number on other devices). This way you can easily write your backups to an sd. Regards, Jürgen
  2. I am using an odroid HC2 as home NAS for some years now. Software is armbian/XU4 in debian flavour. At the moment I am running bookworm (which was updated from buster to bullseye and then to bookworm - I know its not supported but it worked fine. And the problem described here started only some month after the last update). Some days ago I wanted to reboot the unit but it was stuck in the boot process. Not available by ssh or any other services. I then found out that the boot stopped because my hard disk could not be mounted from ftsab (while the sd card as root file system could be mounted). After commenting out the line it boots normally. And when logged in by ssh I can mount the hard disk without any problem. As a workaround I put the "noauto" option in fstab and mount the drive after a sleep of some seconds from rc.local. That works fine but I am wondering what is causing the problem? Has something in armbian changed so that mounting on boot time doesnt work anymore? Maybe some problem with initializing the sata controller? Or is this a sign of degrading hardware? Any hints welcome. Juergen
  3. Hi bedna, I have to admit that I didnt look too deep in your script. This is mainly because my backaup strategy works now and is established for a lot of system, not only the odroid hc2. Therefore I dont want to change it. But maybe our misunderstanding is based on the terms image and files. For me you can backup on image level or on file level. There is no in-between. Of course you can mount an image and access the files, but its still a different thing. And taking an image-based backup of a running system is not a good idea in my opinion. > But restoring it is only possible on exactly the same type of sd, which will typically not be the case if you want to make a clone. You cited this sentence but removed the sentence before which is important. I was refering to a backup of the first 4 MB of a sd (and not your script). When you restore the first 4 MB to a different sd, you will delete the partition table. So at least you have to rewrite the partition table. But even then it didnt work for me. Did not find out the reason for that, maybe I did something else wrong. Regards, Jürgen
  4. Hi Bedna, this is not exactly what I was looking for. I regularly run backups via rsync - so it is on a file basis, not image. This allows me easily access old states for every file - just like timemachine. Jürgen
  5. Took me a while to find this out. Finally I found this threat that describes the procedure: Seems you have to write a vanilla image to your sd in order to get it bootable. After that you can delete all files and put your own backup on it. Important point is to then change the current uuid in boot/boot.ini (although it says you shouldnt). That worked for me. In many posts it is proposed to take a backup of the first 4 MB from your sd by dd. But restoring it is only possible on exactly the same type of sd, which will typically not be the case if you want to make a clone. I think this is because the first 4 MB do not only cover the u-boot, but also the partition table. So the partition/file system may be corrupted after writing the first 4 MB on a new sd. You have to recreate the partition table afterwards. But the system will not boot. Even when putting the right UUID in boot/boot.ini. Maybe fdisk is somehow corrupting the u-boot when writing the partition table. So I see no point in backing up the first block of the sd. It will help you only if you want to use exactly the same sd again. Regards, Jürgen
  6. I finally did the update. I used the same procedure as I wrote in the thread I linked in the first post. It worked without problems. However, in the last step nothing was updated. I think this means that the armbian repos for bookworm point to the same versions as for bullseye (kernel, dts, ...). I guess this will change soon. Only then I will get a new kernel. I hope this will not break the systems. Lets see. Jürgen
  7. I take regular backups from my linux boxes (rsyncing the file system). To resume, I boot from usb, copy the files to the disk of the box and then make it bootable by chrooting into the box and executing grub-install or update-grub. That works fine. But how can I do this on my odroid hc2 running armbian/bullseye? I cannot boot from usb. So I need to make the sd card bootable on my debian-amd64 pc after copying the files on it. Is there some command like "update-uboot" I can execute on amd64? Or do I need a virtual host running arm architecture to do so? Jüregen
  8. As bookworm is stable now I want to update my odroid HC2 from bullseye to bookworm? Any experiences welcome. I know this is not supported. But in principle it should work. I did the update from buster to bullseye and that worked perfectly (see link to threat below). I would just do the same for the new update. But maybe there is one special fact to remember that wasn't necessary for the last update. Jürgen
  9. I had the same problem on first boot (buster on HC2). Second boot worked. Didnt find out the reason for failure on first boot (suspectzed an error in ssh config, but that wasnt the case). Did you try a second boot with bullseye? jba
  10. You are right, as my /var/log is less than 75 % full this part of the script is not executed. So, what can I do with my "patch" (I know its trivial but it solves a problem that may exist on a lot of armbian systems)? Can I send it anywhere to get checked? jba
  11. Correct. The cleanup i done in /var/log/journal (at least thats how I understand the statement). Deletion of files is never propagated to /var/log.hdd/journal. In armbian-truncate-jobs maximum size of journal is 5MB. For journald it is defined as 20 MB. And a size of about 20 MB is what I normally see. I would expect it to be the lower value as in armbian-truncate-logs. Why is this not the case? There was a --delete in an older version, but for the complete /var/log. This wouldn't work with the other scripts as they interplay today. The --delete was removed 3 years ago. jba
  12. Now I have a solution that works. The hole thing seems extremely complicated to me. I did not find out all the tricks how logrotate, armbian-ramlog and maybe other functions work together. But the problem I had is now clear to me: Armbian copies current logs ad midnight from /var/log to /var/log.hdd. There they are rotated by logrotate. That works (at least for logs armbian is aware of). However, /var/log/journal (by journald) is not covered by logrotate. It does its own cleaning up in /var/log/journal. So /var/log.hdd/journal is keeping all the old files and gets bigger and bigger. On my system it increases by 10 MB per day. So after some days, /var/log.hdd gets bigger than 50 MB, which is the size of the ramdisk used for /var/log. Which becomes a problem on next reboot because then everything from /var/log.hdd is copied to /var/log which is too small. Therefore not all logs can be copied and get get lost in the end. My proposed solution is to do a second sync in syncToDisk to sync /var/log/journal to /var/log.hdd/journal and uses the --delete option. This way, everything that was deleted in /var/log/journal will also be deleted in /var/log.hdd/journal. Now, /var/log.hdd/journal grows no longer. Here is the patch: jba@lana:/lib/armbian$ diff armbian-ramlog armbian-ramlog.orig 56,62d55 < < # jba 2022-03-15 < ${NoCache} rsync -aXWv \ < --delete \ < --links \ < ${RAM_LOG}journal/ ${HDD_LOG}journal 2>&1 | $LOG_OUTPUT < This works fine on my system. What do you think about it? can it be incorporated in official armbian-ramlog? How can I post a bug report and proposal? jba
  13. I did some testing with overlayfs as described in the link. It worked fine but I also found out, that writing to the lowerdir (in our case the version on the sd) is not permitted by overlayfs. You can do so, it worked in a test, but its no guaranteed to work always. Seems it was designed for ro lowerdirs only: So it is not a good idea to use it this way. What could be done is having to directories on sd. One is used to hold the lowerdir and will not be changed while the ramdisk is mounted as an overlay. The other one (backup) holds the changes and is updated once per day and on shutdown. On next boot all files are copied from the backup to the lowerdir before the overlay is setup. However, the only benefit of this approach to the solution I now use (see below) is that we need a smaller ramdisk (as it only holds the changes) and safe some ram. What I did in the end is modifying armbian-ramlog so that all syncs are done with the option --delete *.gz, *.xz, '*.[0-9] are no longer excluded from the rsync Now log.hdd is an exact copy of log. Therefore the ramdisk needs be somehow bigger. I increased the size to 70 MB which seems to work. Any opinion on that? What about including it in the package? jba
  14. On my odroid hc2 with armbian/bullseye I found some of the logs (both in /var/log and /var/log.hdd) empty, while they should have some contens (i.e. afpd.log, kern.log, user.log, ...). The empty files all have the timestamp of a run of armbian-ramlog at a recent reboot. In armbian-ramlog.log I found this for the run that created the empty files: rsync: [receiver] write failed on "/var/log/journal/0d4b1c13b9a14b6d9c746402b7d7ef6f/user-1000@0005d37f46f9961b-23c015a66b68d086.journal~": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(378) [receiver=3.2.3] rsync: [sender] write error: Broken pipe (32) Seems that journal has become too big to fit on the log/ramdisk. That is strange, as I defined a maximum of 20MB for the journal and the ramdisk has 50MB. I guess this is what happened: When syncing to sd armbian-ramlog uses rsync without --delete. So if some older files have been already delete by journald (because of the 20 MB limit) on the ramdisk, they will still stay in the log on sd. Therefore the journal on the sd will become bigger and bigger. Which is not a problem because there is plenty of space on the sd. However, when rebooting everything is copied from the sd to the ramdisk. Including the bloated journal. Thus the ramdisk is full and additional files will not fit (see error message from rsync). I think in this case rsync just creates empty files and that is the reason for my empty logs. And on next sync the empty files are copied back to sd so both versions are empty. There is another potential problem I see in the implementation of armbian-ramlog: on reboot only recent files (so no *.gz or *.[0-9]) are copied to ramdisk. After som runtime logrotate will rotate the logs and create new *.gz or *.[0-9]. However, these might already exist on the sd. They will be overwritten when the logs are written back to sd. So you loose old logs. I think both problems are due to the fact that simple rsync is used without --delete and without copying even the old files to the ramdisk. To overcome these problems I see two ways: use rsync --delete and dont exclude *.gz and *.[0-9]. Then the ramdisk holds all logs and when copying to sd nothing is lost. But this may requier a bigger ramdisk dont use rsync but use an overlay fs instead. I found this discussion on the topic. The described solution looks superior to me than what we are using now: https://unix.stackexchange.com/questions/424341/mount-var-logs-as-tmpfs-with-help-of-overlayfs-to-save-changes-sometimes What do you think about it? Would it make sense to use an overlay fs? I am not that deep into linux hacking and therefore are not sure if I would be able to implement it in a nice way. But I would like to support this process and do some tasks. Regards, jba
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines