Saturday, 2022-02-26

T42<HengYeDev> @elros34 Here it is
T42<HengYeDev> Adding system/${LIB} to the sphal search path doesn't seem to make it work either, i think because its not in the "framework or device manifest"00:38
T42<elros34> you could see how original looks like but probably is same just without hybris paths01:00
T42<elros34> @HengYeDev maybe something like that:
T42<LSolrac> Nope. I cloned the preexisting Lineage 17.1 Kernel Sources (re @elros34: Do you use prebuilt ...)04:43
T42<zinstack625> Where have you cloned them, and where are they being expected to be by the device tree (must be in the dependencies if it's the lineage tree) (re @LSolrac: Nope. I cloned the p...)07:31
T42<LSolrac> This is my manifest file. (re @zinstack625: Where have you clone...)07:54
T42<LSolrac> The trees are being cloned to device/samsung/07:54
T42<LSolrac> And the kernel to kernel/samsung07:54
T42<LSolrac> I assume I should rename kernel/samsung/star2lte to kernel/samsung/universal9810 ?07:57
T42<zinstack625> Mostly correct, but kernel is expected in another directory. See
T42<zinstack625> Exactly (re @LSolrac: I assume I should re...)07:57
T42<LSolrac> The mistakes of building android for the first time... thank you. I'll try again c:07:58
T42<LSolrac> Sadly, it still happened.
voidanix[m]Have you checked that the kernel src is actually there though? Do `repo sync kernel/samsung/universal9810` just in case09:07
T42<LSolrac> It worked acutally It started compiling the kernel. (re @SailfishFreenodeIRCBridgeBot: <voidanix[m]>Have yo...)09:52
T42<LSolrac> But of new error regarding the defconfig
T42<elros34> looks like wrong fixup-mountpoints changes10:00
T42<elros34> or some duplicate entries in fstab10:00
T42<LSolrac> Maybe? I based myself off of the result removing the -> and replacing the10:21
T42<LSolrac> left text with s block/by-name 🤔10:21
T42<LSolrac> adb's report:
T42<LSolrac> my addition to the fixup-mountpoints: (re @elros34: looks like wrong fix...)10:21
T42<elros34> looks wrong, compare with others: space is a separator in this sed command. Also did you read collabedit? Path also looks incorrect10:23
T42<LSolrac> I havent read the collabedit, but I took a look and did notice a few notes of fstab. I'll lok into them, I also noticed I didn't leave any spaces at the end of the lines (re @elros34: looks wrong, compare...)10:25
T42<elros34> like I said previously, you should read it before starting building, it would save from making few common mistakes10:27
T42<LSolrac> Will do.10:31
T42<LSolrac> Though. I don't think my fstab is rather helpful.
T42<LSolrac> Most storage devices are missing, and most of the ones here are accessed via the same path and then by name. Maybe Im getting the wrong file though10:37
T42<elros34> it doesn't matter how they are accessible in device, the point is that fixup-mountpoints will replace by-name path from fstab10:40
T42<elros34> What is not unclear in collabedit instruction so I can fix it:  "fixup-mountpoints converts your by-name path defined in fstab and .rc files (for example: /dev/block/platform/msm_sdcc.1/by-name/system) to block device (for example: /dev/mmcblk0p23) which is needed to create working systemd mount units. So to create correct map for your device you need entries from your fstab and ls -l */by-name/* output from device. Do not assume that your de10:42
T42<LSolrac> I was just reading that.10:43
T42<AntonlX> Does sound in calls fixed for lena device?10:44
T42<LSolrac> May I ask why you think the path is incorrect? /dev/block/by-name/ gives me the same result as /dev/block/11120000.ufs/by-name10:48
T42<LSolrac> vs 🤔 (re @elros34: looks wrong, compare...)10:48
T42<elros34> that is why I ask what is unclear. Your by-name symlinks on device doesn't matter. fstab is a source for fixup-mountpoints not your device symlinks10:50
T42<elros34> sed 's block/by-name/USERDATA sda25 ' fstab will not change anything10:51
T42<elros34> because there is no "block/by-name/USERDATA" in fstab at all10:52
T42<LSolrac> oh, my apologies so, to clarified, fstab is preffered then10:52
T42<LSolrac> then i may need to double check cause my fstab file was in /vendor only, and it was still symlinked10:53
T42<elros34> I am still not sure if you get it: fstab is not prefered it's source. If it's missing in your device tree then you need to copy it (also explained in instruction)10:57
T42<LSolrac> I'll admit I am confused at the moment. I'll check the instructions again, but its my understanding that I do have the device tree cloned in the correct directories. (Replying to a link to my manifest)11:08
T42<LSolrac> I do apologize for by lack of knowledge (re @LSolrac: This is my manifest ...)11:08
T42<elros34> do no apologize for lack of knowledge. I want to understand what is confusing in hadk or in collabedit instruction about fixup-mountpoints because you are not the first one who has trouble to understand it but nobody improve instruction after they finally get it11:18
ThaodanAntonlx: No this one
Thaodanbut it depends on your device11:21
ThaodanSee here11:22
Thaodanelros34: both are sources for the .mount units. The issue is that udev isn't there so early when we mount our units so we need to use the direct device files instead of the symlinks from /dev/block11:23
T42<elros34> I guess you meant @LSolrac ^11:37
ThaodanBoth since the fixup-mountpoints and fstab are used11:50
T42<HengYeDev> Where is this to be applied? i don't have all those gralloc source files and my device isn't qcom... (re @elros34: @HengYeDev maybe som...)14:49
T42<HengYeDev> There is also a strange occurence that only occurs rarely..when the device is booted into the "charging mode" (with the charging percent of sailfishos) the display works and telnet works, i did see the sailfish gui once but that's about all...)15:01
T42<HengYeDev> does this give any clues? @elros3415:01
T42<HengYeDev> booting normally, this never happened15:01
*** Daanct12 is now known as Danct1216:21
T42<HengYeDev> I find it interesting that the charging mode seems to work perfectly...16:22
T42<HengYeDev> therefore, i would guess that mapper isn't the problem, as actdead-charging worked with mapper 2.0...16:25
T42<HengYeDev> so, any clue why act-dead charging works but minimer, lipstick don't during a normal boot?16:26
T42<elros34> about commit: obviously it will not apply to your completely different device, just idea what changes might be required to achieve what you are trying. About act-dead I have never tried to debug it so not sure how it works. I still suggest you the same: try bootanimation with surfaceflinger, if that works then you at last can be sure that android side works correctly16:51
T42<elros34> Check you *.rc files, there should be different sections and different services started for act-dead mode and normal mode16:52
T42<HengYeDev> how is bootanimation supposed to be run? i try to run surfaceflinger and bootanimation at same time, bootanimation says ANDROID_ROOT not set and segfaults17:24
T42<elros34> maybe just remove it from disabled_services.rc17:25
T42<HengYeDev> act-dead causes device to bootloop when manually run and user@100000 service is masked, so does this mean that some other service started earlier causes the bootloop?17:26
T42<HengYeDev> note that it works perfectly when it is not normal booted17:26
T42<HengYeDev> where can i find the services that are started otther than user@100000?17:26
T42<AntonlX> How to add firmware to ramdisk? (re @leha155: thanks for the advic...)18:08
T42<BenKerry> Is there a port for the RedMi Note 10 Pro ???18:08
T42<AntonlX> No, there is no Rn10Pro ports. Porting is hard and long process. No one will do it for free and to device which don't have. If you want you can make own port. (re @BenKerry: Is there a port for ...)18:22
T42<BenKerry> I have no idea sorry. (re @AntonlX: No, there is no Rn10...)18:22
T42<elros34> @AntonlX build particular driver as  module or/and make sure you have fw_helper* options enabled in defconfig18:40
T42<elros34> @HengYeDev just an idea, systemctl list-dependencies compared to doesn't include yamuisplash. Maybe splashscreen mess with your driver19:19
T42<LSolrac> Good Afternoon, Thaodan, Elros. I think this was the bit that wasn't as obvious. So if anything I'd change that. Explicitly explain the direct file is preffered over any symlinks. I tried changing the it from /dev/block/platform/by-name, to /dev/block/platform/11120000.ufs/by-name, and it seems to have worked (re @SailfishFreenodeIRCBridgeBot: <Thaodan>elros34: bo...)19:53
T42<LSolrac> First Successful Build19:54
ThaodanYes and you have to compare which file the fstab mentions e.g. /dev/block/by-name or /dev/block/platform/by-name19:55
T42<LSolrac> So, something like; Get names via 'ls -l /dev/block/*/*/by-name, confirm physical location via fstab?19:56
T42<HengYeDev> likely not, i don't seem to be able to find yamuisplash anywhere on my rootfs?20:00
T42<HengYeDev> is it included? (re @elros34: @HengYeDev just an i...)20:00
T42<elros34> @HengYeDev not sure if it's installed by default, check with zypper se splash20:01
T42<HengYeDev> @elros34 Seems that it isn't installed then20:04
T42<HengYeDev> possibly, in hybris-17, i must apply as in hybris-16 faq?20:05
T42<elros34> @LSolrac 'ls -l /dev/block/*/*/by-name' is to get map between block device sda27/mmcblk0p21 and partition name system/SYSTEM/20:10
Thaodan@LSolrac: Yes fstab sometimes uses a different path than you would find booted up on stock, all that matters is that you have the right real device file for the fstab20:16
T42<HengYeDev> however, @elros34 , it is interesting that yamuisplash does not cause the bootloop when manually run, it also does not display anything either though20:19
T42<HengYeDev> absolutely nothing in logcat20:19
T42<elros34> yamui doesn't use hwcomposer20:20
T42<LSolrac> Thank you for clarifying20:21
T42<LSolrac> So, are there any general recomendations on what _should_ be enabled in a kernel config? I got this from the kernel checker, Im seeing a few that I already wanna enable but I wanted to make sure
ThaodanYou can also look into the defconfigs of official ports20:36
ThaodanJust make sure that they are the same in your kernel20:36
ThaodanE.g. lena/Xperia 10 III here:
T42<LSolrac> Im assuming these should be modified in the kernel's defconfig file as opposed to the .config file, correct?21:08
T42<HengYeDev> @elros34 did some more testing, minimer works perfectly when the below sequence is followed:21:55
T42<HengYeDev> 0. usb plugged in21:55
T42<HengYeDev> 1. Regular boot, user@100000 masked21:55
T42<HengYeDev> 2. shutdown -h now from telnet21:55
T42<HengYeDev> 3. The device will shutdown than show the charging screen (looks like this:
T42<HengYeDev> 4. wait a few seconds21:55
T42<HengYeDev> 5. the device will boot into the sailfish rootfs with the actdead thing - note that it is strange as the bootloader warning isn't even displayed21:55
T42<HengYeDev> 6. run minimer from telnet, it works perfectly, but the power button is misbehaving (i think we can worry about that later)21:55
T42<HengYeDev> Minimer will not work on a regular boot.21:55
T42<HengYeDev> I straced minimer on the regular boot:
T42<elros34> so do I get it right that now minimer do not cause decon failure and crash? Did you check init*.rc files for actdead/normal boot differences?22:06
T42<HengYeDev> @elros34 What do you mean by init*.rc files? Here are all the init.rc files i have in the fs:
T42<HengYeDev> yes, it is right that minimer does not cause decon failure when in the actdead mode22:11
T42<elros34> in normal boot also?22:12
T42<HengYeDev> no22:15
T42<elros34> no idea what makes difference, maybe some initialization order/timming  and you should restart hwcomposer just before you start minimer similar to this:
Thaodan@LSolrac: The .config file is generated from the  _defconfig file its easier to do that than keep our own .config file in the kernel package itself22:44
Thaodan@elros34: Hwcomposer needs to be stoped if e.g. minirun was before22:45

Generated by 2.17.1 by Marius Gedminas - find it at!