device-helper blocking

[FriendlyNeighborhoodShane]

Hello creator!

First of all, let me thank you for this project. I'm new to kernel DIYing, and the whole initramfs thing was almost incomprehensible because of all of the convoluted things mainstream distros do, almost too scary to dabble in. It's been nice to have this system you can look at and tinker with yourself.

While setting it up for myself, I found a blocking bug in the device-helper script along with a potential false failure in the init.

How to reproduce: have a CD drive in your system

Procedure: After running for about one or two minutes, the init script got an EXIT signal (the panic message was unexpected error) and it dropped me into an interactive shell. I played around a bit and used the cmdline breakpoints to figure out that it was failing somewhere in setup_devmgr. Played around some more, entered the commands in the init script by hand and saw that device-helper was going into a infinite waiting loop on /dev/sr0. It never got a successful blkid read on it, which is expected, it doesn't even give one on booted systems.

Solution: added a special case exit in device-helper for sr*dev_name (probably a very dirty hack)

Also worth looking into is the EXIT signal init was getting about 2 minutes after boot. While no (working) boot process should ever last this long, it may be symptomatic of another problem. All I could figure out was that at the time I was thrown into the interactive shell, device-helper for sr0 was still running, and some time later, udevadm got tired of it and killed it itself.

Thanks and good luck!

[illiliti]

First of all thanks for kind words!

First of all, let me think you for this project. I'm new to kernel DIYing, and the whole initramfs thing was almost incomprehensible because of all of the convoluted things mainstream distros do, almost too scary to dabble in. It's been nice to have this system you can look at and tinker with yourself.

That's main reason why i wrote tinyramfs. I was always hated how dracut or mkinitcpio complicates their configurations. Second reason is portability issues. Mkinitcpio always was unportable due to udev dependency and gnuisms...Same thing for dracut, it contains millions of unnecessary bashism. Their claim about "Init script written in POSIX shell" is false because they(developers) uses local variables which is not POSIX(yash, pbosh, mrsh, etc... doesn't support local). It also depends on libkmod. I don't talk about genkernel, mkinitrd, mkinitramfs, ... because they have same issues or distro-specific dependencies(not portable at all).

While setting it up for myself, I found a blocking bug in the device-helper script along with a potential false failure in the init.

Thank you for very detailed bug report. I'm currently a little bit busy because i'm working on a huge update for tinyramfs(see #7 ) and another one project for community... I will include fix for this issue in next update

[FriendlyNeighborhoodShane]

Welcome! I'll be eagerly looking forward to when you're satisfied enough with this to include it in community, or perhaps even extras.

[illiliti]

Should be fixed, can you confirm?

[FriendlyNeighborhoodShane]

Yup, thank you so much, it's working perfectly now!

BTW was root filesystem autodetection removed intentionally? The config still says it will be done, but it isn't anymore :P

[illiliti]

Nope, it should work. At least it works for me (f2fs)

[FriendlyNeighborhoodShane]

Ah nevermind, my bad, it is working :P

Thanks again!