xorriso in ghostbsd-build

[ASX]

Hi,

i uploaded a new GNU xorriso development snapshot tarball with the bug fix:

http://scdbackup.sourceforge.net/xorriso-1.4.9.tar.gz
MD5: 3ff9197427dd13acf0f72c33d1d40287

xorriso -version is supposed to say:

Code: Select all

  xorriso version   :  1.4.9
  Version timestamp :  2017.09.23.074650

The snapshot tarball content and its MD5 can change without change of
the tarball name. Any future version with a newer "Version timestamp :"
is supposed to contain the fix, too.

A new libisofs release will not happen soon. The last one was just a
week ago and the bug is rarely triggered.
I understand from
https://www.freebsd.org/doc/en/books/po ... patch.html
that FreeBSD ports can apply patches.

If it is important to have a libisofs-1.4.8.pl01 release tarball, then one
would need to convince me: scdbackup@gmx.net or bug-xorriso@gnu.org .

Have a nice day

Thomas

Hi Thomas,

Indeed the freebsd ports system allow to easily add patches, and eventually can also grab sources from github, a new tarball is not strictly required.

Thanks!

[ASX]

Thomas,

When we added a marker for the end of the page list, that become the 20th element.
The code is using a mix of pointers and arrays, the latter are sized as "19", so I'll put a warning here, although it may not be relevant, just in case.

Kind Regards,
ASX

[ericbsd]

Eh,
I am looking forward to taking ownership of maintaining xorriso ports since GhostBSD and some iXsystems depend on it.

[scdbackup]

Hi,

When we added a marker for the end of the page list, that become the
20th element.

Probably as consequence of the bug. In
viewtopic.php?f=98&t=711&start=20#p4858
i count 19 lines of "3L". That many complete loop passes happened.
Then at some point of the 20th pass it crashed. Pass 20 should not
have started, of course.

Everything at the end of the function indicates that 19 passes happen
here. The difference to the buggy situation here is that "rpt" is not
two uint16_t beyond the end of "class_page_data" any more, because
the fix grew "class_page_data" by two uint16_t elements.

Code: Select all

    rpt = (uint16_t *) class_page_data;
    page_pt = (uint16_t *) class_pages;
    while (1) {
        if (*rpt <= page_idx)
    break;
        page_count++;
        page_idx = *(rpt++);

        ... inner loop writing to page_pt ...

        hfsplus_class_pages[page_idx] = class_pages[page_count - 1];
        page_pt += 256;
    }

I brought the fixed xorriso-1.4.9 under control of gdb to the end of
the function call. All seems well:

Code: Select all

(gdb) p page_pt-(uint16_t *)class_pages
$2 = 4864
(gdb) p 4864/256
$3 = 19
(gdb) p page_count
$4 = 19
(gdb) p page_idx
$5 = 254

The last iteration value of "page_pt" was not yet used when the
loop ends. So the last one used was

Code: Select all

class_pages + 18 * 256

The last value of "page_count" was used minus 1. So again, index 18.

Best is if you put some printfs to the end of the function and
check whether the same values are to see as here with gdb.
Also print "page_pt - (uint16_t *) class_pages" before the inner while-loop
starts. 4608 should be the last value used, not 4864.

Have a nice day

Thomas

[scdbackup]

Hi,

ericbsd wrote:

I am looking forward to taking ownership of maintaining xorriso ports
since GhostBSD and some iXsystems depend on it.

Be aware that the bug fix belongs into the devel/libisofs port.

Don't hesitate to ask for advice about upstream or for adaptions for BSD
systems. I test each release on an old FreeBSD 8 and a three year old
NetBSD VM.

Have a nice day

Thomas

[ASX]

Thomas,

thanks, I just don't have the same level of confidence as you at reading that code, glad to know it is not a problem.

Why do you perform test on FreeBSD 8, which is EOL/unsupported ?

[kraileth]

For testing purposes I can only recommend using Vagrant. Especially if you have a good internet connection, you always have the latest releases three terminal commands away. All available releases can be found here: https://app.vagrantup.com/freebsd

[scdbackup]

Hi,

ASX wrote:

I just don't have the same level of confidence as you at reading that code

Well, i already once shot my foot with that function.
Insofar i take any objection or suspicion for serious. Pity that valgrind
is not effective with that kind of error. With dynamic memory it finds such
trespassers.

