<Guest9824>
as these are always required to boot, made them as built-ins and not modules
<Guest9824>
thanks to SiFuh and ukky for helping me out go in the right direction.
<Guest9824>
SiFuh: when you say 'I myself used VM;s' - why are you not using them anymore?
<SiFuh>
I used a dedicated box for building. However, it has a problem now. It keeps shutting down.
<Guest9824>
i see. thanks for the information
<Guest9824>
SiFuh: one more question if it's not a problem.
<SiFuh>
OpenBSD nfs server has no problem. 6:43PM up 206 days, 18:29, 2 users, load averages: 4.30, 4.17, 4.20
<Guest9824>
my initramfs now boots, however, i'd like to use /dev/disk/by-uuid in initramfs rather than /dev/nvme0n1 and /dev/nvme1n1, for this to work it should be enough to create device with same major and minor block numbers or with 'cp -a' and add them to initramfs?
<SiFuh>
Mine is APPEND root=/dev/mapper/machupo-root rw rd.auto=1 net.ifnames=0 quiet
<Guest9824>
i'll need to read about rd.auto=1
<SiFuh>
luks enc_root= <-- I do not use this
<Guest9824>
is rd.auto something specific to dracut?
<Guest9824>
because it appears it is, and i don't use dracut for my small initramfs
<SiFuh>
It's a kernel option
<Guest9824>
im unable to find anything related to rd.auto about kernel
lavaball has joined #crux
<SiFuh>
rd.auto rd.auto=1 enable autoassembly of special devices like cryptoLUKS, dmraid, mdraid or lvm. Default is off as of dracut version >=024.
<SiFuh>
Hmm maybe it is. Let me check
<Guest9824>
got it. but why is dracut mentioned everythwere.
<SiFuh>
Seems you are correct.
<Guest9824>
hmmm...
<Guest9824>
im not sure if using udev in initramfs should be the right way to deal with this problem, in case dm-0 is not always the first/faster/main slot and dm-1 being the second/slower/additional slot
<farkuhar>
ukky, here's my simple-minded attempt at implementing Mark Rosenstand's 15-year-old suggestion: https://dpaste.com/6FMD83MJD
<farkuhar>
tested once, as a regular user with write-permission on the repo passed as argument. Will need further testing to see how it handles multiple repos and drivers.
<ukky>
farkuhar: I will test your patch, observe results and report back when done.
<ppetrov^>
farkuhar, is the idea that ports and prt-get eventually get "merged"?
<farkuhar>
But as noted, it's a 15-year-old proposal that has been left dormant for a while.
<ppetrov^>
yep
<ppetrov^>
in a way, i kinda like the separation
<ppetrov^>
but sth like prt-get sync would be nice
<ppetrov^>
pkg-get sync exists
groovy2shoes has quit [Ping timeout: 268 seconds]
<farkuhar>
ppetrov^: pkg-get sync was actually a strong motivation. The more parallelism between the commands, the less likely it is that muscle memory will produce a nonsensical command.
groovy2shoes has joined #crux
<ppetrov^>
yep, makes sense
<farkuhar>
speaking of pkg-get ... after the breakage stemming from the icu update, r0ni inquired about adding the -fr option (force reinstall) to pkg-get. I'm not sure how many CRUX users would take advantage of it, but there's no harm in letting pkg-get do something intelligent when it sees the -fr flag.
<ppetrov^>
i would, for sure, benefit
ppetrov^ has quit [Quit: Leaving]
groovy2shoes has quit [Remote host closed the connection]