Thursday, 2023-05-11

Caffeineupdate: I think I have fixed the merge conflicts00:06
Caffeinecompiling again now00:06
Caffeine@T42 it turns out I needed to revert another00:36
Caffeinethe kernel was complaining about this file00:37
CaffeineIT LIVES!!00:40
CaffeineHi I have some errors, and I'm not sure how to solve these, cause when I try it seems to open up more problems.02:40
T42<elros34> is that with or without changes in defconfig?06:12
T42<edp_17> Is there a way to check what's kernel installed on the device?09:06
T42<edp_17> I'd like to do because of the following:09:06
T42<k1gen> `uname -a`?09:07
T42<edp_17> Thanks.09:07
T42<edp_17> So, I've turned CIFS on in defconfig (it is correctly set in /out/*/.config)09:07
T42<TheVancedGamer> `zcat /proc/config.gz`09:08
T42<edp_17> did a zypper dup, then reboted09:08
T42<edp_17> the device rebooted a few times, so I think the kernel was installed09:08
T42<edp_17> but zcat /proc/config.gz | grep CONFIG_CIFS gives me nothing09:08
T42<TheVancedGamer> are you sure you have the correct kernel? you can check build time in uname -a09:09
T42<edp_17> It's not a module, built in (CONFIG_CIFS=y)09:09
T42<edp_17> I'll check that thanks.09:09
T42<edp_17> So, uname -a gives me: Linux G7Power 4.9.206-edp17+ #16 SMP PREEMPT Sat Jan 21 22:37:29 UTC 2023 aarch64 GNU/Linux09:12
T42<edp_17> Is that date (Sat Jan 21 22:37:29 UTC 2023) when the kernel was built?09:12
T42<edp_17> If yes, then, it's a bit old.09:12
T42<edp_17> :)09:13
T42<TheVancedGamer> @edp_17: yup, that's the build date09:17
T42<TheVancedGamer> what?10:06
CaffeineNickserv was asking me to use the identify command10:40
Caffeineelros34, I have edited the defconfig10:42
T42<edp_17> @TheVancedGamer : Hmm, then it looks like the OTA update didn't properly flash the updated kernel. Indeed, I built the last image in January but since I have OTA updated it a few times. (Just an hour ago I did it.)12:26
T42<edp_17> Guess I should flash the kernel manually. :)12:26
T42<b100dian> You shoukd check journalctl -b -112:37
T42<edp_17> Thanks, will do. Now I flashed the kernel and cifs works. :)12:41
malcheck the configs for kernel flashing12:43
T42<edp_17> On device the /var/lib/platform-updates/ has a missing line. On my github repo there is that line, (/usr/sbin/flash-partition boot /boot/hybris-boot.img)12:49
T42<edp_17> The CPUCHECK_STRING in /var/lib/flash-partition/device-info matches with the Hardware value from /proc/cpuinfo12:53
T42<edp_17> So, probably the is the guilty one.12:54
T42<edp_17> Oh, no wait, that content is also correct on device.12:54
T42<edp_17> And its executable.12:56
T42<edp_17> Might be the device was booting from Slot B while the script updated Slot A? Is that possible?12:56
mal@edp_17 check these and
malthose flash both a and b slots13:08
malnot sure if your device needs dtbo.img so skip that if not relevant13:08
malusually on dual-slot devices flashing both is a good idea, unless for a good reason13:10
mal*both slots13:11
T42<edp_17> mal : Thanks! I think this was the missing bit.13:11
T42<edp_17> How can I install TWRP on a dual-slot device? (When I installed it, the device still booted into Sailfish)13:12
maldoes the device have recovery partitions?13:13
T42<edp_17> Not sure, how can I check?13:14
T42<edp_17> No recovery listed in /dev/block/bootdevice/by-name/13:14
malwondering how it handles recovery on the device13:16
T42<edp_17> I always use PC to boot into recovery with : fastboot boot <twrp.img>13:16
T42<edp_17> When I am in recovery and trying to reboot into recovery Sailfish (or Android if that's installed) starts13:17
malof course that happens if you have used fastboot boot13:18
T42<edp_17> Oh, okay.13:18
malafaik that only boots in once without flashing it so next reboot uses the boot image flashes on the device before that13:18
T42<edp_17> I see. If I flash TWRP, then I can boot into it but cannot boot Sailfish anymore. If I flash hybris-boot, I can boot Sailfish but not TWRP anymore. :)13:20
T42<edp_17> But this is not crucial at the moment, so don't worry about it.13:20
T42<edp_17> mal: in that device-info example you gave me for dual-slots, how can I know what partition number I should set? (In your example there is part_1 and part_32 for boot_a and boot_b)13:22
malhow often do you really need to reboot from recovery back to recovery13:22
T42<edp_17> mal: I don't need that often. What I'd need is ability to boot into recovery without PC.13:23
malone a bit ugly option would be to have recovery in slot b and normal kernel slot a and manually changing slot in sailfish to get into recovery and then back in recovery13:24
T42<edp_17> I see. Yeah, that would be a bit ugly solution, however, if that works... :)13:27
T42<edp_17> mal: in that device-info example you gave me for dual-slots, how can I know what partition number I should set? (In your example there is part_1 and part_32 for boot_a and boot_b)13:27
malpart_1 is always there and is boot_a, other are based on the partition number you see in ls -l /dev/block/bootdevice/by-name/13:30
T42<edp_17> mal: I have boot_a -> mmcblk0p41 and boot_b -> mmcblk0p4213:53
T42<edp_17> so, should I put PART_1="boot_a" and PART_42="boot_b" ?13:53
maland then in part real set the real device nodes for both13:55
T42<edp_17> Oh, I see.13:57
T42<bouic> Anyone knows how to change fastboot slot from SFOS? `/usr/libexec/droid-hybris/system/bin/bootctl set-active-boot-slot 0` gives me a permission error, even as devel-su, and breaks the next boot (until fixed with fastboot).16:43
T42<bouic> I'd really like to find a way to do that on device, since I can do it on Droidian on the same device; this would allow dual-booting both OS without a computer to change slot with fastboot.16:43
malin theory that should work18:11
T42<b100dian> Mister_Magister, @K31j0 do you still plan to use nemo:testing:hw:asus:sake ?18:54
T42<Mister_Magister> sure but do you need it?18:55
T42<bouic> At least two of us got the issue, but we are both using the Pro1 port, maybe that command works on other phones/ports? (re @SailfishFreenodeIRCBridgeBot: <mal>in theory that ...)18:56
malare the udev rules ok?18:58
malI should merge the bootctl udev fix, some devices suffer from broken storage device node symlinks18:59
T42<b100dian> @Mister_Magister yes, to make release in the next days.19:08
T42<Mister_Magister> i mean you can release with dev repo no problem lol19:09
T42<b100dian> But I don't want to19:09
T42<Mister_Magister> but if you want sure19:09
T42<b100dian> I see tama devices use a subproject, maybe we could use that19:09
T42<Mister_Magister> oh ye19:09
T42<b100dian> Do you use the 18.1 lineage base too?19:09
T42<Mister_Magister> thats good idea19:09
T42<Mister_Magister> yee19:09
T42<Mister_Magister> oh19:10
T42<Mister_Magister> you already have access to testing19:10
T42<Mister_Magister> carryo n19:10
T42<Mister_Magister> carry on (edited)19:10
T42<b100dian> Yes, just coordinating here:)19:10
T42<Mister_Magister> kay19:10
T42<Mister_Magister> @K31j0 is currently slacking off so carry on19:10
T42<b100dian> But the question was also if you still want to build in paralel, what is the difference between the builds. What name should go in the subprojects?19:13
T42<Mister_Magister> just use the man project19:13
T42<Mister_Magister> dw about it19:13
T42<b100dian> ok19:14
T42<Mister_Magister> we will merge it at some point anyway19:14
T42<bouic> How do I check udev rules for bootctl, mal19:14
T42<b100dian> @bouic is this still FxTec Pro1?19:15
T42<bouic> Yes19:15
T42<b100dian> There should've been an lib/udev in sparse if piggz would have deemed it necessary
piggziirc, i patched bootctl back in the day19:18
T42<b100dian> but that also depends on the logcat error on bootctl command, maybe it does another breaking thing.. since it borks next boot19:22
malyeah, not sure19:22
T42<bouic> Yeah it does bork the next boot, g7 experienced it too19:24
T42<bouic> I'm not in SFOS right now but could check logcat later. How would I proceed?19:25
T42<adampigg> quite likely the udev rules could help ... but i patchet bootctl to not need them i think19:28
T42<bouic> Can I test that on device directly without having to back up my data?19:29
T42<adampigg> possibly just copy the udev rule to the right place?19:29
T42<bouic> Sure, I can try that19:30
T42<bouic> I'll check more carefully the commit mal posted to see where it should be, and try when I reboot SFOS19:30
CarbontatedCaffeineHi, I have gotten to the point where the kernel will compile without any changes. But once I apply changes to the defconfig something strange happens and I'm not completely sure why it does this.
T42<elros34> what changes?23:06
T42<elros34> I see dma, pid namespaces, f2fs and so on, which config did you enable?23:11
CarbontatedCaffeineThe one that was currently being built by the system23:15
T42<elros34> but what changes23:16
CarbontatedCaffeineSo I basically copied it, made the changes via make menuconfig23:16
CarbontatedCaffeinegive me a second to just find everything23:16
*** phlixi is now known as Guest116923:16
*** phlixi_ is now known as phlixi23:16
T42<elros34> show the diff, I hope you regenerated it first if you use menuconfig so diff will not be meaningless23:17
CarbontatedCaffeinewym regenerated?23:17
T42<elros34> show diff then you will see23:17
CarbontatedCaffeineI just copied the config back23:17
CarbontatedCaffeineto the folder23:18
CarbontatedCaffeineand marked the og one as old23:18
CarbontatedCaffeineI'm using meld23:20
CarbontatedCaffeinehow do I make a diff file lmao23:20
T42<elros34> git diff in kernel directory23:21
CarbontatedCaffeineThere you go23:24
T42<elros34> now you can see why is so important to regenerate defconfig and commit changes if you plan to use menuconfig/xconfig. How can anybody read these diff and find out your changes?23:25
CarbontatedCaffeineI don't even know how to "regenerate" defconfig23:27
T42<elros34> Anyway I see you enabled bunch of useless filesystems which are know to create issues23:28
CarbontatedCaffeineI'm just doing what the warning system told me to do23:28
CarbontatedCaffeine+CONFIG_X86_64=y +CONFIG_X86=y +CONFIG_INSTRUCTION_DECODER=y +CONFIG_PERF_EVENTS_INTEL_UNCORE=y +CONFIG_OUTPUT_FORMAT="elf64-x86-64" +CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"23:29
CarbontatedCaffeineAlso why is it x86 now :skull:23:29
T42<elros34> I suggest you to stop using menuconfig because you clearly do not know how23:29
T42<elros34> you can't start it without proper env variable otherwise you will change arch23:30
CarbontatedCaffeinehow am I supposed to keep going if I can't use menuconfig23:33
T42<elros34> like everybody else: manually fix errors and some warnings23:35
CarbontatedCaffeineI'm not silly enough to ignore "NO NOT EDIT"23:37
CarbontatedCaffeineManually editing a defconfig?23:37
T42<elros34> yes like in instruction23:37
CarbontatedCaffeineAt this point I think I might as well give up, I lack knowledge.23:38
CarbontatedCaffeineOh well23:38
T42<elros34> you lack knowledge to open file and change config_somethig=n to config_something=y?23:39
CarbontatedCaffeinecause that'll break something23:39
CarbontatedCaffeinecause *this* also depends on *that*23:40
T42<elros34> yeah like you didn't break whole defconfig now23:40
CarbontatedCaffeineand then ugh23:40
CarbontatedCaffeinefor the record, I broke it yesterday23:40
CarbontatedCaffeinealright I'll give it another go23:44
CarbontatedCaffeineit took me an hour yesterday to flick those switches23:47
CarbontatedCaffeineit was horrible23:47
CarbontatedCaffeineWait, how am I supposed to this without knowing where to put the new lines I need to add?\23:51
CarbontatedCaffeineMy grammer is getting worse the more mistakes I make omfg23:52
CarbontatedCaffeineIdk what that means23:55
T42<elros34> just example how it is easy to manually change defconfig: just put bunch of configs at the end of file23:56

Generated by 2.17.1 by Marius Gedminas - find it at!