00:27 <Jasper[m]> <Segfault[m]> "i tried reseating it *many..." <- Tried putting it in a different device and updating the firmware,m

00:27 <Jasper[m]> *?

05:52 <travmurav[m]> louist103: is there any reason you use acpi instead of DT to boot c630?

06:18 <louist103> @travmurav Thats what it was doing by default. I didn't even know you could change that

06:20 <travmurav[m]> louist103: you probably want to get a dtb file for c630 (should be in the kernel package) and boot with that: either use a directive in your bootloader (i.e. "devicetree <file>" for grub) or via kernel cmdline (I think it's dtb=<file>)

06:20 <louist103> Can that be done on the live cD?

06:20 <travmurav[m]> assuming it's not /actually/ a CD, can probably copy the dtb to it and edit the bootloader config on the fly

06:21 <louist103> I'll have to try that. Could that fix the keyboard and Wifi issue?

06:21 <travmurav[m]> (as in, I guess might want to format the usb stick to fat and copy files to it at worst)

06:21 <travmurav[m]> I'd expect so

06:22 <travmurav[m]> don't think there is much work being done for acpi on qcom given how hard it is and considering we use dt for everything so far, which works quite well

06:27 <louist103> Is the partition for the main part of the live cd not ext4? My main linux machine can't read it for some reason

06:29 <travmurav[m]> I'd assume the actual rootfs is some kind of squashfs file or something like that, if not even just in the initramfs

06:46 <louist103_> Do you know where the grub config is once you boot into the CD? I couldn't get the drive mounted correctly

06:49 <travmurav[m]> I'm afraid I'm not familiar with how gentoo installer works, they may as well use some other bootloader than grub...

06:50 <louist103_> I'm pretty sure it said "grub" when I booted. I'll do some poking tomorrow. Its pretty late now. Thanks for this information.

06:51 <travmurav[m]> louist103_: but I believe all you need to do is to get a dtb file from the kernel package the installer would use (so I expect it to be in the squashfs/whatever it has), put it into the fat fs for uefi and edit grub config to list it, then

10:00 <jhovold> Here's an updated wip branch for the X13s:

10:00 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.8-rc7

10:01 <jhovold> Changes include:

10:01 <jhovold> - fix camera clock controller array out-of-bounds issue

10:01 <jhovold> - usb dwc3 multiport support v15

10:23 <Nios34> Hi there! I have a Galaxy Book Go arrived last day. Will it really brick if I destory the Windows on it?

10:25 <Nios34> It's a second hand one. And it has Windows 10 professional preinstalled with Windows Update enabled. It looks kinda werid.

10:26 <Jasper[m]> Nios34: Not necessarily, but it may take some messing around with drivers to get a new install to work

10:31 <Nios34> ah so it will be tough to install it back?

10:31 <Jasper[m]> Nios34: Might be a little bit

10:31 <Jasper[m]> But just to be sure

10:31 <Nios34> I don't know much about UFS yet. Will `dd' the entire disk do the trick?

10:31 <Jasper[m]> Can you share a screenshot of the partitions that are on the device?

10:32 <Jasper[m]> Just the windows disk partitioning tool should be fine

10:33 <Nios34> Disk 0: 250M efi, 60.69 GB C: NTFS, 58.93 GB D: NTFS

10:34 <Jasper[m]> Sounds good, but do you also have a screenshot? Just to be sure that you don't nuke the UEFI

10:34 <Nios34> iirc, on debian, it shows something like /dev/sd[a-e]. And I have zero idea about why

10:35 <Jasper[m]> Nios34: That's what I'm trying to find out hahaha

10:37 <Nios34> https://0.vern.cc/nD.jpg

10:38 <Jasper[m]> Nios34: That looks okay

10:38 <Jasper[m]> Make sure the sdX matches the one that these partitions are on

10:40 <Jasper[m]> Some UFS based machines don't have the firmware on separate storage or on a protected UFS LUN. In that case you should try to only partition the LUN that has windows on it

10:41 <Nios34> Okay, so I will be fine if I don't mess around with other partitions?

10:43 <Nios34> Will it work like in USB drive when installed on UFS?

10:44 <Nios34> I was thinking about making an Arch Linux Arm with kernel maintained by hexdump0815 or maybe debootstrap a Debian.

10:45 <Jasper[m]> Nios34: I think so, just the EFI and two NTFS partitions you showed should be okay to mess with

10:45 <Jasper[m]> Make sure to backup your drivers somewhere for now.

10:46 <Jasper[m]> Nios34: Depends on if the kernel you're trying to install has UFS support I guess.

10:47 <Nios34> OK, thank you very much. xD

10:51 <Jasper[m]> No problem, please let us know if you run into any issues

14:21 <steev> huh, and now I hit the ath11k crash again (with .23 firmware)

14:25 <jglathe__> same here on .37

14:27 <jglathe__> 3rd day up

14:30 <steev> https://paste.debian.net/1309416/ look similar?

14:30 <steev> oh mine is pm resume

14:32 <jglathe_x13s> and an AER immediatily before that

14:32 <steev> yeah but that's common

14:33 <jglathe_x13s> as far as I understood jhovold not with the adjutments in the dts for L0s

14:38 <jhovold> steev: try updating to the latest fw which is supposed to fix some such ath11k fw crashes on resume

14:39 <jhovold> jglathe_x13s (and steev): if you still see such crashes with .37, then please report it on the kernel bugzilla so that upstream is aware of it

14:41 <jhovold> jglathe_x13s: and yes, I disabed L0s also for the NVMe in my wip branches since 6.8-rc6 (looks like steev is running 6.7.8)

14:42 <steev> si, that's 6.7, i haven't yet made the config changes, so haven't pushed out my 6.8

16:56 <clover[m]> please lmk when you do steev

17:36 <_[m]123> 6.7.7 - link training dpe -> forget about it

17:46 <_[m]123> 6.5.5 is fine seems kind of

18:17 <hexdump0815> Nios34: in case you read this offline - my latest image should have working ufs support, but i never tested it for writing - it should work i guess as it seems to work well on similar devices, but be awaere that there is a small remaining risk

18:18 <hexdump0815> Nios34: better only touch that one sdx device with the windows stuff on it and leave the others alone as they seem to contain some "magic" stuff

18:20 <hexdump0815> Nios34: please report back how it works and as already mentioned: backup the drivers from windows first (see doc subdir of the 7c dir in my repo) and i think one can even create some windows restore disk from within windows

18:21 <hexdump0815> Nios34: i think there is no really well working generic arm64 windows installer like there is for x86, so you might end up not being able to reinstall windows once you delete it

18:23 <jglathe_> From Windows you can also use minitool ShadowMaker to create a complete image. Was my safety net for the aarch64 devices. Odd, but powerful software, and works even in emulation.

19:01 <hexdump0815> jglathe_: how does it work - i.e. is it possible to boot some arm64 device with it to restore a disk worst case?

19:06 <Jasper[m]> <hexdump0815> "Nios34: i think there is no..." <- Nope, but you can fetch all of the drivers from windows update and merge them with a generic arm64 iso using dism

19:06 <Jasper[m]> Worst case scenario that is

19:07 <Jasper[m]> Easiest is to backup the drivers beforehand

19:17 <jglathe_> hexdump0815, Nios34: it makes a complete image of the drive. In the emergency case, and if you can physically remove the drive, you can restore it on a different machine (partition wise, or completely). And it runs the same on x64 for that matter. I tested it serveral times because..reasons. Tedious but works

19:22 <jglathe_> Did my move from 512GB to 1TB (and 1TB to 2TB) that way

19:24 <jglathe_> booting aarch64 to restore - nope. So all physically non-removable disks are harder to restore. There it is dd all the way I guess

19:26 <jglathe_> They do some typical sector-wise image, full, differential, incremental images. QT5 GUI, IMO a bit autistic. But it does the job.

19:26 <hexdump0815> jglathe_: ah ok - but that would then not help for devices with usually non removable emmc or ufs storage

19:45 <jglathe_> yep