Skip to main content ↑ ↓
Topic: /sbin/init does not exist (Read 885 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

/sbin/init does not exist


I raised this in another thread involving fs issues, thinking that it had been caused by those issues. WRONG (i think), them fs probs were one thing, this /sbin/init is another.

I use 5 distros and to keep things HALF sane I get grub to write out boot code always under the same system, the one I'm most familiar with: Suse-Leap   ..which uses systemd :-(

- ALL my fstabs list partitions strictly by uuid, there isn't a single reference to dev-names anywhere

- When I boot Leap the system SSD will show up in diskfree as either /dev/sda OR /dev/sdb

- IF the second condition applies i.e. /dev/sdb AND it's in that session that I get grub to do its thing THEN threre's a high probability of subsequent boot failures of OTHER systems (mostly Artix & Devuan, hardly ever Slackware and never Suse Leap/Tumbleweed). Beats the living crêpe-suzette out of me but that's what's coming down.

I had this happen just before checking in here so *on-spec* I booted back to Leap, this time verified that the system disk WAS in fact showiing up as /dev/sda, and repeated the grub boot routine. The next boot of Artix was this one with no issues at all.

What's up?  Seems to me that since the issue turns south when running Leap, it's gotta be a Leap OR a grub-under-Leap problem. It's waaaaaay over my head but I WOULD like to fix it.


 
Who, has loved us more?

Re: /sbin/init does not exist

Reply #1 –
when i was stationed in korea as a soldier at the hospital in seoul i was taught some korean.  Literally if you ask a person if they speak korea, what you are really asking is do korean words exist.  The implication is do they exists with them.  You is understood, assumed.  When you ask them if the are well you literally ask them if good health exists.  And again you is the understood.  When you say /sbin/init does not exist, i'll assume you me yours.  But as i look at my sbin folder i have a symlink named init that points to dinit-init, so it both exists and does not exist on my system.

Of course i know nothing to help you as i am the inspector closseau  of this board.  But i did bumble my way through a web search and found this about that.

https://unix.stackexchange.com/questions/367385/sbin-init-does-not-exist

and that person had some wonky file system where /usr was on a separate partition from root and then didn't mount it properly.
So i have to ask you to please post your partitioning scheme in the mean time, while you wait for actual help to arrive. 
Code: [Select]
  lsblk

ps.  i had that probelm befor where a drive would jump between sdX and sdY on boot up.  Drove me nuts and like you i used strict uuids for everything, still do...  now if i could only remember what i was told to do by that very knowing person..

Cat Herders of Linux

Re: /sbin/init does not exist

Reply #2 –
Quote from: cat herders of linux – on
when i was stationed in korea as a soldier at the hospital in seoul i was taught some korean.  Literally if you ask a person if they speak korea, what you are really asking is do korean words exist.  The implication is do they exists with them.  You is understood, assumed.  When you ask them if the are well you literally ask them if good health exists.  And again you is the understood.  When you say /sbin/init does not exist, i'll assume you me yours.  But as i look at my sbin folder i have a symlink named init that points to dinit-init, so it both exists and does not exist on my system.

Of course i know nothing to help you as i am the inspector closseau  of this board.  But i did bumble my way through a web search and found this about that.

https://unix.stackexchange.com/questions/367385/sbin-init-does-not-exist

and that person had some wonky file system where /usr was on a separate partition from root and then didn't mount it properly.
So i have to ask you to please post your partitioning scheme in the mean time, while you wait for actual help to arrive. 
Code: [Select]
  lsblk

ps.  i had that probelm befor where a drive would jump between sdX and sdY on boot up.  Drove me nuts and like you i used strict uuids for everything, still do...  now if i could only remember what i was told to do by that very knowing person..



I don't even know if the error arises from grub, systemd ot the kernel (nowadays the former two are trynig to be kernels at all cost) :-)

The problem is that /sbin/init is being sought on the wrong partition and that SOMEHOW links back to the fact that when I was getting grub to write boot code to the disk root AT THAT TIME the uuid of the partition to boot on ssd sata-1 was showing up as  /dev/sdb. But when the next boot begins that same partition on ssd sata-1 is then showing up as /dev/sda. This, at least is what I can guess at being totally clueless about the real situation.  

Code: [Select]
# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 931.5G  0 disk 
├─sda1    8:1    0   100G  0 part 
├─sda2    8:2    0   100G  0 part /
├─sda3    8:3    0   100G  0 part 
├─sda4    8:4    0   100G  0 part 
├─sda5    8:5    0   100G  0 part 
├─sda6    8:6    0   100G  0 part 
├─sda7    8:7    0   100G  0 part 
├─sda8    8:8    0   100G  0 part 
├─sda9    8:9    0   100G  0 part 
├─sda10   8:10   0     4G  0 part [SWAP]
└─sda11   8:11   0     1G  0 part 
sdb       8:16   0   1.8T  0 disk 
└─sdb1    8:17   0   1.8T  0 part /0/dx
sdc       8:32   1  57.8G  0 disk 
└─sdc1    8:33   1  57.8G  0 part 
sr0      11:0    1  1024M  0 rom 

The problem seems to be born when the above shows sdb1 to sdb11 because of all my 5 installations Suse is the only one on which I have ever seen this happen, on all others the ssd on sata-1 is ALWAYS /dev/sda.

I spent years fighting uuid but all I had to do was stop using Suse and dev-name would STILL do the job A1. For now I'm trying to get into the habbit of checking with fdisk or kdiskfree BEFORE invoking grub, if the disk is /dev/sdb then I reboot Suse and do the grub number only when I see /dev/sda. When I remember to do this the problem doesn't come up.

 


Who, has loved us more?

Re: /sbin/init does not exist

Reply #3 –
artix would be the one to run grub if it were my pc..

also if you used an nvme drive you could skip the sdX sdY name jumping because you d be running from /dev/nvme0n1pX and not /dev/sdX

if one isn't baked into your board get a nvme adapter for an 4 lane pcie slot.  a 1 tb nvme drive is 100$ish

that was what the smart person told me to do (me)

but you have to see if the nvme will boot from pci on your bios if you don't have a dedicated slot.  and if not then you could always set up a usb drive with your uefi for booting.. maybe..
Cat Herders of Linux

Re: /sbin/init does not exist

Reply #4 –
Quote from: cat herders of linux – on
artix would be the one to run grub if it were my pc..

also if you used an nvme drive you could skip the sdX sdY name jumping because you d be running from /dev/nvme0n1pX and not /dev/sdX

if one isn't baked into your board get a nvme adapter for an 4 lane pcie slot.  a 1 tb nvme drive is 100$ish

that was what the smart person told me to do (me)

but you have to see if the nvme will boot from pci on your bios if you don't have a dedicated slot.  and if not then you could always set up a usb drive with your uefi for booting.. maybe..

For now I'm doing grub from Suse-Leap because I'm more familiar with it (2 clicks in Yast, done). Which is not to say that I won't some day try it from Artix, especially since Leap (according to rumors) is on death-row and Tumbleweed being at times unstable bleeding-edge I don't really weant to trust booting to it :-)
 
