King_InuYasha has quit [Read error: Connection reset by peer]
nirik has quit [Ping timeout: 252 seconds]
<somlo>
seems I celebrated too soon -- the system booted to the `fedora-riscv login:` prompt, but using either `root` or `riscv` users to log in gets me "no shell: Permission denied"
<somlo>
I did recreate the /boot and / partitions on a larger image, rsync-ed the contents of /boot and / from the downloaded raw image, and adjusted the UUIDs in /etc/fstab and on the kernel command line
<somlo>
that did it for the f33 image in the past, did I miss any new tricks for f37?
<somlo>
such as some sort of btrfs double-vision thing where / and /home are somehow "sharing" the same physical partition?
<somlo>
(although it was ext4 in /etc/fstab, and no mention of a /home "view" or partition, so maybe some other thing I failed to notice?
nirik has joined #fedora-riscv
<somlo>
is this SELinux screwing me over in some way? If so, is there anything I can do while I have the target root partition mounted via qemu-nbd to re-label it properly? Or some argument to `rsync` that also copies SELinux labels over to the target partition?
<somlo>
hmmm... I'll try again tomorrow using `rsync -aX`, and hope for the best :)
<somlo>
getting errors when doing `rsync -aX src/ dest/` from the downloaded raw image to the larger destination
<somlo>
is there a canonical way to grow the raw image while preserving all the selinux stuff without all the pain and suffering I seem to be running into? :)
nirik has quit [Ping timeout: 268 seconds]
nirik has joined #fedora-riscv
nirik has quit [Ping timeout: 260 seconds]
<somlo>
so using `-X` with rsync is not the way; I used "regular" `rsync -a` and temporarily appended "systemd.unit=multi-user.target enforcing=0" to the kernel command line
<somlo>
that got me the text-mode login prompt, and a successful root login
<somlo>
ran `systemctl set-default multi-user.target` (which should allow me to get rid of "systemd.unit=multi-user.target" on the kernel cmdline)
<somlo>
now running `restorecon -Rp /`, which will *hopefully* allow me to boot in enforcing mode and actually still be able to log in :)
<somlo>
will find out in the morning if that worked, need some sleep now
<davidlt[m]>
Yes, SELinux is enabled. You can disable it via kernel command line now. I thing very recent kernels might not allow to do it via user-space.
<davidlt[m]>
If you modify files/add files you might need to relabel.
<davidlt[m]>
virt-builder typically does that (expand and relabel) based on your needs.
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<somlo>
I've tried using virt-builder before and got a bit lost. Besides, when I have to create a sdcard for litex, the /boot partition will have to be FAT and the partition table MSDOS, so I'll end up having to rsync (and relabel) anyway
<davidlt[m]>
ah, I see, so modifications are required
<somlo>
and I'm happy to report that my process (explicit multi-user.target for text mode and enforcing=0) worked -- after setting the systemd target manually and relabeling, I can now boot without those command line options
<davidlt[m]>
Yeah, SELinux is a bit annoying because of that relabeling if you touch anything outside.
<somlo>
ok, now that I have a *modern* riscv64 fedora (f37) I'll need to build a kernel with the liteUART irq patches, and see if I can still boot it on the fpga, fingers crossed
<davidlt[m]>
Was your patchset approved? I recall multiple versions, but don't recall if everything got approved and it landed.
<somlo>
right, I didn't want `selinux=0` which completely disables it; `autorelabel=1` didn't work for me (tried it, so I know :); What worked was `enforcing=0` which brought everything up in permissive mode, but still selinux aware so I could relabel manually and get it to work OK on subsequent boot, in actual enforcing mode
<somlo>
yeah, patchset is percolating through the tty-next tree, according to Jiri Slaby
<davidlt[m]>
Which kernel version is targeted? 6.2?
<somlo>
don't know, didn't think to ask specifically. sent a direct email asking "besides your r/b, do I still need to do anything?", to which I got back "no, just wait" :)
<somlo>
so all I know is "yes, *eventually*" :D
<davidlt[m]>
Did you check specific tree branches? or linux-next in general?
<somlo>
I'm lazily doing "git pull" on my clone of `tty-next`, last time was about a week ago, and nothing yet. I should try again today...
<davidlt[m]>
That's how I do. I just check all relevant trees + branches to understand if things are picked up, and which kernel version might have it.
nirik has joined #fedora-riscv
<somlo>
davidlt[m]: btw, the backup URL in fedora-riscv64.repo is wrong: "...repo/fedora/f37/latest/..." -- should be "...fedora/37/latest...", without the "f" in "f37"
<somlo>
also, nothing yet in tty-next re. LiteUART -- current tag is "v6.2-rc1"; I'll probably ping jirislaby in (late) january if nothing shows up by then :)
<somlo>
a bunch of repos besides fedora-riscv.repo are enabled in /etc/yum.repos.d/ and causing errors when using dnf; I set them all (except fedora-riscv.repo) to "enabled=0"
<davidlt[m]>
yes, you need to disable them
<davidlt[m]>
I forgot to do that at a time
<somlo>
trying to `dnf install <something>` from the remaining "Fedora RISC-V" repo seems to take a long time
<davidlt[m]>
Well, it was never fast to begin with :)
<davidlt[m]>
Maybe DNF5 could improve things in the future.
<somlo>
eventually, it became obvious it's actually working, so we're all good :)
esv_ has joined #fedora-riscv
esv has quit [Read error: Connection reset by peer]