<cruxbot>
[contrib/3.7]: postorius: initial commit, version 1.3.10
<cruxbot>
[contrib/3.7]: python3-asgiref: initial commit, version 3.7.2
<cruxbot>
[contrib/3.7]: python3-django-allauth: initial commit, version 0.61.1
<cruxbot>
[contrib/3.7]: python3-django-gravatar2: initial commit, version 1.4.4
tilman has quit [Ping timeout: 264 seconds]
tilman has joined #crux
lavaball has quit [Remote host closed the connection]
stoffepojken has quit [Quit: ZNC 1.8.2 - https://znc.in]
stoffepojken has joined #crux
brian|lfs has joined #crux
aardo has joined #crux
ardo has quit [Ping timeout: 272 seconds]
r0ni has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
r0ni has joined #crux
VolumetricSteve has joined #crux
<VolumetricSteve>
is anyone up to troubleshoot a kernel/init-time issue?
<VolumetricSteve>
I'm trying to boot an EFI-Stub kernel from a USB 3 device, I've got all the built-ins set, filesystems set, UUIDs baked into the kernel command line. My problem -seems- to be that the kernel insists that it can't find the rootfs device, and it seems apparent why, it's not getting all the way through bringing up all the usb stuff before it goes
<VolumetricSteve>
looking for the rootfs.
<VolumetricSteve>
I've tried rootwait, usb-storage.delay_use=10; about to try rootdelay out, but on "rootwait" it disabled that argument because it couldn't find the rootfs...but...I thought that argument exists to give it time to find the rootfs... anyway, usb-storage.delay_use seemed to get skipped outright, it definitely didn't seem to fail any slower or act
<VolumetricSteve>
any differently.
<VolumetricSteve>
I'm wondering if there's a way to get it to kick off usb init earlier in the process of the kernel coming up? In lieu of that, wondering if there's a way to get it to wait until the usb portion has at least had a good 30 seconds to go get an entry in /dev/
<VolumetricSteve>
I found that usb is considered hotpluggable, (makes sense) and therefore can never be counted as being "done" scanning, so it really should just need to be given more time....I think. I'm hoping someone here can tell me if I'm wrong in this assumption. Additionally, I don't think this issue is anything else... I'm hoping there isn't
<VolumetricSteve>
anything inherently wrong with an EFI-Stub kernel booting from a USB device, I can't imagine why that'd pose an issue, but I just hope I'm not fighting with an unsolvable problem because of how I'm doing it (EFI Stub) It really looks like the kernel blasts through its initialization really, really fast, and immediately panics on not being
<VolumetricSteve>
able to find the root fs.
<VolumetricSteve>
(It's a USB3 device, I have xHCI compiled as a built-in to accommodate)
<jaeger>
About to go to sleep as it's late here but I wonder if you need to use an initramfs to make that work. I would have tried the same things like rootwait, etc. as you've done but I'm also thinking of the install ISO which loads USB modules explicitly and then pauses for 10 seconds for the devices to "settle"
<jaeger>
Maybe someone else will have another idea but I'll think about it more after I've slept :)
<VolumetricSteve>
I was thinking about the Install ISO as well, I'd be perfectly happy with that behavior - I don't need this system to do very much
<jaeger>
I do see you have xHCI compiled as builtin rather than module, didn't miss that... but still could be just a timing issue
<jaeger>
And lines 293-308 where it waits for the settling with a configurable timeout
<VolumetricSteve>
I could post what's on my screen when it panics somewhere if that might help, but I'd be willing to bet some vital organs that it's a timing thing
<jaeger>
Is it a typical "unable to mount root vfs" error or something else?
<VolumetricSteve>
that's the one
<jaeger>
OK, seen that one before :)
<jaeger>
In general, I mean... never tried booting from a usb device with efistub, though
<SiFuh>
UUID
<VolumetricSteve>
yeah, I might be blazing a bit of a trail here. Dr.Google hasn't had a lot to say that I haven't had to infer against
<VolumetricSteve>
I have the UUID set "root=UUID=whatever my UUID is"
<VolumetricSteve>
anyway, ty jaeger, have a good night
<SiFuh>
And that is for / right?
<jaeger>
No problem, good luck :) ZZzz
<VolumetricSteve>
Correct, that is for /
<SiFuh>
And your filesystem is compiled into the kernel?
<VolumetricSteve>
In what sense? I have the kernel command line set "root=UUID=f9027d28-1077-4124-b037-67144aafdca9"
<VolumetricSteve>
and I have that same UUID defined in fstab, but I don't think it boots far enough for that to matter yet
<SiFuh>
And if you are not using an initramfs, then you need to compile into the kernel as well the USB stuff or as jaeger mentioned above an initrd of sorts
<SiFuh>
I boot from USB and I am using initramfs without issues except for a mysterious @ but that is another story
<VolumetricSteve>
I'm almost completely certain I have. I've got xHCI, EXT4, FAT, several USB components, the scsi over usb command protocol, just in case.... can't remember what else
<VolumetricSteve>
I'm taking a look at that guide right now
<VolumetricSteve>
It looks like I've done everything they're suggesting.. I'm double checking
<VolumetricSteve>
What I tend to hear online is that "a lot of USB stuff is typically done -after- the kernel starts" yet, people usb boot all the time, this should just be a cleaner way to do it, no bootloader, no initramfs, just a kernel and a thing to boot from
<VolumetricSteve>
I think I really just need a way to get the kernel to wait a good 30 seconds before it goes looking for rootfs
<VolumetricSteve>
I remember back in the day with early USB booting, people would have to unplug and replug their boot device to get it to be seen by the system, manually triggering a system event... I'm really hoping that's not the case here
<SiFuh>
I don't think it has anything to do with that. I think there something missing from your kernel
<VolumetricSteve>
I'm still double checking, balancing two laptops and a cat lol
<VolumetricSteve>
according to the gentoo link, I have all the right compiled-in things selected
<VolumetricSteve>
I re-enabled async scsi scanning, maybe that'll help catch it. I'll look at your config in a minute, thanks for posting it
<VolumetricSteve>
huh, usb-storage.delay_use seems to have no effect at all
<VolumetricSteve>
I can't find any examples of it on the command line, so I've tried it at the start of the line and at the end, neither seems to do anything to slow down kernel startup
<VolumetricSteve>
This sure seems to be saying I need rootdelay. I'm trying that again.... but it sure seems like my kernel command lines largely get ignored or skipped somehow, despite being built-in
<VolumetricSteve>
if this fails I'll read line by line through your config, SiFuh
<VolumetricSteve>
Okay! rootdelay decided to work this time... no idea what that's about... now, onto a new issue.. It's still kernel panic'ing
<VolumetricSteve>
Now, it's actually showing the correct devices, my flash drive (showing up as sdb) it shows the two partitions, sdb1 and sdb2
<VolumetricSteve>
VFS: Cannot open root device "UUID=my really long UUID" or unknown-block(0,0): error -6
<VolumetricSteve>
then, it goes on to show the 4 partitions present in my system, the two for sda, which is fine and the two for my usb boot device
<VolumetricSteve>
the annoying part now is that I've checked multiple times now, the UUID I've specified is -exactly- as it appears in this error message where it prints the partitions it can see
<VolumetricSteve>
I can't tell from any of the guides online if I'm actually supposed to put "UUID=" in my kernel command line like:
<VolumetricSteve>
root=UUID=the really long ID string
<VolumetricSteve>
I'm trying to OCR what I'm seeing with chatgpt, this friggin Sora video stuff has totally tanked their system...
<VolumetricSteve>
sd 2:0:0:0: [sdb] Attached SCSI removable disk
<VolumetricSteve>
VFS: Cannot open root device "UUID=fb68b20e-f838-6b40-96cd-14443f7c2c8d" or unknown-block(0,0): error -6
<VolumetricSteve>
Please append a correct "root=" boot option; here are the available partitions:
<VolumetricSteve>
There's all of the immediately relevant stuff... as far as I can tell, holding my UUID kernel line up to the line that matches sdb2... as far as I can tell, that's definitely the same UUID and I have no idea how this isn't working at this point...
<VolumetricSteve>
If it's showing me the available partitions, that suggests to me it's not able to match my string to what it thinks it actually has. Yet, they are, in fact, the identical.
<SiFuh>
Or your filesystem is a module in the kernel and can't be loaded
<VolumetricSteve>
It's built-in, EXT4 and FAT both are
<VolumetricSteve>
according to this ancient thing, I need to use PARTUUID instead??
<VolumetricSteve>
it's weird that it says UUID isn't available this early in the boot process but PARTUUID is... yet the error I get from the kernel, as far as I can tell, provides me with UUIDs... not PARTUUIDs...
DesRoin has joined #crux
<VolumetricSteve>
ohh... maybe I found a kernel bug... or more like a typo...
<VolumetricSteve>
The error I get labels things that it spits out there as UUIDs, but I just checked, it's actually showing me PARTUUIDs for my system
<VolumetricSteve>
my string is correct, I put the PARTUUID in my kernel, and that's why it matches what's in the error.. but the error message only speaks of UUIDs... that's... rife for confusion..
<VolumetricSteve>
HAH... okay... that's the magic combination.
<VolumetricSteve>
If you boot without initramfs, you need to use the PARTUUID, and if you're doing so from USB, you need rootdelay=X (where X is some number of seconds)
<VolumetricSteve>
It just booted.. EFI-Stub from USB definitely works
VolumetricSteve has quit [Ping timeout: 264 seconds]
lavaball has joined #crux
stoffepojken has quit [Quit: ZNC 1.8.2 - https://znc.in]
stoffepojken has joined #crux
<cruxbot>
[core/3.7]: libffi: updated to version 3.4.6
<cruxbot>
[opt/3.7]: firefox-bin: updated to version 3.4.6
dlcusa_ has joined #crux
dlcusa has quit [Ping timeout: 264 seconds]
dlcusa__ has joined #crux
dlcusa_ has quit [Ping timeout: 246 seconds]
<cruxbot>
[opt/3.7]: samba: updated to version 4.19.5
chrcav has quit [Ping timeout: 256 seconds]
chrcav has joined #crux
lavaball has quit [Remote host closed the connection]
aardo has quit [Ping timeout: 252 seconds]
serpente has joined #crux
<serpente>
i ve being maintaining some orphaned ports on my repo (covil), but it vanished from the portdb, n1?
<jaeger>
Looks like the portdb updater is a little broken, will look into it
<SiFuh>
jaeger: also ppetrov^ mentioned the same as above but with his repo r4-modules
<serpente>
alright
<jaeger>
Most of the time I think the python 2 -> 3 changes are decent but man they made urllib much more annoying
dlcusa__ is now known as dlcusa
stoffepojken_ has joined #crux
stoffepojken has quit [Ping timeout: 255 seconds]
<jaeger>
OK, in addition to python 2 -> 3 shenanigans it looks like an older version of the portdb cacher was restored for some reason. Should have it fixed soon
deltahotel has joined #crux
<jaeger>
OK, they're back. Thanks for the reports.
<serpente>
ok, all good! just tested
<jaeger>
cool
zorz_ has joined #crux
stoffepojken has joined #crux
stoffepojken_ has quit [Ping timeout: 264 seconds]
jue has joined #crux
lavaball has joined #crux
stoffepojken_ has joined #crux
stoffepojken has quit [Ping timeout: 264 seconds]
deltahote1 has joined #crux
deltahotel has quit [Ping timeout: 256 seconds]
stoffepojken_ has quit [Client Quit]
stoffepojken has joined #crux
tarxvfz has joined #crux
deltahote1 has quit [Quit: deltahote1]
deltahotel has joined #crux
tarxvfz has quit [Ping timeout: 255 seconds]
stoffepojken has quit [Quit: ZNC 1.8.2 - https://znc.in]
stoffepojken has joined #crux
tarxvfz has joined #crux
stoffepojken has quit [Quit: ZNC 1.8.2 - https://znc.in]
stoffepojken has joined #crux
deltahotel has quit [Ping timeout: 264 seconds]
crash_ has quit [Ping timeout: 255 seconds]
crash_ has joined #crux
tarxvfz has quit [Quit: tarxvfz]
crash_ has quit [Remote host closed the connection]
crash_ has joined #crux
<cruxbot>
[opt/3.7]: unison: updated to version 2.53.4
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
VolumetricSteve has joined #crux
<jaeger>
VolumetricSteve: I saw in the log you got it working, nice
DesRoin has quit [Quit: WeeChat 4.2.1]
DesRoin has joined #crux
<VolumetricSteve>
curious point of note: I suggested to the kernel bug/enhancements group that they make the error output of VFS more clear, since they already say "partitions" I figured it wouldn't be a stretch for them to say PARTUUIDs in there... they inform me that "The kernel doesn't work neither with UUIDs, nor with PARTUUIDs, it opens devices directly
<VolumetricSteve>
which is the job of your initrd." and they closed my suggestion outright -_-
<VolumetricSteve>
jaeger also thank you, almost went and copied the crux installer process, but we're good
<VolumetricSteve>
and now I'm just left wondering... 100% of what I did to fix this was squarely within the kernel, and the kernel people tell me that's not a thing, but now it works. all of it on the kernel built-in command line
<jaeger>
Interesting... even though there was no initrd/initramfs used?
<VolumetricSteve>
yeah, they just decided to ignore that lol
<jaeger>
Yeah, sounds like someone didn't know what they were talking about
<VolumetricSteve>
lol maybe I'll just go and suggest an edit directly to the source file that changes the wording of only that error
<VolumetricSteve>
like if they're gounna say "partitions" and then list a bunch of partuuids... it just seems like they could put the term "partuuid" on the screen somewhere
<jaeger>
indeed
<VolumetricSteve>
anywho, I'm just glad I can do super thin usb boots now and never have to think about like syslinux or any of the ISO booting weirdness... seems like it'd be advantageous for installers, perhaps. One less layer of code and process to deal with.
<VolumetricSteve>
and this doesn't preclude you from using initramfs either
<jaeger>
Yeah, definitely nice to have the options
<VolumetricSteve>
thanks again for the guidance, I'm off to bash my head against the wall on the next problem
VolumetricSteve has quit [Quit: Connection closed]