I've had some luck using "-pix_fmt yuyv422" and "scale=-1:720"

It's not unusal to get all sort of such problem if you happen to omit or forget to set up the virtual filesystems (esp. proc, sysfs and devpts) and device nodes in the chroot.

grub, for instance, will want to access both the disk device as a whole as well as the boot partition on that device, and it also wants that boot directory to be present on that disk device.

But you probably don't want that installation to mess with your "outside" boot so you should refrain from bind-mounting /dev. Rather you set up the appropriate device node for the target disk image under an alias name within the chroot; i.e., for example, use mknod naming it "sda" but with major/minor identifying the actual device (perhaps "sdf" for a removable, or "loop0" for a  duly set up disk image file).

@Altoid, to recover an DOS partition table, you clear the first 1 Mb of the device:

# dd if=/dev/zero of=/dev/sdf bs=1M count=1 conv=notrunc

NOTE THIS IS HARMFUL TO A DISK. Make sure doubly /dev/sdf is the disk at hand.

Then run fdisk to create a DOS partition table as per post #3, create a single primary partition of type 83 starting at 2048 and ending at end.

Thereafter run fsck as per superblock advice at post #7, trying some of the discovered superblocks.

Then mount sdf1.

Might work, though it doesn't recover overwritten files of course.

If it was me, I would run fdisk to set up a new partition table... I would make a dos partition table starting from scratch possibly deleting whatever entries it has, then using defaults, all on my habit of normally using the defaults for my disk partitioning.

The directory /etc/modbrobe.d holds files that are used by the modrobe program/command to in particular use given parameters to modules as they are loaded.

If you want to give parameters when usbcore is loaded, then you would typically make a file named usbcore.conf in that directory, and in the file write a line

options usbcore use_both_schemes=y

That line tells modprobe to use that parameter setting when loading the module.

In order to take effect, the module must first be unloaded before loaded again; the parameter setting applies at loading.

Some modules allow some parameters to be changed also for a loaded module. You would do that with a command similar to

# echo y > /sys/module/usbcore/parameters/use_both_schemes

The redirection must be done as root of course.

Yes, you may need to run an install disk but stop before partitioning, and then use Ctrl-Alt-F2 to gain an installer shell instead.
It should be raid0 capable to let you assemble your installed system, for mounting it and chroot into it.

Though this should be rather similar to using the rescue mode... did you select the "configure raid" option in the "select root filesystem" menu, and then use the md device?

I realized I tried a raid1; I should it with try raid0 instead.

EDIT: I started to wonder about which kind of raid system you are setting up.

Basically, if any of the bootstrap files end up straddling a division line between raid0 partitions there will be grief, because those are all loaded before any raid0 support is available, using disk block addressing.

To be sure about things, you might therefore want to have a separate /boot partition outside of the raided partitions.

I'm afraid I don't have a RAID setup myself, but at a quick glance I would probably first try to follow these instructions

I.e. do that on the installer command line to begin with.
And make sure to save the configuration file(s) somewhere.

EDIT: Actually, the installer includes some functions for setting up RAID. You will need to use "expert" mode, and then in particular select the "mdcfg" option as additional component. At the partitioning stage there will then be some RAID setup options. I'm not yet totally sure how these work though.

EDIT: I'll take it back: the RAID setting up is available also with "default" mode. But you need to use the Manual option for partitioning so that you first partition the physical devices, and then use the "Configure RAID" option before finishing the partitioner.

Note that grub will only install on the one disk, which should be one of the physical disks. You may later also run grub-install onto the other disk(s) to make them separately bootable.

I think the last line in /var/log/dmesg should tell you how long time the last boot up took. And /var/log/dmesg.0 would be the previous boot. And successively /var/log/dmesg.N.gz the Nth boot before that (those files are in gzipped format though).

On that line, the first  number counting from the left is a time stamp of relative time in seconds with fractions since the kernel started to, as I believe, when the "boot finished".

how do you know which parameters it is using?

Eh?

deb.devuan.org is the mirror round-robin, which ultimately resolves to any one of the package mirror hosts.

There is no devuan SSL access for those but they of course provide whatever services they want in addition to the package mirror service for "http://deb.devuan.org".

.. keeping in mind of course that github nowadays is a Microsoft venture ..

Note that @Head_on_a_Stick jumped into the particular solution(s) of how to get the saved filesystem mounted at boot time onto /home, under on an assumption like that users Billy and Kate had their home directories saved at top level as /billy and /kate on the save partition.

Since I often find myself in some different situation (with old home directories somewhere down deeper on the save partition) I need to do a little bit more and different things.

Perhaps it's useful for the OP to first conceive the distinction between

• a partition which is a portion of a disk, and

• the filesystem a partition contains.

On bootup, the kernel sets up one selected partition's filesystem as root filesystem, and any other partition's filesystem gets mounted (as declared in /etc/fstab) onto some directory (to become that subdirectory tree). The pathnames of that second filesystem are then appended to the pathname prefix leading to the mount point.

For example, if the saved data gets mounted on a directory named /old, then it'll be accessible under the saved pathname following the prefix /old. In other words, if Biily's old home directory got saved as /home/billy on the save partition, then that will be found as /old/home/billy when that partition is mounted onto /old. Or it is found as /home/home/billy if the partition is mounted onto /home.

Thus, if Billy's home directory got saved as /billy on the save partition, then mounting that partition onto /home makes the saved directory accessible as /home/billy.

The home directory for a user is registered in the file /etc/passwd. This has one line for each user, with the line divided into parts separated by ":", and the second last part of a line tells the home directory for the user named as first part of the line.

In some other scenarios, such as when mounting the save partition onto /old because the save path is /home/billy on that partition, one might edit /etc/passwd to tell that billy has /old/home/billy as home directory.

And then, even in that scenario, it is possible to instead use an additional "bind mount" to make the path /old/home/billy (also) accessible as path /home/billy, and thereby avoid editing /etc/passwd. To do this you'll need two separate entries in /etc/fstab: one to mount the partition, and a second one to declare the bind mount.