Why do you perform test on FreeBSD 8, which is EOL/unsupported ?

It's an older machine with Debian 6, FreeBSD 8, and OpenSolaris.
I need real iron for the tests with DVD burners.
Of course i should try to install a newer FreeBSD ... but i am an awful
sysadmin and first i'd need to understand or replace the master GRUB of
the disk.

kraileth wrote:

For testing purposes I can only recommend using Vagrant.

Would Virtualbox 4.3.18 on a Linux kernel be able to forward a real
DVD burner to a FreeBSD guest so that it appears as /dev/cd0 with full
SCSI passthrough via libcam ?
I.e. not only as emulated DVD-ROM but as usable burner for cdrecord,
growisofs, or in my case libburn.

Have a nice day

Thomas

[ASX]

Hi Thomas,

I need real iron for the tests with DVD burners.
Of course i should try to install a newer FreeBSD ... but i am an awful
sysadmin and first i'd need to understand or replace the master GRUB of
the disk.

I'm not sure if you are currently using grub-legacy or grub2, but may be you don't need to change boot loader at all; the simplest method to boot mutiple OSes is install each OS on a dedicated partition, and each OS own loader installed on the same partition. You can then use "chainloading" from your actual grub because that method is OS agnostic, and the needed config is limited to point the right disk/partition.

You can use the same method with grub or grub2 (although the syntax is a little different, specifically the partition numbering start from 0 in grub legacy and start from 1 in grub2).

A different method often used is to load the kernel directly, that imply that grub must have some knowledge of the filesystem hosting the kernel, and grub2 does a rather good job because can provide support for USF or ZFS (of interest for FreeBSD), but that support is optional and some Linux distribution doesn't install the related modules by default in /boot/grub (however they are generally available in /usr/share/grub or something like that).

FreeBSD installer doesn't provide grub by default, but GhostBSD offer it as an option, our grub2 of course install the support for UFS, ZFS and Linux filesystems.

For FreeBSD specifically, one can load the kernel, or the "loader" (/boot/loader), and eventually I suggest to load the loader: the reason is that the freebsd docs often refers to changes/additions in loader.conf and that settings are evaluated from BTX loader, bur are skipped if you load the kernel directly; Of course those settings could be applied directly from grub, but is not simple, there is a different syntax and this is also not well documented.

Don't know about OpenSolaris, but the chainloading method should work.

Would Virtualbox 4.3.18 on a Linux kernel be able to forward a real
DVD burner to a FreeBSD guest so that it appears as /dev/cd0 with full
SCSI passthrough via libcam ?
I.e. not only as emulated DVD-ROM but as usable burner for cdrecord,
growisofs, or in my case libburn.

Yes, as far as I know pass-trough is available for virtualized disks and optical drives, provided you have installed the "Extension Pack", that is not supported in virtualbox for freebsd, but should be supported on virtualbox for linux.
http://download.virtualbox.org/virtualb ... ox-extpack

[scdbackup]

Hi,

i set up that system 7 years ago. AMD with 4 x 2.4 GHz, kvm-ready.
If i remember right, the master boot loader is GRUB Legacy, installed and
managed by the old Debian system. It chainloads partition boot loaders.

Main question is whether i should upgrade only FreeBSD or also the GNU/Linux
and pull NetBSD from qemu+kvm to real iron.
First part of any endeavor would be making backups of the current partitions
when they are not active.

I can use qemu+kvm on my Debians to pass a real DVD burner to a guest Debian
and then i can use it for SCSI command passthrough via the "vda" driver.
https://dev.lovelyhq.com/libburnia/web/ ... emuXorriso
But that's not good enough to get the kernel to handle the drive by the "sr"
driver. "sr" suffers from global mutexiosis. But we still have "sg" which
was not worth being mutexed back then, in the Big Kernel Lock Eradication
stampede. So i gave up my plan to test fixes for "sr" and rather made
xorriso ready for "sg", ye olde deprecated way of Linux 2.4.
https://dev.lovelyhq.com/libburnia/web/ ... entLinuxSr

Virtualbox on my workstation is a bit of a problem, ideologically, although
the wiki https://wiki.debian.org/VirtualBox gives hope that it would be
possible. I would rather put it on the test machine.

Have a nice day

Thomas