5.10.139 is not available, but 5.10.147 as latest one of the v5.10 generation. So:
apt install linux-{image,dtb}-current-meson64=22.08.4
1 Like
Will try as soon as I could, thank you!
I never understood why they did that…a separate /boot partition (especially a small one in fat32) with a kernel that loads before the main / partition to help with fixing driver errors…if that one partition borks…it ALL borks
IT WORKED!!! YES!!
But… only if there are no HDD inserted. If I put them it doesn’t boot, maybe is something related with mount points??
I read some apt command to make updates but don’t update kernel packages, how I can do it?
EDIT: Well… it seems that also happens with the SD… Maybe it’s since I installed petitboot? Since I installed I didn’t try to boot with both HDDs inserted because I cannot mantain the SPI button with both HDDs…
when it hits that initramfs after the /scripts/init-bottom and can’t mount/run in those directories…it’s failed boot, the kernel initialized, but it can’t get any further
/dev/sda1 looks good, shows clean
At least you need to assure that there are no filesystems with same UUIDs on any two attached drives, e.g. if you flashed current DietPi to USB drive as well as to SD card, and both attached.
It looks like it found a drive, but the wrong one, as it does not contain an /sbin/init, which exists on all Linux images.
Sadly we cannot see whether petitboot did overwrite the UUID with /dev/sda1 here or not. Because with other HDDs (via SATA) attached, the USB drive may be /dev/sdb1 or different. petitboot falsely replaces UUIDs for SD card and eMMC for mainline kernel, so that it waits for an eMMC when told to boot from SD card and the other way round. So we added setenv rootuuid "true" to our /boot/boot.scr when booting via petitboot, which should disable this strange behaviour of petitboot (not sure why that exists at all), but I saw it not working in another case, while it does work well here on my Odroid N2+.
Can you input something into that initramfs prompt with a keyboard?
Yes I can now input anything on it.
I made the cat command you said me on GitHub.
Don’t know if it has sense now.
1 Like
Okay looks like either petitboot_active was not set or rootuuid was ignored. No idea why it would behave differently in this regards then on my N2+. I forgot the respective command, but can you check whether one of these prints the environment variables and show them?
env
printenv
fw_printenv
should it not say root=PARTUUID=somethingsomething on the boot line right before the rootfstype=ext4…the /dev/sda1 might not work
Also, is there a fsck.repair=yes option that should be in there?
does it show the /dev/sda1 mounted?
What does fdisk -l show?
or
ls -l /dev/disk/by-uuid
ls -l /dev/disk/by-label
Then try putting that root=PARTUID=somethingsomething and see if it finds the correct drive to run the os
This is the output, but that uuid does not correspond to sda1
The one to boot is sda1 with this uuid as petitboot shows
Well it sems that I have it working now. I’ll try my best to explain it…
The problem, is that is set to boot sda1 on usb, and when I put the first HDD is automatically mount it on sda1, and the second HDD on sdb1.
The error I was having, is that on the image I was making from the sd to flash it on the sdd, fstab file had mounted the 2 hdd as sda1 and sdb1, and when I flashed and boot it ,there was the error.
I unmounted first all hdd’s, check that on fstab I had only the sd, and then make the image, flash it, and boot without any hdd, just the ssd connected to the usb.
It boots fine, then I put one hdd and on dietpi-drive_manager I see is mounted to sdb1 because sda1 is with the ssd. I rebooted and then I see on petitboot that is sdb1 the system is going to boot. Surprisingly it boots, I checked what happened on drive_manager, and I see, that the hdd is mounted on sda1 and ssd on sdb1. I reboot to check and without a problem.
So maybe the 2 sata ports, are reserved to sda 1 and sdb1, and that was the problem??
I need to block now kernel updates, to avoid update it, and broke the ssd detection again.
EDIT: Talked to fast… Petitboot is messing up with which disk has to start… now it detects sda1 first(HDD) and it doesn’t boot…
This is why it’s best to use the UUID rather than the /dev/sdX1…because sometimes the system can do weird things and mount drives all willy nilly…if locked in with UUID…it will never change
Can petitboot use the UUID or PARTUID options
Searched and found it does ID the drive…but can’t differentiate between the basic labels if the kernel mounts them all janky
odroid-n2:os_images:petitboot:os_installation_using_otg [ODROID Wiki]
Have you seen this site?
odroid-hc4:odroid-hc4 [ODROID Wiki]
Have you seen this site?
odroid-hc4:odroid-hc4 [ODROID Wiki]
Yep but I don’t know where it is something related.
Same as my two of N2+ , It boots with SPI if i flash the image to microsd or eMMC but booting directly from SSD/HDD it’s another thing , So now booting from SPI (Dietpi) is pointless for most of odroid devices because no matter SPI or MMC makes no difference you cannot boot (dietpi) directly from SSD/HDD .
Since you can install and boot Debian directly from SSD with netboot_default then exit , You can try to convert debian to dietpi but i don’t think it will works .
I keep making tests, sda1 and sdb1 keeps swapping, like this ubuntu - sda and sdb keep on swapping - Unix & Linux Stack Exchange
I have set on petitboot, boot arguments, instead of selecting sdx putting the disk uuid, and on boot.ini rootdev equal to uuid. But no changes…
Another thing that happens is that when it boots fine, after a time system hungs… and became unresponsive. The first time it happened the blue and red lights where on, the second just the red.
A bit frustrating…
Our /boot/boot.scr indeed sets the root= argument to the filesystems UUID to work with eMMC, SD card and USB the same way. But petitboot by default, for whatever crappy creason…, replaces this with a /dev/* line. I thought this would only cause issues with SD card and eMMC, since it replaces the line falsely to wait for an eMMC, when the rootfs is actually on SD card, and the other way round. This is since Hardkernels ancient vendor kernel has /dev/mmcblk0 and /dev/mmcblk1 swapped compared to mainline kernel. But if it even replaces it with /dev/sda1 even that the rootfs is on /dev/sdb1, then petitboot is more destructive and dumb than I thought.
However, we actually disable this misbehaviour via setenv rootuuid "true", as mentioned, which works well on my N2+. But it seems on your HC4 this does not work. Please try the following:
In your /boot/boot.cmd, the setenv rootuuid "true" is located within a if test "${petitboot_active}" = "1"; then block. Possibly, this petitboot_active variable is for some reason not set in your case. Remove that condition so that
if test "${petitboot_active}" = "1"; then
setenv fdtfile "amlogic/meson-sm1-odroid-${variant}.dtb"
setenv rootuuid "true"
fi
becomes
setenv fdtfile "amlogic/meson-sm1-odroid-${variant}.dtb"
setenv rootuuid "true"
Then recompile the boot.scr from it:
mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr
Ah, do you have a way to do that e.g. booting the system via SD card with that USB drive attached? I can also generate new images with this condition removed. It doesn’t hurt to set those to variables even when booting via mainline U-Boot.
I have changed it, and it boots fine, but maybe is because all the changes I made before…
Also the test of booting with the sd inserted, failed, it isn’t detected as a bootable system.
EDIT: Can I erase petitboot and this would be “working”?
You mean with a freshly flashed SD card, and USB device and eMMC removed, it does not boot from there? Similarly bad. Of course, erasing petitboot is otherwise the mandatory step, but I was actually hoping that our changes allow boot via petitboot, regardless whether from USB or SD card or eMMC. Before erasing petitboot, test first holding the MASKROM button. Probably something else went wrong.
To flash mainline U-Boot to SPI, which should enable reliable USB boot:
apt install linux-u-boot-current-odroidhc4
source /usr/lib/u-boot/platform_install.sh
write_uboot_platform_mtd "$DIR"
Interesting would be however whether a fresh image with above change in boot scripts only boots from USB as well with petitboot.
1 Like
No sorry, I thought with the used sd.
Will try.
I think I know why it swaps sdx mounting points at boot. If I reboot because the hdd is already spinning, is detected earlier, and it gets sda1 mounting point, but when it starts from poweroff ssd from usb gets sda1…