Hello!
I am running a initrd make with mkinitcpio using the "systemd" hook.
This works great in general, but after a bit of playing with the hooks and systemd code the generated initrd will no longer start. That is no big deal and entirely my fault and I should be able to fix it. My problem is now that I can not really debug the initrd anymore.
Is there a way to get a debug shell on the initrd when using the systemd hook? Any hints would be greatly appreciated:-)
Best Regards, Tobias
On Wed, Sep 24, 2014 at 12:38 AM, Tobias Hunger tobias.hunger@gmail.com wrote:
Hello!
I am running a initrd make with mkinitcpio using the "systemd" hook.
This works great in general, but after a bit of playing with the hooks and systemd code the generated initrd will no longer start. That is no big deal and entirely my fault and I should be able to fix it. My problem is now that I can not really debug the initrd anymore.
Is there a way to get a debug shell on the initrd when using the systemd hook? Any hints would be greatly appreciated:-)
Best Regards, Tobias
Thanks for the pointer. I just removed the init= setting from /etc/default/grub and added the systemd hook to mkinitcpio.conf. I generated both the bootloader config and the initcpio. However, I still wonder, because my machine boots just fine this way. Thinking more closely about the issue as you present it, usually, if things go wrong in the inticpio stage you get thrown to a shell to fix stuff manually. As it does not looks like this seems to be the case, your new_root appears to get mounted and the issue appears to be somewhere else... You also did not provide any error message or other pointer which would lead us to the source of your problem, and I think you should add anything you have (eg. remove the "quiet" boot option).
cheers! mar77i
Hi Matti,
On Wed, Sep 24, 2014 at 9:20 AM, Martti Kühne mysatyre@gmail.com wrote:
Thanks for the pointer. I just removed the init= setting from /etc/default/grub and added the systemd hook to mkinitcpio.conf. I generated both the bootloader config and the initcpio.
Yeap, that part works fine for me, too. Make sure to use the "sd-*" variant of the HOOKS if available. The arch wiki is unfortunately a bit lacking wrt. mkinitcpio and systemd:-/
It e.g. suggests to add the "base" hook before "systemd", to get a debug environment... That will indeed install some binaries, but then the systemd hook will overwrite the init script with systemd and thus remove the normal options to trigger a debug shell in the initrd.
However, I still wonder, because my machine boots just fine this way.
So does mine till I start to tinker with it:-)
Thinking more closely about the issue as you present it, usually, if things go wrong in the inticpio stage you get thrown to a shell to fix stuff manually.
That is no longer the case once I enable the "systemd" hook (I do have the "base" hook before the "systemd" one).
As it does not looks like this seems to be the case, your new_root appears to get mounted and the issue appears to be somewhere else...
You are correct, but how did you gather that from my original mail? :-)
Systemd claims to have mounted / and /usr. It then proceeds to tear down services it started as part of the initrd and tries to pivot root. Everything perfectly normal up to that point.
Then it fails with "/bin/sh not found".
Most likely either / or /usr is not mounted properly. A quick "ls" should point me into the right direction, but how do I get a debug shell?
You also did not provide any error message or other pointer which would lead us to the source of your problem, and I think you should add anything you have (eg. remove the "quiet" boot option).
I have to admit that I did not think about removing "quiet" this morning:-/ Shame on me.
My question is basically how to get the a debug shell in an initrd created by mkinitcpio with the "systemd" hook enabled?
The long and involved way is most likely to make sure the systemd-debug-generator will be added to the initrd by the "systemd" hook, together with a modified debug-shell.service that actually is started during the initrd (and not only afterwards).
Then I should be able to enable that debug shell with the kernel parameters documented for the systemd-debug-generator.
Is there a simpler way, involving less hacking?
Best Regards, Tobias
On Wed, Sep 24, 2014 at 9:51 AM, Tobias Hunger tobias.hunger@gmail.com wrote:
Then it fails with "/bin/sh not found".
As new_root is mounted (/bin/sh is there in the initrd), where /bin is a symlink to /usr/bin, this should be obvious...
You also did not provide any error message or other pointer which would lead us to the source of your problem, and I think you should add anything you have (eg. remove the "quiet" boot option).
I have to admit that I did not think about removing "quiet" this morning:-/ Shame on me.
My question is basically how to get the a debug shell in an initrd created by mkinitcpio with the "systemd" hook enabled?
The long and involved way is most likely to make sure the systemd-debug-generator will be added to the initrd by the "systemd" hook, together with a modified debug-shell.service that actually is started during the initrd (and not only afterwards).
Then I should be able to enable that debug shell with the kernel parameters documented for the systemd-debug-generator.
Is there a simpler way, involving less hacking?
With /usr not correctly mounted, you might want to check fstab and arch-chroot to the current setup and try mount -a? Maybe somehow pull busybox into / before you chroot, so you have everything you need while in the dark ages...
cheers! mar77i
On Wed, Sep 24, 2014 at 1:02 PM, Martti Kühne mysatyre@gmail.com wrote:
On Wed, Sep 24, 2014 at 9:51 AM, Tobias Hunger tobias.hunger@gmail.com wrote:
Then it fails with "/bin/sh not found".
As new_root is mounted (/bin/sh is there in the initrd), where /bin is a symlink to /usr/bin, this should be obvious...
Yeap. I just need to check what ended up being mounted where and what the .mount units that got generated actually look like.
That is why I am asking wether somebody knows how to get a debug shell.
<snip>
With /usr not correctly mounted, you might want to check fstab and arch-chroot to the current setup and try mount -a?
There is no /usr in fstab:-) Getting /usr mounted based on /proc/cmdline is what I am experimenting with and I might just have ended up messing up the mount options, getting me something else on /usr than whatever I expect.
My C-foo is a bit rusty, so who knows what I actually put into my patched version of systemd-fstab-generator that I have on that initrd;-)
Maybe somehow pull busybox into / before you chroot, so you have everything you need while in the dark ages...
chroot works fine, once I manually mounted the root and /usr FS to some directory.
I guess the next stop is getting a debug shell into the initrd. "man systemd-debug-generator" should have all the information I need for that, I hope.
But first I need to check whether removing "quiet" has any useful effect.
Best Regards, Tobias
Ha, found it!
I gave the wrong subvol to mount:-/ Stupid mistake, pretty much as expected.
Martti: Thanks for your help!
Best Regards, Tobias
On Wed, Sep 24, 2014 at 1:47 PM, Tobias Hunger tobias.hunger@gmail.com wrote:
My C-foo is a bit rusty, so who knows what I actually put into my patched version of systemd-fstab-generator that I have on that initrd;-)
I was planning to complain already. Try not to insult people trying to help you like that...
cheers! mar77i
Hi Martti,
It was definitely not my intention to be rude. I am sorry if I gave that impression.
Thanks again for taking the time to help me!
Best Regards, Tobias
On Thu, Sep 25, 2014 at 9:32 AM, Martti Kühne mysatyre@gmail.com wrote:
On Wed, Sep 24, 2014 at 1:47 PM, Tobias Hunger tobias.hunger@gmail.com wrote:
My C-foo is a bit rusty, so who knows what I actually put into my patched version of systemd-fstab-generator that I have on that initrd;-)
I was planning to complain already. Try not to insult people trying to help you like that...
cheers! mar77i
hi tobias,
I wasn't taking you rude. But implying you were using custom packages while we're trying to debug an issue is generally seen as a serious undermining of any help... Such things are to be mentioned beforehand, since the basic assumption is a repo install.
cheers! mar77i
Hi Martti,
I did mention that I have been playing with the hooks and systemd in my initial mail. At least I thought that would be clear. Sorry if it was not. I will try to make that more clear next time. Was my first post here, I only joined this list recently.
My question about how to open a debug shell is not effected by my changes in any way.
Best Regards, Tobias
On Sep 25, 2014 3:28 PM, "Martti Kühne" mysatyre@gmail.com wrote:
hi tobias,
I wasn't taking you rude. But implying you were using custom packages while we're trying to debug an issue is generally seen as a serious undermining of any help... Such things are to be mentioned beforehand, since the basic assumption is a repo install.
cheers! mar77i
On Thu, Sep 25, 2014 at 7:21 PM, Tobias Hunger tobias.hunger@gmail.com wrote:
Hi Martti,
I did mention that I have been playing with the hooks and systemd in my initial mail. At least I thought that would be clear. Sorry if it was not. I will try to make that more clear next time. Was my first post here, I only joined this list recently.
My question about how to open a debug shell is not effected by my changes in any way.
That said, I'm sorry. I should have just told you to test without your changes and been done with it.
cheers! mar77i
arch-general@lists.archlinux.org