| onefang | One is larger than the BIOS can handle for booting maybe? | 04:49 |
|---|---|---|
| gnarface | onefang: they're both ARM devices, so there's no BIOS, and the one that isn't booting is the smaller of the two... and that one booted fine on another A64 board with a different OS image | 09:27 |
| gnarface | still, maybe it's somehow defective or incompatible but i'm struggling to see how | 09:28 |
| agneli | gnarface: what is your normal boot procedure for the source one? | 09:51 |
| agneli | or even better - when you upgrade the kernel | 09:51 |
| agneli | any acitivies with boot loader? | 09:52 |
| agneli | I am using uboot and hmmm I am kinda sure after dd it shoudl work | 09:52 |
| agneli | you dd'ed whole card, didn't you? not just the partition? | 09:53 |
| agneli | and speaking about sdcards, I had those strange read only moments on my sdcards, I think we discussed few times... seems I solved it, I red somewhere it might be poor electrical contact so I applied some conact cleaner to both card and the reader, so far so good... | 09:58 |
| gnarface | agneli: i tried it several different ways, including dd-ing the whole thing, or just the part before the first partition. same results both times. i'm forced to conclude the device is allergic to the sd card itself somehow, it's just weird because the same sd card is working fine in another very similar device | 10:37 |
| agneli | do you have any messages? | 10:38 |
| agneli | it is just so bizzare, I am curious | 10:39 |
| agneli | and in that very similar device does it begins booting? | 10:39 |
| gnarface | ugh, didn't save it specifically though i probably should... just kernel panic then boot loop. complaints it can't find root device, suggests i should specify an init on the kernel command-line | 10:40 |
| gnarface | but it couldn't be throwing that error if it couldn't find the device | 10:41 |
| gnarface | and yea the other board just boots fine | 10:41 |
| gnarface | they're using different kernel and rootfs though | 10:41 |
| agneli | would be interesting to see those messages in detail... | 10:42 |
| gnarface | i'll have to hook a serial terminal up or something | 10:42 |
| agneli | ach... | 10:43 |
| agneli | this is why I have serial hooked up at all times, you never know :) | 10:43 |
| agneli | do you care to share models of both cards, please? | 10:44 |
| gnarface | uh... i can try | 10:44 |
| gnarface | didn't really save them but i can tell you what the label says | 10:45 |
| gnarface | the working one says "samsung 128 pro endurance" (white+black label) and the non-working one just says | 10:46 |
| gnarface | "micro SD XC 64GB" | 10:46 |
| gnarface | but it's from pine64's house label | 10:46 |
| gnarface | however ... both devices are A64 based, also from pine64 | 10:46 |
| agneli | so u copied 128 GB card to 64 GB | 10:47 |
| agneli | I recommend you do use this 3f thing | 10:47 |
| agneli | to check the 64 GB card | 10:47 |
| agneli | if it is really 64 GB | 10:47 |
| gnarface | well yes, but there was only 7GB of data on it, and the second partition that would go over the end, i did try recreating it and just copying over the contents to the smaller disk, i tried it more than once in fact. same results | 10:48 |
| agneli | you have only one partition on 128 GB card? if yes what is the % of space used | 10:48 |
| gnarface | 2 partitions but the first partition was only 100MB | 10:48 |
| gnarface | both partitions nearly empty | 10:48 |
| gnarface | just /boot/ (100MB) and / (the rest of the disk) | 10:48 |
| agneli | and you say the 64 GB card on a different device works sort of OK? | 10:49 |
| gnarface | worked 100% fine on the other device. and on the one that wasn't working, i tried BOTH bootloaders | 10:49 |
| agneli | and after copying are you able to mount that 64 GB card on some othere device? | 10:49 |
| agneli | fsck does not complain? | 10:50 |
| agneli | can you ready and write to it? | 10:50 |
| gnarface | yea, mounted it and verified | 10:50 |
| gnarface | i even tried once just writing the whole disk and letting it run over the end and fscking the filesystem just to see if my problem was in the filesystem recreation | 10:50 |
| gnarface | same result though | 10:50 |
| agneli | so it all worked? | 10:51 |
| gnarface | yea the 64GB card seems fine and boots in a A64+ board, but fails to boot in a pinebook based on the exact same A64 SoC | 10:52 |
| gnarface | i can mount it, i can fsck it | 10:53 |
| agneli | ech this must be sth very simple... | 10:53 |
| gnarface | i'm about to try badblocks on it, but dd and tar threw no errors | 10:53 |
| agneli | nah I think you did check all possible things | 10:53 |
| agneli | iiuw it does boot | 10:53 |
| gnarface | i'm starting to think it's just gotta be gremlins but this is a very weird one | 10:54 |
| gnarface | maybe i should try polishing some contacts too | 10:54 |
| agneli | but cannot find the root filesystem | 10:54 |
| agneli | how do you pass root filesystem, please? | 10:54 |
| agneli | UUID or /dev/sdX ? | 10:54 |
| gnarface | it's /dev/mmcblk0p2 | 10:55 |
| agneli | and u r sure the device is OK? | 10:55 |
| gnarface | i've imaged it several times now, dd doesn't complain and i can always mount and read the filesystem afterwards | 10:55 |
| agneli | on my ac100 i am getting sdcard as 1 device and internall emmc second | 10:55 |
| agneli | idk why :) | 10:55 |
| agneli | leave the image, please, I do not think there is anything wrong with it | 10:56 |
| agneli | at least for now :) | 10:56 |
| agneli | my bet is the /dev/mmc think is the problem | 10:56 |
| gnarface | i'm giving up on it for now but maybe i'll try dumping the full text of the failed boot to a file tomorrow | 10:56 |
| gnarface | there's no way a change to microsd model could somehow change the mmcs' physical orders right? | 10:57 |
| agneli | I would bet that you need to do /dev/mmcblk _1_ p2 | 10:57 |
| gnarface | only thing i could think of is if my boot.scr was somehow wrong for the different disk but i couldn't see how that'd be possible | 10:57 |
| agneli | this is exactly what I am saying | 10:57 |
| gnarface | since they shouldn't have changed orders | 10:57 |
| agneli | idk why but that happes to me | 10:57 |
| agneli | depends on the kernel even | 10:58 |
| agneli | i think the speed at which devices are initiated by uboot | 10:58 |
| agneli | matters... | 10:58 |
| gnarface | hmm.... i did consider trying extlinux to see if it gives me less trouble but i haven't tested yet | 10:58 |
| agneli | so I think your card is just slower | 10:58 |
| gnarface | i didn't know that was possible. maybe extlinux will help then | 10:58 |
| agneli | and gets initialized later | 10:58 |
| agneli | hence 1 | 10:58 |
| agneli | not 0 | 10:58 |
| agneli | extlinux still has uboot inside, no? | 10:59 |
| gnarface | the 64GB card is probably slower, but i didn't think it'd change orders because of that | 10:59 |
| gnarface | i think in this case extlinux is inside u-boot but i'm not clear on specifics | 10:59 |
| agneli | this is why I prefer UUID | 10:59 |
| agneli | for any usb and msd and etc | 10:59 |
| agneli | I am not sure my explanation is correct gnarface but I did bang my head against the wall because of such issue many times | 11:00 |
| agneli | so I wasy pass root as UUID :) | 11:00 |
| agneli | *say | 11:04 |
| gnarface | i think in this case if your theory is correct it may actually be about the boot.scr's mmc 0:1 / mmc 1:1 specifier | 11:25 |
| gnarface | but i think i did see an error like that scrolling by that may be an indication your theory is correct | 11:26 |
| gnarface | if changing the sd card had somehow changed the physical order of it with respect to the emmc, then the boot.scr would no longer be accurate | 11:26 |
| gnarface | the other device i was booting with extlinux instead of a boot.scr, but it also had no internal storage so that's two counts of irrelevance | 11:27 |
| gnarface | there are very few other material differences between these two devices so it seems like a viable suspect anyway | 11:29 |
| gnarface | thanks for that | 11:29 |
| agneli | "it may actually be about the boot.scr's mmc 0:1 / mmc 1:1 specifier" | 11:48 |
| agneli | yes | 11:48 |
| agneli | let me know gnarface when you have time to test it, please ;) | 12:11 |
| agneli | and I backtrack on the mmc x:1 specifier | 12:11 |
| agneli | if that would be the case it would not boot at all | 12:12 |
| agneli | unless it is not complainig about missing root but it in fact complains about being unable to find *.scr file | 12:13 |
| agneli | but unless you have some special uboot compilation it should not be relevant | 12:13 |
| agneli | uboot scans everything it can find for the scr script... | 12:13 |
| agneli | ach but then it needs to load... OK | 12:14 |
| agneli | :) | 12:14 |
| gnarface | agneli: "Kernel panic - not syncing: No working init found..." | 16:01 |
| gnarface | ?? | 16:01 |
| gnarface | it reads the boot.scr, and it even finds the kernel using that info | 16:01 |
| gnarface | the kernel starts booting, i see my boot penguins | 16:01 |
| gnarface | (turns out the "unable to use mmc 1:1" thing was a u-boot error that's irrelevant) | 16:02 |
| gnarface | it says to try passing init= option to kernel, but i figured that's a red herring because the same install didn't need that on the other microSD | 16:03 |
| gnarface | could i be wrong about that? | 16:03 |
| agneli | i think i am passing that one... | 16:03 |
| agneli | let me boot my device and check | 16:04 |
| gnarface | i've never had to before | 16:04 |
| gnarface | root= yes, but not init= | 16:04 |
| gnarface | is that still something that could be caused by nothing more than a speed difference in the media? | 16:05 |
| agneli | i doubt | 16:05 |
| agneli | ach... | 16:06 |
| agneli | and what about uboot | 16:06 |
| agneli | is this the same uboot | 16:06 |
| agneli | the same compilation? | 16:06 |
| agneli | the same version? | 16:06 |
| gnarface | i even have rootwait | 16:06 |
| gnarface | yea, same u-boot on both microSDs | 16:06 |
| gnarface | not a very recent version | 16:06 |
| agneli | you have to have an uboot installed on some bootsector on internal storage | 16:07 |
| agneli | at least on my device | 16:07 |
| agneli | i remove all cards and still I will see it booting | 16:07 |
| agneli | is that the case for your boards? | 16:07 |
| agneli | i am pretty sure pbp has internal storage | 16:08 |
| gnarface | it's an old pinebook not a pro, and yes it has internal storage but i have a different u-boot version there, and it's much smaller. if it was booting into that i'd notice (this time. that did screw with me once in the early days) | 16:08 |
| gnarface | the bare SoC A64 board however has no internal storage and does not boot without microSD | 16:09 |
| agneli | https://paste.debian.net/plain/1286030 | 16:10 |
| agneli | this is me :) | 16:10 |
| agneli | say hi gnarface :) | 16:10 |
| gnarface | heh, fancy | 16:11 |
| gnarface | i see no init= here... | 16:11 |
| agneli | so I am loading initrd into memory and uboot passes it to kernel | 16:11 |
| agneli | it is there Sir | 16:11 |
| agneli | show me yours please | 16:11 |
| gnarface | yea, i see the initrd= but i'm not even using one of those | 16:11 |
| agneli | and from what you say I think you _do_ have 2 different uboots | 16:12 |
| agneli | one on the pinebook is old | 16:12 |
| gnarface | uh, yea... here, this is it i think https://paste.debian.net/1286031/ | 16:12 |
| agneli | and it is the one that is not working with your copied card | 16:12 |
| agneli | why the hell it works with the original idk | 16:13 |
| agneli | but all of these messages | 16:13 |
| agneli | mean order of devices is OK | 16:13 |
| agneli | but again kernel restarts the devices | 16:14 |
| agneli | I had such a situation with pre 3.10 kernels | 16:14 |
| agneli | that order was different for uboot and different for kernel | 16:14 |
| * agneli recomends adding that load initrd bit... | 16:15 | |
| gnarface | but i don't have an initrd.img | 16:16 |
| gnarface | i statically built the drivers in | 16:16 |
| agneli | ach ok | 16:16 |
| agneli | and UUID for root | 16:16 |
| agneli | you see the penguins - that means it cannot find / and therefore init | 16:17 |
| agneli | if UUID would not help I am ready to say there is sth wrong with the controllers or something... | 16:18 |
| gnarface | hmm, well it's well known there's "something wrong" with these controllers, and being mysteriously unable to read properly rated cards is one of them | 16:20 |
| gnarface | one of various issues | 16:20 |
| gnarface | usually the issue doesn't crop up with their own cards though | 16:21 |
| gnarface | and usually it can't read /boot either | 16:21 |
| agneli | card is no name so it is not great | 16:21 |
| gnarface | what's weird is that it can definitely read /boot but apparently not / | 16:21 |
| agneli | it is not reading /boot Sir | 16:21 |
| agneli | it is reading mmc 0:1 | 16:21 |
| gnarface | it has to be, because it starts the kernel, and that's where the kernel is | 16:21 |
| agneli | no | 16:22 |
| gnarface | keep in mind this is a non-pro, the boot order is different | 16:22 |
| agneli | it loads first partition from the media | 16:22 |
| gnarface | the pro boots the emmc first in hardware, but this one actually boots the sd first in hardware | 16:22 |
| agneli | load mmc 0:1 | 16:22 |
| agneli | fromally it is not /boot | 16:22 |
| agneli | and for some reason with this card kernel reorders it | 16:23 |
| agneli | this is my bet | 16:23 |
| gnarface | hmmm | 16:23 |
| agneli | until proven by the fact that UUID will not change anything | 16:23 |
| agneli | aaaaameeeeeen :) | 16:23 |
| agneli | unfortunately one of uboot devs I know is not around :( | 16:24 |
| agneli | so we are alone... | 16:24 |
| gnarface | well, looks like you may be right about this, because it seems like i must have updated the emmc u-boot after all | 16:32 |
| gnarface | so your theory is it's actuall skipping the microSD, then booting the eMMC which... loads the microSD anyway but then changes its order so it can't find root after that? | 16:35 |
| gnarface | truthfully that sounds like a problem with u-boot's behavior but i remember early on everyone was having problems with them being in different orders on different batches of the same model, so maybe this is the same issue still | 16:36 |
| gnarface | maybe it's the controller misbehaving still in the same way | 16:36 |
| gnarface | just a new outcome from the same problem | 16:37 |
| gnarface | but if that's the case, then fixing this on the microSD won't do anything, i'll have to update the emmc one | 16:38 |
| gnarface | and then after that it won't be able to sneakly boot both anymore | 16:38 |
| gnarface | hmmm.... | 16:38 |
| gnarface | i wish there was a way to just force the order so it doesn't change | 16:39 |
| agneli | hmmm | 16:51 |
| agneli | my uboot is configured on purpose to look for *.scr file | 16:51 |
| agneli | if it does not find anything on emmc it looks at the card | 16:52 |
| agneli | and I will surely look in the future in an option that it looks at the card frist | 16:52 |
| agneli | and if not found then on emmc | 16:52 |
| gnarface | is there a way to make the u-boot shell say which disk it's currently on? | 16:54 |
| agneli | ugh, idr, but there was even a way to list | 16:58 |
| agneli | i built my script loooong ago | 16:59 |
| gnarface | agneli: this hypothetical disk order switch, do you think the status at the u-boot shell will represent that change, or do you think it's happening after that? | 20:39 |
| agneli | idk really, I just heard from a colleague that this is not true what I am saying | 21:12 |
| agneli | but I do remember very well having problems with guessing what drive is actually what | 21:13 |
| agneli | i once even ereased my emmc because I gave wrong device to the installer | 21:13 |
| agneli | and device was the one I was using daily on other (fact is: newer) distro | 21:14 |
| agneli | gnarface: why do not you just test: boot it or mount it, issue blkid and pass the root as UUID? | 21:15 |
| agneli | 16:39 < gnarface> i wish there was a way to just force the order so it doesn't change - well UUID bypasses that issue | 21:16 |
| agneli | then you have everything mounted in proper places | 21:16 |
| agneli | and you can even use same sd card in other ports(like USB) and other devices and all will be just jazzy and sexy | 21:16 |
| gnarface | agneli: yea, but then if i pull it out the emmc won't boot | 22:03 |
| gnarface | i definitely had a problem with the order not being as expected, but to my knowledge it had never been expected to change on the fly | 22:04 |
| gnarface | it was one of those things i was told changed on a per device basis, usually between different batches but not always | 22:04 |
| gnarface | i can definitely do it to test the theory, and i probably will later, but if the theory is true that just gives me a different problem | 22:05 |
| gnarface | so that sabotages the primary goal which was to switch these cards | 22:06 |
| gnarface | without regressions in expected behavior | 22:06 |
| gnarface | as that would basically make the emmc only capable of booting the rootfs of one particular microsd | 22:08 |
| gnarface | i could make it the right microsd, but i wouldn't be able to boot the rootfs on the emmc just by removing the microsd anymore | 22:09 |
| gnarface | and i wouldn't be able to easily use a different microsd either | 22:09 |
| gnarface | i was hoping to avoid having to build a new u-boot but maybe that's what it has come down to | 22:10 |
| gnarface | the discouraging thing is that i might do all this and find out the problem with the microsd is inherent and not fixable in software... which is possible, even if it seems unlikely because the same card booted a different image on a different device of the same chip family fine | 22:11 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!