| agneli | very good morning :) or whatever your tz is | 07:03 |
|---|---|---|
| agneli | gnarface: since more or less 20 yrs using UUID was recommended because the drives might come in a different order even between reboots | 07:04 |
| agneli | idr exactly why, but that was due to drive initialization, order in which drivers load etc... | 07:05 |
| agneli | i missed the bit that your boot script is actually on emmc | 07:06 |
| agneli | but then I am not sure I understand your script | 07:10 |
| agneli | you have both kernels on emmc? | 07:10 |
| agneli | looks like one you have on the root of the 1st partition of your emmc | 07:10 |
| agneli | and the other in boot directory on the same drive/partition | 07:11 |
| agneli | is that correct understanding, please? | 07:11 |
| gnarface | agneli: yes, this has been a known issue for SATA drives for a while now, and i do believe there was some kernel change that started it, but i didn't think it matters for these mmc devices, but no i don't think you're picturing my drive layout quite right | 17:49 |
| gnarface | what i have is the boot script in /boot on partition 1 of the microSD and the rootfs is partition 2 | 17:50 |
| gnarface | the emmc also has a separate u-boot and boot.scr, a /boot for partition 1 of its own, and a rootfs as partition 2 | 17:51 |
| gnarface | at one point the emmc was older so it would be obvious, but then i tested that to be sure and discovered i'd it's the same version on both now, i must have updated. but that meant i couldn't tell if boot.scr from the emmc was actually booting the microSD. i hadn't considered it, but that was your theory and i realized i couldn't disprove it just based on those tests. | 17:52 |
| gnarface | i haven't tested further yet to be sure one way or another | 17:52 |
| gnarface | it had definitely happened that way at some point before so it's a valid theory | 17:55 |
| gnarface | but for the boot.scr on the emmc to be working for both that would mean they'd have to be changing order in some way with the new microSD but not the old one, which would mean if i edited the boot.scr on the emmc to point to the new microsd then it could no longer boot both as per your hypothesis of how it was currently working, so at that point i gave up | 17:59 |
| gnarface | i still wanted it to boot the emmc if there's no microsd present you see, and using the new microsd that way would prevent that | 17:59 |
| gnarface | er, actually no, it would mean they're changing order some way with the old microSD but not the new one, and that's why the new one doesn't work | 18:04 |
| gnarface | anyway, at some point i'll probably want to figure it out, but either way that now ruins the point of trying to swap these microSD cards | 18:08 |
| gnarface | because now either i won't be able to boot the emmc, or i won't be able to boot the new microSD, i'll have to pick one or the other, (or else learn how to make a much more complicated boot.scr, which may be possible in theory but is also currently beyond my skill) | 18:09 |
| gnarface | or i could do all that and find out that it's a red herring and the newer microsd won't work no matter what | 18:09 |
| * agneli will read it all and understand soon | 18:12 | |
| gnarface | (which would be weird because it was working fine in a different, related device, but still not impossible) | 18:12 |
| agneli | but seems you have a real complicated setup | 18:12 |
| gnarface | i don't think it's all that complicated i think i'm just bad at explaining it | 18:12 |
| agneli | I have some ideas but I will share once I study your fresh input | 18:12 |
| gnarface | basically there's some academic value in figuring out if you're right about this or not, but whether you are or not it means this microSD is probably not going to suit as an exact drop-in replacement of the old one so i'm aborting the mission because that was the primary goal | 18:13 |
| gnarface | my assumption was that the newer microsd would work identically to the old one in every way despite being half the size, so i could put the larger, older microsd in a completely different device. if that assumption isn't true then this mission has failed regardless of the specifics of why. | 18:15 |
| gnarface | i do appreciate your help though | 18:17 |
| gnarface | sorry we didn't actually make any progress | 18:17 |
| gnarface | anyway, it's a good theory, but looking now at /boot/boot.scr on the emmc i believe it's not true because it clearly says root=/dev/mmcblk2p2 | 18:21 |
| gnarface | and that boots fine while the microSD is not present | 18:22 |
| gnarface | the boot.scr on the microsd clearly has root=/dev/mmcblk0p2 on it | 18:23 |
| gnarface | so even if there's some sneaky order switching that allows both these cards to work on the emmc's boot.scr, it won't work anymore if i switch to the new microSD | 18:24 |
| gnarface | before i had update the emmc's u-boot install i was sure that isn't happening, but i hadn't considered the possibility it might happen with some microSD cards and not others | 18:25 |
| agneli | gnarface: 1. if your soc has a boot sector on emmc, and you have standard, unmodified u-boot, then your boot.scr on your sdcard is _never_ read imho | 20:14 |
| agneli | i recommed you add echo test_emmc and echo test_sdcard to respective *.scr files, if you have serial console then you will see easily | 20:16 |
| agneli | but iirc you do not, so jsut comment the boot line | 20:16 |
| agneli | so kernel does not overwrite u-boot output | 20:16 |
| agneli | then you will know for sure which one is booting | 20:16 |
| gnarface | agneli: no, note that this is NOT a pbp, it has a different hardware boot order. unlike the pro, it will absolutely try the microSD first | 20:16 |
| agneli | where is your boot sector please? | 20:17 |
| gnarface | i'm gonna test it eventually, but it definitely does at least try the microSD first, i know that for sure with this hardware. the pinebook pro internals have a different boot order because they're by a different cpu vendor | 20:17 |
| agneli | I believe this has nothing to do with hw where u-boot looks for the *.scr file | 20:18 |
| agneli | mine goes throug everything imaginable | 20:18 |
| agneli | eth, usb, gkw, etc | 20:18 |
| gnarface | well u-boot will look for boot.scr on the current disk, whatever it is | 20:18 |
| gnarface | but it is also an older u-boot build and possibly from before the necessary patches were mainlined | 20:19 |
| gnarface | my notes say i wrote the u-boot installs at the 8k address of each of their respective disks | 20:19 |
| agneli | so SoC does not have a predefined bootsector really? | 20:20 |
| agneli | it just choses microsd frist and emmc later looking for a bootsector? | 20:21 |
| agneli | how does it know that there is actually no usable code? | 20:21 |
| gnarface | it doesn't know without trying it | 20:21 |
| gnarface | i think it looks across a range on both | 20:21 |
| gnarface | but it tries the microSD first if present, then the emmc second. the pinebook pro models try the emmc first instead | 20:22 |
| agneli | let us say I will write SeXdUgSnRoCkRoLL many times at that adress on the sd card | 20:22 |
| agneli | how will SoC knows this is not a real code | 20:22 |
| gnarface | it may not know. there is a known issue where boot will hang if your u-boot is corrupted, and the recommended fix is to dd /dev/zero across it | 20:22 |
| agneli | how SoC with no firmware to analyze the code knows that there is a valid bootloader? | 20:23 |
| gnarface | i think it literally just tries to execute whatever is there | 20:23 |
| gnarface | afaik this is common for arm devices | 20:23 |
| gnarface | but it is weird | 20:23 |
| agneli | i have tegra2 and i have predefined bootsector devices on emmc | 20:24 |
| gnarface | that's a very fancy device though | 20:24 |
| agneli | carved out of the overal emmc space | 20:24 |
| agneli | so basicall if the bootsecotr on sdcard is crap it will just hang the device? | 20:24 |
| gnarface | yep | 20:25 |
| agneli | it will not proceed to probe emmc boot sector? | 20:25 |
| agneli | OK that seems realistic | 20:25 |
| gnarface | i think the pinebook pro has something called a "SPI" which is the thing like you said, carved from the emmc but looking like a separate device.... but get this: they ship with it empty | 20:26 |
| gnarface | but yea, i can try to make the boot.scr files each write out something unique. the u-boot build i have has display support patched in, so i just need to know the right command to echo a string, then i can be sure which one is booting | 20:27 |
| gnarface | i'm just being lazy about it right now | 20:27 |
| gnarface | because keep in mind, even if this confirms your theory, it still doesn't fix the problem, only gives us a different explanation | 20:28 |
| agneli | i think so, a bit yes :) | 20:28 |
| agneli | those are very simple things that take like 10 minutes all of them | 20:28 |
| agneli | we spent much more time discussing | 20:29 |
| gnarface | true | 20:29 |
| agneli | gnarface: i am saying uboot has same order but kernel changes it on the newer card | 20:29 |
| agneli | let me doublecheck if it actually is not happening on my device | 20:30 |
| gnarface | yea, i understand your theory. it's not supposed to be possible from what i've been told but i admit what i've been told only amounts to hearsay | 20:30 |
| gnarface | and i also admit that your theory is possible for SATA devices and that actually has caused me problems with other machines so this is a possibly valid theory | 20:31 |
| gnarface | this machine i'm talking to you on now, it has 3 drives and they never come up in the same order anymore. i had to use UUIDs here starting some 10 years ago. | 20:31 |
| agneli | so... | 20:32 |
| gnarface | and it was definitely a kernel change | 20:32 |
| agneli | I have exactly thins on my device | 20:32 |
| agneli | for uboot sdcard is 1 | 20:32 |
| agneli | while for kernel i is /dev/mmcblk0 | 20:32 |
| agneli | so it does switch the order | 20:32 |
| agneli | _kernel_ not uboot | 20:32 |
| agneli | u want some logs or something? | 20:33 |
| agneli | u saw my boot.scr | 20:33 |
| agneli | i am loading from 1 | 20:33 |
| agneli | i remember many year ago I did pull out a lot of hair because of this | 20:34 |
| agneli | so if your setup is correct then the card is being read by u-boot | 20:35 |
| agneli | if you just change root from dev to UUID it should work | 20:35 |
| agneli | then when you pull out the sd card | 20:35 |
| agneli | your emmc will take over | 20:35 |
| agneli | from what you are saying | 20:35 |
| agneli | so there will be no issue | 20:35 |
| agneli | am I wrong? | 20:35 |
| gnarface | i think you're wrong on one point because when i boot from the emmc it clearly sees the rootfs as /dev/mmcblk2p2 and when i boot from the old microSD it clearly sees the rootfs as /dev/mmcblk0p2 | 20:52 |
| gnarface | since the newer microSD doesn't complete booting, that's still unknown | 20:52 |
| gnarface | but the theory would require that the newer microSD is actually coming up as /dev/mmcblk2 | 20:53 |
| gnarface | even though the old one definitely shows up as /dev/mmbclk0 | 20:53 |
| agneli | i never had pinebook I am talking about my tegra2 based laptop | 20:53 |
| gnarface | how do i make a *.scr file that just echos a string and does nothing else? | 20:54 |
| agneli | by copying the first line form mine :) | 20:54 |
| gnarface | i could make two different *.scr files named like test.scr and just run them manually from the boot prompt | 20:54 |
| agneli | and nothing else | 20:54 |
| gnarface | looking again... | 20:54 |
| gnarface | ugh, the paste was deleted | 20:54 |
| agneli | just write echo "dasdsadsa" | 20:55 |
| agneli | and nothing else | 20:55 |
| gnarface | oh, its' just that one line? | 20:55 |
| gnarface | echo "statement" | 20:55 |
| gnarface | like that? | 20:55 |
| gnarface | i can try it | 20:55 |
| gnarface | i need a few minutes to get more coffee | 20:55 |
| agneli | echo =====> devuan daedalus <===== | 20:55 |
| agneli | so "" is not needed | 20:55 |
| gnarface | ok, noted | 20:55 |
| agneli | and if you can load *.scr | 20:56 |
| agneli | hmmm | 20:56 |
| agneli | i think I remember loading scripts from the prompt | 20:56 |
| agneli | but I would not bet on it | 20:56 |
| agneli | i can test tomorrow | 20:56 |
| gnarface | yea i know you can run them from the prompt if you've built u-boot to have a prompt | 20:57 |
| gnarface | and keyboard support | 20:57 |
| * agneli do not have keyboard support | 20:57 | |
| agneli | we have a patch but that was not accepted | 20:57 |
| gnarface | even the shell prompt is not always enabled by default | 20:57 |
| agneli | i am doing all via serial | 20:57 |
| agneli | i never enabled the shell purposedly | 20:57 |
| agneli | so for my config_* it is | 20:58 |
| agneli | anyway, from all that we have discussed your sd card is booting, problem is further down the boot procedure | 20:59 |
| agneli | you did check that card with f3, didn't you? | 20:59 |
| agneli | I think I asked already | 20:59 |
| gnarface | f3? | 20:59 |
| agneli | and I think you said you did | 20:59 |
| agneli | fight fake flash | 20:59 |
| agneli | or something | 20:59 |
| agneli | it tests well the card | 21:00 |
| gnarface | oh, no but it was in use and never threw errors for dd or tar or cp | 21:00 |
| gnarface | but i'm considering running badblocks on it anyway | 21:00 |
| gnarface | just in case it's some rare corruption on read | 21:00 |
| agneli | and you are able to mount that card on some other device, I mean the / partition? | 21:00 |
| agneli | or even better | 21:01 |
| agneli | when you boot pb from emmc | 21:01 |
| gnarface | yea, that's how i copied the contents of the rootfs over on some of the attempts | 21:01 |
| agneli | can you insert the sdcard and mount? | 21:01 |
| gnarface | yea | 21:01 |
| gnarface | it really seems to be a normal microSD card except for this problem | 21:01 |
| agneli | then I really see only the possibility which I am mentioning | 21:01 |
| agneli | what else could it be | 21:01 |
| agneli | direct copy | 21:02 |
| agneli | same uboot, same pt, same everything | 21:02 |
| agneli | or is it | 21:02 |
| gnarface | well, no, there's one other possibility; the pinebook could suck this much that it just randomly can't use certain perfectly good SD cards for no reason | 21:02 |
| agneli | first is 128 GB | 21:02 |
| agneli | and the other is 64 GB | 21:02 |
| agneli | but you said you mounted the / on pb from that card while it was booted from emmc | 21:03 |
| gnarface | yea, the new one is smaller but i accounted for that. actually i tried accounting for it and not accounting for it. neither approach changed anything | 21:03 |
| gnarface | the rootfs contensts are only 8GB | 21:03 |
| agneli | that means it can read the card perfectly well | 21:03 |
| gnarface | hmm, yea. so why would it fail to read only on boot? | 21:03 |
| gnarface | that does seem odd | 21:03 |
| agneli | this is why I am so stubborn about my theory | 21:04 |
| gnarface | could this actually be a u-boot bug somehow? specific to one card? it is an old u-boot build like i said | 21:04 |
| agneli | but you did not really dd the cards directly did you? | 21:04 |
| gnarface | like i said, i tried it both ways | 21:04 |
| agneli | what does it mean both ways? | 21:04 |
| gnarface | i tried a couple different times from a direct dd, and i also tried manually recreating and formatting all the partitions fresh then copying over the contents | 21:04 |
| gnarface | i tried like 6 times total these two basic different ways using different computers to write, including the pinebook | 21:05 |
| agneli | 1. dd untill it fails due to lack of space, device to device not partition to partition | 21:05 |
| gnarface | yea, but all that gets cut off is empty space, so in that case i just ran xfs_repair on it | 21:05 |
| agneli | but well dd directly would not work... unless all partitions on the table are small enough to fit on the smaller card | 21:06 |
| gnarface | and like i said, it only was using 8GB so when i create the partition manually and copy it over there's no complaint | 21:06 |
| agneli | your pt would be invalid | 21:06 |
| gnarface | the partition table is barely invalid in that case, it still functions. but you should know i also tried a couple times recreating the partition table in place, which works. no change though. | 21:07 |
| agneli | gnarface: could you exactly describe procedures | 21:07 |
| agneli | ach u r sure | 21:07 |
| gnarface | look, you have to try it yourself to be sure | 21:07 |
| agneli | partition table is OK and valid | 21:07 |
| agneli | and you are 100% sure the copy went well | 21:08 |
| gnarface | write a 16GB partition to a 8GB device then just delete and remake the partition in place and fsck the filesysytem. if none of the data was in the truncated part it will work fine | 21:08 |
| agneli | and it mounts | 21:08 |
| gnarface | yea, always mounts | 21:08 |
| agneli | gnarface: I just did that yesterday | 21:08 |
| agneli | fitting 512GB into 256GB | 21:09 |
| agneli | heheh | 21:09 |
| agneli | really we discussed about everything | 21:09 |
| agneli | somehow I doubt partiton that mounts on the very same device | 21:09 |
| agneli | suddenly stops working | 21:10 |
| agneli | and kernel versions are the same? | 21:10 |
| gnarface | yea | 21:10 |
| agneli | it is not like fs on that partition is much newer | 21:10 |
| agneli | than the kernel? | 21:10 |
| gnarface | ah, that was one of my first suspicions, so after that i used the pinebook to mkfs.xfs | 21:10 |
| agneli | for example I have 3.10.x kernel I need to speclially format ext4 on amodern kernel | 21:11 |
| gnarface | no change | 21:11 |
| agneli | otherwise it does not want to see | 21:11 |
| gnarface | yea, i was really hoping that would be my mistake but using the xfs from the pinebook changed nothing | 21:11 |
| gnarface | and after all, it's xfs not ext4 | 21:11 |
| gnarface | ext4 definitely had a problem like that | 21:11 |
| agneli | we did discuss everything, didn't we? | 21:12 |
| gnarface | i think so | 21:12 |
| agneli | i believe you card is OK | 21:12 |
| gnarface | trying to create some test.scr files now | 21:12 |
| agneli | you might give f3 a try | 21:12 |
| agneli | i think that is the only way... playing with the uboot | 21:12 |
| agneli | but again if what you are saying about bootsectors on pb | 21:13 |
| agneli | is should not hurt you | 21:13 |
| agneli | it should work as you want | 21:15 |
| agneli | "boot from the emmc it clearly sees the rootfs as /dev/mmcblk2p2" | 21:16 |
| agneli | "boot from the old microSD it clearly sees the rootfs as /dev/mmcblk0p2" | 21:16 |
| agneli | that line about emmc should not be /dev/mmcblk _1_ p2" | 21:17 |
| agneli | or you have more boot devices there? | 21:17 |
| gnarface | no, something weird about the hardware, mmc device 1 is not a storage device or else unfurnished... i think it might be the wifi actually but i'm not using the internal wifi for anything | 21:20 |
| gnarface | so it calls emmc mmcblk2 and microsd mmcblk0 and there's no mmcblk1 | 21:20 |
| gnarface | very strange hardware but i think it was to save costs | 21:21 |
| agneli | I suggest that apart from echo you use printenv | 21:21 |
| agneli | as well | 21:21 |
| gnarface | the SoC this device is based on costs $17 | 21:21 |
| gnarface | hmm, i have a problem with the first test | 21:22 |
| gnarface | echo is doing nothing | 21:22 |
| agneli | not build in the u-boot? | 21:22 |
| agneli | i think there is an option for evey boot shell command in the u-boot menuconfig, yes | 21:23 |
| gnarface | can't be that, because if i run "echo blah" at the u-boot prompt it echoes blah | 21:23 |
| gnarface | if i try to call test or test.scr it just outputs nothing | 21:23 |
| agneli | then id should work in script too | 21:23 |
| agneli | i think it should be some load or somehting, idr | 21:24 |
| gnarface | maybe it's a u-boot bug i'm not sure, but can you show me yours again? | 21:24 |
| agneli | http://paste.debian.net/plain/1286146 | 21:25 |
| gnarface | thanks | 21:26 |
| gnarface | hmm, unles some of these later lines are somehow required to make the echo work, i don't see what could be wrong | 21:27 |
| gnarface | i don't get any errors from the test.scr i made but i also don't get any output | 21:27 |
| agneli | no | 21:29 |
| agneli | they are not required | 21:29 |
| agneli | but I think the printenv will tell you how to load boot.scr | 21:30 |
| agneli | or some other.scr | 21:30 |
| gnarface | printenv when run from the shell prompt outputs quite a lot | 21:30 |
| agneli | what you have in the bootcmd line if I recall correctly | 21:30 |
| gnarface | any clues as to what i should be looking for specifically? | 21:30 |
| agneli | yes a lot | 21:30 |
| agneli | printenv bootcmd id say | 21:30 |
| gnarface | oh! i have an idea | 21:31 |
| gnarface | hah | 21:31 |
| gnarface | i'll delete one test.scr | 21:31 |
| gnarface | then i'll know which one i'm booting because it'll error on the one that doesn't have it | 21:32 |
| agneli | i just recommend you make sure there is not boot* line there | 21:32 |
| agneli | so screen stays for you to read | 21:32 |
| gnarface | yea, the only contents are this: | 21:32 |
| gnarface | echo =====> 16GB Pinebook internal eMMC <===== | 21:32 |
| agneli | i have to go, good luck :) | 21:33 |
| gnarface | thanks | 21:34 |
| agneli | just in case: https://u-boot.readthedocs.io/en/latest/usage/index.html#shell-commands | 21:34 |
| gnarface | argh | 21:39 |
| gnarface | i think it may have been a poor choice to use "test.scr" as the file name | 21:39 |
| gnarface | damit | 21:39 |
| gnarface | yea that was dumb. native shell test was running instead of test.scr... starting over. (sigh) | 21:39 |
| gnarface | agneli: alright, well, i got some more info. adding "gnartest.scr" to both microSDs didn't work, it can't find it in either place when i add it, but... i did notice that if i run "mmc info" from the shell prompt i get 3 different responses depending on which device i'm booting from, which seems to be matching expected behavior | 22:02 |
| gnarface | "mmc" info reports the correct size of the microSD if the 64GB or 128GB are present, and if it's booting from eMMC it just says no cards are present | 22:03 |
| gnarface | ...er, "mmc info" i meant to type | 22:03 |
| gnarface | so that seems to suggest to me that it's booting from the device i expect in every case, and it must just be mysteriously allergic to the 64GB microSD for no apparent reason | 22:03 |
| gnarface | that doesn't explain why nothing sees my alternate "gnartest.scr" files but maybe there's rules about what *.scr files can be named which i wasn't aware of | 22:04 |
| gnarface | i think now maybe i'll run a destructive-mode read+write badblocks pass on the 64GB microSD because read corruption or silent write failure seems to be the only other possible explanation here | 22:05 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!