Refracta Development, Scripts, etc.
Post a reply

Re: Going with the systemd flow . . . or not?

Sat Nov 29, 2014 2:35 am

Interesting comment on #debianfork:
it was when fsmithread [sic], the dev for refracta, dzz, the dev for exegnu, and clefebver, the dev for mint, were here all having an issue making live isos that would boot a sysv init live system

Anything come out of that brainstorming?

Re: Going with the systemd flow . . . or not?

Sat Nov 29, 2014 2:42 am

Observations with the live-boot? util-linux? bug so far:

Newer util-linux (2.25x) works in an installation. Live images (more than one totally different, made in different ways, which worked before) were observed to boot beyond the point of mounting the root filesystem but no tty prompt appears. Unless booting to single user mode, in which case it's then possible to switch runlevel normally.

Downgrading udev and sysvinit makes no difference. The only fix is to downgrade util-linux. Not necessarily it's "sub-packages" (libblkid1, libmount1 et al).

This behaviour was the same with the "official" version (requiring libsystemd0 for bsdutils) as a custom-compiled suite with *systemd* disabled. I see no related bug reports for util-linux nor live-boot.

Note that official Debian policy is, although sysvinit will not be default it will be supported for Jessie (or so they say).

Re: Going with the systemd flow . . . or not?

Sat Nov 29, 2014 1:26 pm

I'm not able to boot single user mode on the snapshots that hang at knfsd. Other than that, the behavior is as you describe - no console prompt. I tried adding single, S, 1, and init=/sbin/init to the boot line with no effect. I even tried systemd.unit=rescue, just to see if the newer incantation works. It didn't. I can boot to shell with init=/bin/bash, but then I can't change runlevel.

Edit: Maybe the difference is due to your re-packaged packages? I might be able to test that later today or tomorrow.

Edit2: BTW, next version of refractasnapshot, "quiet" will be gone! Never needed to remove it before now, everything always worked so well. (Also, it suppresses system messages in the console.)

Re: Going with the systemd flow . . . or not?

Sun Nov 30, 2014 3:20 pm

I'm testing mostly (at the moment) using jessv-nox in virtualbox on a wheezy host. Of course I have to at least dist-upgrade and rebuild it, I'm using a (now fairly well tested) custom script and a chroot to do that.

The ttys are not being made. I can't explain why you are unable to get a console prompt using "1" on cmdline but I can.

Results are the same with no custom-compiled packages at all. My custom util-linux works in an installation as does the official one, i checked this multiple times.

Interestingly Im getting similar trouble with the latest (original) GRML iso which uses util-linux 2.25x

Need to try an older kernel next to rule that out.

Re: Going with the systemd flow . . . or not?

Wed Dec 03, 2014 2:01 am

More tests: I get a prompt using "init=/bin/bash" From there it can be seen that /dev is empty. If then:

Code:
service udev start
exec /sbin/init

bootup continues apparently normal. I'm guessing /dev is not getting moved over from initramfs as it should.. why not is another matter.

No difference with a 3.17 kernel.

EDIT: "Installing knfsd" is the last line in dmesg, seen after booting as described. That is not the actual problem.

Re: Going with the systemd flow . . . or not?

Wed Dec 03, 2014 3:14 am

dzz wrote:
Code:
service udev start
exec /sbin/init

bootup continues apparently normal. I'm guessing /dev is not getting moved over from initramfs as it should.. why not is another matter.


I can confirm that this works. It finished booting.

There's no /dev in the initrd. It should get regenerated every boot. Apparently, it does get regenerated when udev is started. What normally starts udev? I just looked at it in sysv-rc-conf, and there are no symlinks for it - in jessie or in wheezy.

Re: Going with the systemd flow . . . or not?

Wed Dec 03, 2014 1:29 pm

This process doesn't seem very well documented, had to mostly work it out for myself. If anyone knows some good links explaining this in detail please do say. I guess most users are not interested.

The relevant scripts are in (/usr/share/initramfs-tools/) init-top and init-bottom. They all get copied to initrd on update.

Udev starts in initramfs, creates and populates /dev there. Then it is moved to the real rootfs, symlinked back to initramfs while it is still needed, then udevd is stopped.

After switching to the real rootfs and /sbin/init invoked, udev is one of the first scripts to start, from rcS.d

If you start e.g. the original jessv-nox with "init=/bin/bash" you can verify that /dev is already populated (including the ttys) before anything in rcS.d has run.

EDIT: Another interesting test. Make a simple custom script "/sbin/custom_init":

Code:
#!/bin/bash

set -x
echo "Starting custom init script..."
service udev start
exec /sbin/init

(chmod +x it) After rebuilding squash and iso, it boots apparently normal with "init=/sbin/custom_init" on cmdline.

Re: Going with the systemd flow . . . or not?

Sat Dec 13, 2014 3:44 am

I tried newer util-linux (2.25) with older udev, libgudev and libudev (208-7). Didn't help.
Then upgraded udev and tried a suggestion from max2344:
insserv -v -r -f nfs-common
insserv -v -d -f nfs-common
That didn't change it, either. Snapshot still stalls in the same place.

Re: Going with the systemd flow . . . or not?

Sat Dec 13, 2014 2:19 pm

In the initrd main script /init (derived from /usr/share/initramfs-tools/) the mounts for proc and sys get moved to "real" rootfs just before switch_root is called. If I edit the script to symlink them back (making them still available to intramfs till the last moment) everything works.

Original /init :
Code:
# Move virtual filesystems over to the real filesystem
mount -n -o move /sys ${rootmnt}/sys
mount -n -o move /proc ${rootmnt}/proc


Edited /init :
Code:
# Move virtual filesystems over to the real filesystem
mount -n -o move /sys ${rootmnt}/sys
nuke /sys
ln -s ${rootmnt}/sys /sys

mount -n -o move /proc ${rootmnt}/proc
nuke /proc
ln -s ${rootmnt}/proc /proc


Maybe this is the wrong thread, there's no evidence this problem is to do with systemd.

Re: Going with the systemd flow . . . or not?

Sat Dec 13, 2014 5:01 pm

dzz wrote:Edited /init :
Code:
# Move virtual filesystems over to the real filesystem
mount -n -o move /sys ${rootmnt}/sys
nuke /sys
ln -s ${rootmnt}/sys /sys

mount -n -o move /proc ${rootmnt}/proc
nuke /proc
ln -s ${rootmnt}/proc /proc



Well, maybe it has nothing to do with systemd, but we've been talking about this problem for the last two pages, so this is the right thread. And somehow it relates to systemd, because the problem goes away if systemd is installed.

Tested your fix, and it works here.
Post a reply