<mbohun[m]>
(on my HiFive Unmatched PC) yesterday: `dmesg -T | nc termbin.com 9999` => https://termbin.com/6gfx
<mbohun[m]>
There seem to be some "weird" problem with changing the `riscv` user's password? like i change the password, reboot the PC, and the user riscv password is reset back to that default (fedora_rocks!) password
Eighth_Doctor has left #fedora-riscv [#fedora-riscv]
<davidlt[m]>
mbohun: that shouldn't be the case. You you try to sync before rebooting?
<mbohun[m]>
no, i just did `passwd` and entered new password
<mbohun[m]>
in fact i tried already 3 times:
<mbohun[m]>
- riscv user changing their password
<mbohun[m]>
- su changing riscv user's passwor
<mbohun[m]>
- today after i installed GNOME, i tried to to change the password through the GUI
<mbohun[m]>
I am going to test something, like i am going to add the `riscv` user to some group like "dialout" or whatever and then reboot the PC, and check if that additional group was persisted
<mbohun[m]>
meh maybe not, i was just confused by those "GNOME mounts" at the bottom, previously i had an issue when `/boot` partition was correctly mounted from the nvme0n1p1, but the `/` partition was incorrectly pointing to mmcblk0p2
davidlt has joined #fedora-riscv
<mbohun[m]>
I am worried i could have introduce some problem, while i was "re-sizing" the nvme partitions, basically that i could made some file read-only, have to retest again, i think i am getting irrational and paranoid
<davidlt[m]>
My advice is avoid having /boot on different boot media
<davidlt[m]>
So if you are using NVMe, keep firmware-only on microSD or SPI-NOR Flash.
<davidlt[m]>
It sounds that you have full setups on microSD card and NVMe, and that could lead to some annoying issues.
<mbohun[m]>
<davidlt[m]> "So if you are using NVMe, keep..." <- my HiFive Unmatched is in a hard-to-access casing, so i did not yet play with those jumpers to setup a boot without microSD
<davidlt[m]>
Also there are two /boot partitions with legacy boot flag set now. That shouldn't be an issue as there is a boot order, but systemd might not like non unique UUIDs, etc.
<mbohun[m]>
what should i do to fix that?
<davidlt[m]>
Remember that rootfs is mounted based on UUIDs.
<davidlt[m]>
So maybe you are changing the password, but it's on a wrong thing.
<davidlt[m]>
Nuke all partitions (expect fimware) on microSD card.
<davidlt[m]>
Or just flash mmc-firmware image into microSD, whichever is easier.
<mbohun[m]>
Is there a fedora rawhide for `SiFive VisionFive v1` ? I know there is ubuntu for it, but i am kinda avoiding ubuntu, the ubuntu for HiFive Unmatched was running some ancient kernel, couldn't poweroff, nor reboot
<davidlt[m]>
For V1 no. That probably will never get proper upstream support (?).
<davidlt[m]>
V2 will be supported.
<mbohun[m]>
i want to try to use that VisionFive v1 for a "dashcam" system, basically hook cams and maybe some sensor-s to it
<davidlt[m]>
I advice against that.
<davidlt[m]>
JH7100 was basically a test chip. It has L2 bug, it has stuff connected to a wrong port on the SoC.
<mbohun[m]>
oh :-(
<davidlt[m]>
It's not even manufactured anymore. It's a limited run thing.
<davidlt[m]>
V2 is the real thing (hopefully).
<mbohun[m]>
well, i have only: Unmatched, VisionFive v1, and nezha; i saw the article that VisionFive v2 is now ready for order
<davidlt[m]>
Pre-order.
<mbohun[m]>
yes, i noticed that, i shipping starts from DEC for the simpler/crappier version
<mbohun[m]>
no matter what i try after a reboot, or halt/start, riscv's password is back to fedora_rocks!
<Esmil>
mbohun[m]: maybe your /etc/fstab doesn't point to the right mount for /, so it's still mounted read-only
Esmil[m] has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt[m]>
That's strange. Sadly I cannot test it right now (but your are the 1st one ever to report something like that).
* davidlt[m]
testing new fans, thermals, etc.
<mbohun[m]>
Is there a wiki page / install guide for installing fedora rawhide no HiFive Unmatched?
<mbohun[m]>
- I am more than willing to redo the installation from scratch; unfortunately the docs i read were not very nvme specific, and the fedora wiki page actually mentions only the Unleashed (not Unmatched)
<mbohun[m]>
- Even give you ssh access to that box I was using today, if you like.
<davidlt[m]>
Wiki is outdated right now. README.md next to the disk images is the newest information (and specific to that disk image, i.e. Unmatched).
<davidlt[m]>
Yes, these are the latest images we have right now, but that should be changed to F37 sooner than later I guess (depends how fast I am).
<mbohun[m]>
yup, that is the README.md file i was using, but it not very detailed about that nvme isntallation, the mmc installation was without any problems - although that was just an intermediate step to have a look, etc.
<mbohun[m]>
i am more than happy to help with updating documentation
<davidlt[m]>
I don't need SSH access to your personal box. If you want to connect your Unmatched to Fedora/RISCV Koji infrastructure I still don't need SSH access. I could provide information/create certs/etc for that if you are interested.
<davidlt[m]>
If you have FAS accounts (Fedora Account System) you most likely directly can modify Fedora Wiki :)
<davidlt[m]>
There are some policy rules (Fedora specific) at which point you get permissions to edit wiki pages directly IIRC.
chuangzhu has quit [Quit: Bridge terminating on SIGTERM]
mhroncok has quit [Quit: Bridge terminating on SIGTERM]
Kevinsadminaccou has quit [Quit: Bridge terminating on SIGTERM]
davidlt[m] has quit [Quit: Bridge terminating on SIGTERM]
Esmil[m] has quit [Quit: Bridge terminating on SIGTERM]
RichardJones[m]1 has quit [Quit: Bridge terminating on SIGTERM]
mbohun[m] has quit [Quit: Bridge terminating on SIGTERM]
nirik[m] has quit [Quit: Bridge terminating on SIGTERM]
jim-wilson[m] has quit [Quit: Bridge terminating on SIGTERM]
acharles has quit [Quit: Bridge terminating on SIGTERM]
defolos has quit [Quit: Bridge terminating on SIGTERM]
varlad[m] has quit [Quit: Bridge terminating on SIGTERM]
leah2 has quit [Ping timeout: 264 seconds]
chuangzhu has joined #fedora-riscv
Kevinsadminaccou has joined #fedora-riscv
defolos has joined #fedora-riscv
acharles has joined #fedora-riscv
jim-wilson[m] has joined #fedora-riscv
Esmil[m] has joined #fedora-riscv
masami has joined #fedora-riscv
nirik[m] has joined #fedora-riscv
varlad[m] has joined #fedora-riscv
mbohun[m] has joined #fedora-riscv
mhroncok has joined #fedora-riscv
davidlt[m] has joined #fedora-riscv
RichardJones[m] has joined #fedora-riscv
leah2 has joined #fedora-riscv
<somlo>
davidlt[m]: so i simply did a `touch drivers/tty/serial/liteuart.c` followed by `make` to see what would happen :)
<somlo>
took 7 hours (I did not use -j8, silly me :) and there was one line reading "BTF [M] every/single/module.ko" for, well, every single module :D
<somlo>
I'll try again with -j8 to see if that's any faster (probably still going to take a few hours)
<davidlt[m]>
somlo: ouch, that's painful :)
<somlo>
I was hoping once everything is built, make will be smart enough to save some time, but I guess we're well past that in practice, since on "real" hardware it's probably not even noticeable as an "issue" :D
cyberpear has quit [Quit: Connection closed for inactivity]
nirik[m] has quit [*.net *.split]
nirik[m] has joined #fedora-riscv
cyberpear has joined #fedora-riscv
davidlt has quit [Ping timeout: 268 seconds]
rwmjones_ is now known as rwmjones
jcajka has quit [Quit: Leaving]
davidlt has joined #fedora-riscv
<somlo>
davidlt: "only" 2 hours with `make -j8` -- even though a single file (built-in driver, *not* module) was touched, make did the whole "BTF" thing on every single .ko module. All such modules now have different checksums w.r.t. the previous `make [modules_insall]` run -- although the new kernel binary seems to load the old modules just fine, so they weren't modified in a *meaningful* way :)
<davidlt[m]>
somlo: for the kernel modules that works because the kernel version doesn't change IIR.
<davidlt[m]>
somlo: you could try looking into ccache too.
davidlt has quit [Ping timeout: 268 seconds]
<somlo>
huh... but wouldn't ccache help only with "CC ..." and not with this "BTF" stuff? I don't think there's a `gcc` command behind the per-module "BTF" thing, whatever that is -- I may have to look into *that* first :)
<javierm>
somlo: you could disable by not setting CONFIG_DEBUG_INFO_BTF in your .config
<javierm>
somlo: for ccache I use the following: export ARCH=riscv CROSS_COMPILE="ccache riscv64-linux-gnu-"
iooi has quit [Ping timeout: 248 seconds]
iooi has joined #fedora-riscv
<somlo>
javierm: I was beginning to formulate a thought that maybe that whole BTF thing might be optional --thanks for fast-tracking that for me! :)
<somlo>
I'll probably have to rebuild the whole kernel one more time after turning that off, but if that ends up working OK with fedora it will most likely result in a (much) faster test/rebuild cycle time :)
<javierm>
somlo: no worries. I usually disable so that I can rebuild a kernel module to test with an existing kernel image
<javierm>
i.e: make M=drivers/gpu/drm/solomon/
<javierm>
and then cp drivers/gpu/drm/solomon/ssd130x.ko /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/solomon/