**** BEGIN LOGGING AT Thu Apr 04 02:59:57 2019
Apr 04 17:48:58 <ubptgbot> <powderedtoastman9000> Where is the systemd configuration files in the halium build tree?
Apr 04 17:49:08 <ubptgbot> <UniversalSuperBox> Halium does not build systemd
Apr 04 17:49:22 <ubptgbot> <UniversalSuperBox> Any configuration would be on the rootfs
Apr 04 17:50:52 <ubptgbot> <powderedtoastman9000> Rhetorical question, why do the docs list tools for checking configs to support systemd in your kernel
Apr 04 17:51:15 <ubptgbot> <powderedtoastman9000> I know the answer is because some might use non halium rootfs
Apr 04 17:51:15 <ubptgbot> <UniversalSuperBox> Because systemd support in kernel is needed to build systemd
Apr 04 17:51:27 <ubptgbot> <UniversalSuperBox> [Edit] Because systemd support in kernel is needed to use systemd
Apr 04 17:52:30 <ubptgbot> <powderedtoastman9000> Yeah, I just think I wasted a short amount of time preparing for systemd because the docs made it seem like a necessary step and I was planning to get halium userspace working before moving onto UT
Apr 04 17:52:51 <ubptgbot> <UniversalSuperBox> Well if you're trying to get the Halium rootfs working then you need systemd support
Apr 04 17:53:04 <ubptgbot> <UniversalSuperBox> And most of the things needed for systemd support are also needed for lxc container support anyway
Apr 04 17:53:15 <ubptgbot> <powderedtoastman9000> Okay, I thought you were saying I didn't need it and I felt like an idiot
Apr 04 17:53:35 <ubptgbot> <UniversalSuperBox> But you're asking where the systemd configuration files are, which there are none
Apr 04 17:53:59 <ubptgbot> <powderedtoastman9000> They would be in the rootfs then right?
Apr 04 17:54:15 <ubptgbot> <powderedtoastman9000> So to edit them I should edit the rootfs I think
Apr 04 17:54:17 <ubptgbot> <UniversalSuperBox> Yes. Machine specific configuration should be done in `/etc/systemd/`
Apr 04 17:54:24 <ubptgbot> <UniversalSuperBox> But what exactly is going wrong?
Apr 04 17:55:01 <ubptgbot> <powderedtoastman9000> Nothing, I just want to make a log daemon that starts before systemd init the system boot process
Apr 04 17:55:40 <ubptgbot> <UniversalSuperBox> Systemd is PID 1, so that seems like a highly unlikely prospect
Apr 04 17:55:54 <ubptgbot> <powderedtoastman9000> Because right now when I only get logs up until fiklesystems are mounted then it cuts out from halium-boot
Apr 04 17:56:09 <ubptgbot> <UniversalSuperBox> You haven't even gotten to systemd yet
Apr 04 17:58:02 <ubptgbot> <powderedtoastman9000> Well, I don't know where I'm getting to right now is the issue, because halium-boot stops outputting serial console over USB after file systems are mounted
Apr 04 17:58:59 <ubptgbot> <UniversalSuperBox> Is the device rebooting?
Apr 04 17:59:31 <ubptgbot> <powderedtoastman9000> No, it runs and I can detect the USB connection is active and error free on the PC side of the cable
Apr 04 18:00:24 <ubptgbot> <powderedtoastman9000> I just need logs to know what is going on now in the device, so starting a log daemon, since you say is impossible before systemd, then as the first service booted, seems a logical step to take
Apr 04 18:00:49 <ubptgbot> <UniversalSuperBox> Do you not have `/sys/pstore` available?
Apr 04 18:01:18 <ubptgbot> <powderedtoastman9000> I don't remember and the device isn't flashed right now to check, I'll make a note to check for it
Apr 04 18:01:52 <ubptgbot> <powderedtoastman9000> Thanks, @UniversalSuperBox
Apr 04 18:02:04 <ubptgbot> <UniversalSuperBox> Oh, if you're using halium-boot with the normal rootfs you'll need to create `/data/.writable_image`
Apr 04 18:02:38 <ubptgbot> <powderedtoastman9000> What should that file contain and where can I find an example?
Apr 04 18:03:09 <ubptgbot> <powderedtoastman9000> I didn't see making that file in the docs
Apr 04 18:03:14 <ubptgbot> <UniversalSuperBox> It should exist
Apr 04 18:03:52 <ubptgbot> <UniversalSuperBox> @powderedtoastman9000 [I didn't see making that file in the docs], There isn't much about halium-boot in the docs at all
Apr 04 18:04:25 <ubptgbot> <UniversalSuperBox> Neither the reference rootfs nor Plasma Mobile (to my knowledge) use it, so the docs can't be updated yet
Apr 04 18:04:26 <ubptgbot> <powderedtoastman9000> On halium-boot preinit you mean? Cause I have no terminal access and only know it's working by lsusb
Apr 04 18:04:39 <ubptgbot> <UniversalSuperBox> No, create the file from recovery.
Apr 04 18:04:58 <ubptgbot> <UniversalSuperBox> Then as soon as it boots it'll start logging to `/var/log/` as normal. Reboot and read your logs from the image
Apr 04 18:04:59 <ubptgbot> <powderedtoastman9000> Oh, just a touch, or does it need contents?
Apr 04 18:05:05 <ubptgbot> <UniversalSuperBox> Just a touch
Apr 04 18:05:13 <ubptgbot> <UniversalSuperBox> https://github.com/Halium/initramfs-tools-halium/blob/9639316ad8417bf4270b7cd9bb4ec62655dc4232/scripts/halium#L500
Apr 04 18:05:35 <ubptgbot> <powderedtoastman9000> Thanks dalton. I'll do that next,  you answered a few helpful questions
Apr 04 18:05:57 <ubptgbot> <powderedtoastman9000> Gonna compile and flash the thing again and do those suggestions
Apr 04 18:06:35 <ubptgbot> <UniversalSuperBox> You can probably also write a systemd unit to cause a kernel panic accidentally on purpose if you aren't able to get kernel messages for some reason
Apr 04 18:07:52 <ubptgbot> <powderedtoastman9000> I am able to get kernel in preinit of halium-boot but not once I trigger it to init, which is annoying because heimdall/samsung doesn't allow reboot with an arg like preinit
Apr 04 18:08:28 <ubptgbot> <powderedtoastman9000> I could mess with the bootloader, but that contains the download mode to flash so it's too risky to he worth it
Apr 04 18:09:11 <ubptgbot> <UniversalSuperBox> No, don't mess with the bootloader. See if you can get the logs first.
Apr 04 18:11:28 <ubptgbot> <powderedtoastman9000> Yeah, that is the logical way to proceed, although I would like to make a Samsung boot system like multi rom, just already committed to too many things
Apr 04 20:49:57 <ubptgbot> Sup was added by: Sup
Apr 04 21:36:43 <ubptgbot> <powderedtoastman9000> Whoever is in charge of documentation, the error thrown by halium-install with message saying likely not enough room of device, but this same error happens when your rootfs tarball is corrupt
Apr 04 21:37:28 <ubptgbot> <powderedtoastman9000> I got halium fully booting now and staying running without crashing and boot looping,
Apr 04 22:49:26 <ubptgbot> <ilyaishere> @powderedtoastman9000 [Whoever is in charge of documentation, the error thrown by halium-install with m …], https://github.com/Halium/docs
Apr 04 22:50:07 <ubptgbot> <powderedtoastman9000> I know where the docs are, I was suggesting to make a note of that error and how it may be misleading
Apr 04 23:18:49 <ubptgbot> <UniversalSuperBox> @powderedtoastman9000 [I know where the docs are, I was suggesting to make a note of that error and how …], He was saying that you can fix it
Apr 04 23:19:32 <ubptgbot> <UniversalSuperBox> It's all public text. And rst is neat
Apr 04 23:20:36 <ubptgbot> <powderedtoastman9000> Oh, okay
Apr 04 23:20:50 <ubptgbot> <powderedtoastman9000> I didn't know the docs were editable by anyone
Apr 04 23:25:14 <ubptgbot> <UniversalSuperBox> Yep! They are neat.
Apr 04 23:31:06 <ubptgbot> <powderedtoastman9000> I will see if I can reproduce the issue so I can define the error message in my doc update post, because it's so many screens ago that my terminal doesn't have it in scrolling
Apr 04 23:35:42 <ubptgbot> <powderedtoastman9000> Should I be using an android 7.x rom for getting my blobs? Or is TheMuppests vendor tree all I need? Like I was using the phone for a few days with android on it, and I did a full wipe of partitions and flashed 8.0 onto it, and it was somewhat working, it didn't lock up or boot loop, and was detectable from the PC it was plug
Apr 04 23:35:42 <ubptgbot> ged into, but now I can't get it to boot despite having changed nothing since I last tested it. Only thing I can think is that I wiped partitions, I'm going to flash back android to it because I know I wiped the blobs which is why I think it's crashing now. Previous I was able to boot it, but I used the replace android script instead of wiping ever
Apr 04 23:35:42 <ubptgbot> ything
Apr 04 23:36:44 <ubptgbot> <powderedtoastman9000> I'm wondering if using the 8.0 rom for getting back what I wiped would work or should I download 7.0 ROM from Samsung to get the stuff I'm pretty sure is causing the issues
Apr 04 23:36:44 <ubptgbot> <NotKit> TheMuppets is fine if you have it
Apr 04 23:37:47 <ubptgbot> <powderedtoastman9000> I have the muppets, but I didn't change anything when it was working, even today I had it working. Then I wiped every partition visible from TWRP, and reflashed and the same code same build, is bootlooping
Apr 04 23:38:00 <ubptgbot> <NotKit> better flash 7.0 ROM to make sure there are no weird things like newer bootloader with 8.0 that can't boot 7.0 and so on (but that is very rare)
Apr 04 23:40:01 <ubptgbot> <powderedtoastman9000> Okay, the config I'm set up for is to use the 8.0 bootloader though, which was needed fixing to boot via Samsung bootloader. I also suspect that this hidden.img from the 8.0 rom could be wiped along with system and I'm trying to figure out how I broke it so I can know how to fix it
Apr 04 23:41:12 <ubptgbot> <powderedtoastman9000> I'm gonna download 7.0, but I had it set up for the latest build bootloader which was 8.0, I'll have to disassemble the 7.0 bootloader and figure out if they use the same mechanisms and options
Apr 04 23:41:44 <ubptgbot> <powderedtoastman9000> Like, I had to modify the kernel to force override the kernel boot command line args that the bootloader passed
Apr 05 00:13:23 <ubptgbot> <powderedtoastman9000> Okay, the issue was I switched versions of GCC from 6 to 8 and 8 isn't mature enough to produce a working kernel or other binaries. I am gonna try 7.3 now because 7 added a lot of optimization over 6
**** ENDING LOGGING AT Fri Apr 05 02:59:57 2019