All my drives are in mobile-trays, that way when I leave to overnight somewhere all that's left is an empty box. I wouldn't change this for the world.


Who, has loved us more?
 

Re: /sbin/init does not exist

Reply #5 –
One thing I don't like about grub (there are many things) is the situation you describe where one systems install is almost the 'master' install as it has the grub.conf that sets up the boot options for all the other installs.
It can get confusing.

One advantage rEFInd has over grub (there are many) is you can have one refind.conf in the refind directory it installs into your EFI partition which has the common settings for rEFInd.

But where you wish to have specific boot options for a install / kernel those settings go in a file refind_linux.conf in the same directory as the kernel being booted. So normally /boot/refind_linux.conf.
So for each system install you can easily change its boot options just by editing a text file. Rather than having to boot into the grub master install, changing settings and running grub-mkconfig.
But even without a refind_linux.conf next to a kernel rEFInd normally comes up with sane defaults which will boot the kernel.

You can create a rEFInd USB and try it from that.

Old but relevant, in the rEFInd devs words, discussion of the advantages and disadvantages of rEFInd vs grub.
https://askubuntu.com/questions/760875/any-downside-to-using-refind-instead-of-grub/760971#760971

TLDR
Try rEFInd

Re: /sbin/init does not exist

Reply #6 –
for a normal modern PC rEFInd is definitely superior, however i've played around with the coreboot payload of GRUB, you can create a dummy config, it has the option to automatically search for available configs and load any kernel from anywhere in any partition and boot the respective system! Any Linux distro and OBSD worked like that, it was seamless and worked every time. But yeah unfortunately not many PCs get to enjoy coreboot as i would've liked, even though firmware loading grub without actually booting would be always more "secure" than uefi.

Re: /sbin/init does not exist

Reply #7 –
Quote from: gripped – on
One thing I don't like about grub (there are many things) is the situation you describe where one systems install is almost the 'master' install as it has the grub.conf that sets up the boot options for all the other installs.
It can get confusing.

One advantage rEFInd has over grub (there are many) is you can have one refind.conf in the refind directory it installs into your EFI partition which has the common settings for rEFInd.

But where you wish to have specific boot options for a install / kernel those settings go in a file refind_linux.conf in the same directory as the kernel being booted. So normally /boot/refind_linux.conf.
So for each system install you can easily change its boot options just by editing a text file. Rather than having to boot into the grub master install, changing settings and running grub-mkconfig.
But even without a refind_linux.conf next to a kernel rEFInd normally comes up with sane defaults which will boot the kernel.

You can create a rEFInd USB and try it from that.

Old but relevant, in the rEFInd devs words, discussion of the advantages and disadvantages of rEFInd vs grub.
https://askubuntu.com/questions/760875/any-downside-to-using-refind-instead-of-grub/760971#760971

TLDR
Try rEFInd

Thanks, you and Hitman are giving me tons of new material to digest. I just (and finally) cought the beast with it's pants down so for now I think I know how to avoid the problem even if I don't know what it is. Until I do know it's more of a genertal Linux question and I posted it in alt.os.linux so if you would please respond there, it does NOT seem to be an Artix issue, sorry for the initial insinuation. 

Message-ID: <[email protected]>
Who, has loved us more?