On Mon, 24 Apr 2017 14:49:06 +1000, Ralph wrote in message
<be1216c5-c463-a069-b1e4-f405ee658809@???>:

>
> Arnt Karlsen wrote on 24/04/17 09:13:
> > On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message
> > <20170419185407.228cd18a@???>:
> >
> >> On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message
> >> <d3a264ce-a767-dffc-845d-d1eb26027a3e@???>:
> >>
> >>>
> >>>
> >>> Arnt Karlsen wrote on 19/04/17 23:17:
> >>> [cut]
> >>>>
> >>>> ...wiped udev off my box and wound up with a box that boots oh
> >>>> soo fine until it tries to load my new vdev
> >>>> initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try
> >>>> this on a rt kernel?
> >>>>
> >>>> ..recovery ideas? Do we have any vdev live-cd?
> >>>>
> >>>> ..last time I did this stunt, I chrooted in off a Knoppix? iso,
> >>>> I have memdisk and a few iso links handy in /boot, and Debian's
> >>>> Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
> >>>> vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
> >>>> depend on a working install of udev AFAIK, and I'd prefer pushing
> >>>> thru with vdev rather than going back to udev.
> >>>>
> >>>> ..has anyone here tried downgrading to Debian Wheezy era udev?
> >>>>
> >>>>
> >>>> ..looking for recovery live-cd idea starting points, I came
> >>>> across 32-bit
> >>>> https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
> >>>> which could work both as a starting point for a live-cd and as a
> >>>> starting point for an upgrade path for stuck Debian Wheezy people
> >>>> via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.
> >>>>
> >>>> ..according to https://debiandog.github.io/doglinux/ "DebianDog
> >>>> is very small Debian Live CD shaped to look and act like Puppy
> >>>> Linux. Debian structure and Debian behaviour are untouched and
> >>>> Debian documentation is 100% valid for DebianDog. You have
> >>>> access to all debian repositories using apt-get or synaptic.",
> >>>> creating "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their
> >>>> repos for ours, update, upgrade and remaster, the 64-bit version
> >>>> likely needs to be built off deb-src lines.
> >>>>
> >>>>
> >>>> ..but first comes the classic chicken-and-egg 64 bit recovery
> >>>> I need now. ;o)
> >>>>
> >>>
> >>> I'm not sure it helps you, but I've made a vdev variant of most
> >>> recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
> >>> 2017-Mar-27 20:57) that I got from the official mirror
> >>> http://mirror.sfo12.us.leaseweb.net/devuan/
> >>>
> >>> I purged a couple of things from it, then added and installed "my"
> >>> vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into
> >>> devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is
> >>> downloadable at https://www.uk.realsam.co.uk/files/devuan/
> >>>
> >>> It boots with vdev rather than udev, and udev remains installed,
> >>> though with all its "competing" files tucked away. As you might
> >>> know, this vdev packaging is different from aitor's packaging for
> >>> gnuinos by not declaring a udev competition, but rather attempting
> >>> to manage a dynamic choice of which one is in use. The software is
> >>> otherwise the same, I believe.
> >>
> >> ..thanks, we shall find out. ;o)
> >
> > ..no joy this far, vdev does not work with any of my installed
> > kernels, neither my dpkg variant of your vdev-assistant nor your
> > original restores udev, so I'm stuck with live-CDs when I need to
> > go online to chk things to read up on.
> >
> > ..you packaged your vdev differently than aitor, do I then use
> > your deb(-src) lines in /etc/apt/sources.list and comment out
> > his?
> >
> > ..another approach is ignore apt and dpkg, and simply drop in all
> > files with tar or cpio or somesuch, haven't done that kinda stunt
> > since my RH-5.2 days.
> >
> > ..if that fails, are you able to build me an old fashion monster
> > monolithic kernel with nouveau, vdev and everything else compiled
> > into the kernel, and not as modules, that I can boot without an
> > initrd?
> > Big size is no problem, I have 8GB ram, but no build box.
> >
> > ..if not, what do I need to build a vdev kernel myself on my
> > box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?
>
> If the live iso works, you can restore udev via chroot to your root
> file system. It's a relatively simple sequence:
> # mnt /dev/sdaX /mnt

..you meant mount, and I always add -v so I can read what
I just did, in case I'm distracted and forget. ;o)

> # chroot /mnt

..chroot in first, and _then_ mount /proc, /sys et al?????
I've always mounted those first and only then chrooted in,
believing that was the proper way.

> # mount -t proc none proc
> # mount -t sysfs none /sys
> # mount -t devpts none /dev/pts

..I don't need or want /dev up first?

> # apt-get install udev
> # apt-get purge *vdev* <-- all aitor's vdev packages
> # apt-get install --reinstall udev
> # exit

..thanks, I'll try these.

> The end result of that should be that udev is reinstalled to the
> /dev/sdaX root file system, including the update of its initramfs.
> And that your system boots up without fuss. (hopefully)
>
> If then you wish to try vdev again, it is available in
> "experimental"; that's "my" variant. You need to have the
> experimental entry in sources.list, and perhaps a -1 pinning of it in
> the preferences (to avoid gaining other experimental babies), and
> then use explicit "-t experimental" to get it.
> # apt-get install -t experimental vdev

..heh, last time I played with experimental was 5 or 6 years ago,
Debian's, and it got messy, probably a combination of me spending
too much time on Groklaw and being spoiled by all the good stable
"unstable" and experimental stuff before PulseAudio...

> You might also want to consider using eudev instead, which (like
> aitor's vdev packaging) is a full replacement for udev. (afaik
> 'eudev' makes use of the udev rules, and in that way it's much
> friendlier to other products that currently tie in to udev)

..thanks, will try eudev if vdev doesn't work for me. Can they
co-exist?

..one thing that annoys me with the (un)signed kernels, is they
"conflict", meaning you must pick one. In rescue cases, you
want both, "since one of them will fail to boot" your victim.
We should warn people that "one of these 2 will likely fail to
work on your system", not force a conflict upon them.

..file name conflicts are easy to solve, simply append or prepend
appropriate tags to the file names at compile time.

> All in all, there is nothing needed to be compiled into the kernel

..the idea was do an old fashion giant monster kernel with "everything"
compiled in, and no modules nor any initrd, can this no longer be done?

> for vdev or udev (or eudev I think). But if you can't come forward,
> there is also the option of hand crafting an initrd enough to get the
> system pivoting, to let you install/uninstall.

..yup, I get to the initrd shell most of the time, so one way is
try fix it from there, it's a skill I need now, and knowledge we
as a distro need to have.

..especially heads users might not have my luxury of a new disk
handy nor my tax return deferment, they might need to fix what
they have handy, and they might need the skills to trash their
data thoroughly enough, so I'm playing guinea pig now. ;o)

..I wanna fix my box now, but I _can_ do a fresh install now
and play with the fix later, if it can't be done now.

..initrd recovery pointers I should try, if we differ enough now
from Debian's new systemd ways and the old Debian ways of doing
this?


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.