Hi,
> For all they will know, Debian has been pwned :-/
Yeah. I tried hard to keep my previous mail in a civilized tone towards
the intellectual entities who decided to deduce the purity of Debian ISOs
from .exe files on the same server.
(Quotation marks in the air are a warning sign towards myse
Hi,
the Google problem is getting worse. Firefox only warns because of their
botched malware "detection".
According to statements by Mattias Wadenstein and Steve McIntyre
in the thread around
https://lists.debian.org/debian-cd/2020/11/msg5.html
it is probably about this naive reasoning fr
Hi,
the counterpart of this bug, which is assigned to debian-cd is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966608
"debian-cd: Daily iso flagged as virus/malware by Firefox"
where the maintainer of the ISOs affirms
"It *is* a false positive - we are happy
that we do not have a pr
Package: firefox-esr
Version: 68.10.0esr-1~deb10u1
Severity: normal
Dear Maintainer,
examining
https://lists.debian.org/debian-cd/2020/07/msg00056.html
i downloaded
https://cdimage.debian.org/mirror/cdimage/archive/9.13.0/amd64/iso-cd/debian-9.13.0-amd64-netinst.iso
by the Firefox of a 6 day
Hi,
I am not aware of a package that is in charge for drive behavior.
libburn or kernel are near the hardware. But i don't see this as libburn
problem and for now not as a kernel problem either.
It is unusual that an empty DVD drive makes noises, except when the tray
was freshly loaded and the dr
ed libattr1-dev from Build-Depends.
(Closes: #953924)
* Changed Standards-Version to 4.5.0
No changes needed according to packaging-manuals/upgrading-checklist.txt
-- Thomas Schmitt Sun, 15 Mar 2020 11:26:41 +0100
-
Th
DIRECT track reading.
+ Debian never enabled O_DIRECT, so 84fad99 was never desirable.
+ The patch reverts the upstream commit to bring the fifo code of cdrskin
+ back to the state in Debian 9 and Debian 8.
+
+ -- Thomas Schmitt Wed, 27 Nov 2019 16:17:00 +0100
+
libburn (1.5.0-1)
Hi,
Daniel Kahn Gillmor wrote:
> Is the final checksum over the whole image also MD5, or do we use
> something stronger?
Currently, the downloader only checks MD5. But it already now has a wide
range of better checksums to choose from.
A typical .jigdo file contains this header part (after gunzi
Hi,
i wrote:
> How about mirror checking by SHA256 in grab_md5, before computing the
> MD5 for jigdo ?
Or you could let libjte internally compute both, SHA256 and MD5,
let it work with SHA256, but store in .jigdo and .template the MD5.
(I just checked the API definition. If you can tolerate the
Hi,
i wrote:
> > [...] MD5s. I'd rather characterize them as relation keys and as
> > transport checksums.
Steve McIntyre wrote:
> It's *also* checking for potential corruption in the mirror at build
> time.
MD5 is well suited for that, as long as this is not considered to be part
of an intrusi
Hi,
too early in the morning i wrote:
> The security weakness of jigdo-lite download is in the fact that the
> input file .info is not verified at all, [...]
I meant input file ".jigdo", not ".info".
Have a nice day :)
Thomas
Hi,
i wrote falsely:
> The negative e potency nearest to 0 which powl(3) can compute as non-0
> is e exp -1e-18
It would of course have to be "compute as non-1".
Have a nice day :)
Thomas
+
Hi,
Ansgar wrote:
> > > From looking, I believe it is debian-cd's tools/grab_md5 that is using
> > > the MD5sum from Packages (and Sources) to avoid having to compute all
> > > these checksums itself.
Steve McIntyre wrote:
> > Well, not just that. It grabs them for use in the jigdo file. The
> >
Hi,
Daniel Kahn Gillmor wrote:
> We're not talking about random chance -- we're talking about adversarial
> attack.
The MD5s in .jigdo and .template are not intended to counter an attack.
They serve as keys to create a relation between items of both files, and
they serve as transport check (where
Hi,
since Steve McIntyre seems to be busy, i try to answer the general
questions about jigdo.
The files .jigdo and .template get created by xorriso along with the
creation of the .iso image file.
The MD5s in .jigdo and .template are used for bringing together the
file items in both formats. .tem
Hi,
Antoine Beaupré wrote:
> I mean "broken" as in "DVD as are not available as normal ISOs over HTTP
> or bittorrent but only jigdo".
Afaik, that's because jigdo uses the package mirror servers as source of
the bulk of its downloads. Those servers experience the same as with a
generously sized i
Hi,
Antoine Beaupré wrote:
> Severity set to 'grave' from 'normal'
This is really overdone.
See jigdo as a peculiar way of downloading the ISO with a MD5 check
where e.g. wget has none at all.
And as said, for now jigdo seems indispensible for the fat ISO sets.
> If the ISO image generation is
Hi,
Daniel Kahn Gillmor wrote:
> If jigdo would use the SHA256sum entries instead of the MD5 entries when
> it is doing ISO assembly, then everyone could still fetch full DVD sets
> or BD sized installation ISOs
I am kindof the second-last jigdo export, but not at all with .deb
entrails.
Are you
Hi,
Daniel Kahn Gillmor wrote:
> I would even posit that temporarily breaking jigdo would be better than
> keeping this additional bandwidth cost in play.
To my knowledge, jigdo is the only way to get full DVD sets or any BD sized
installation ISO from
https://cdimage.debian.org/cdimage/release
Hi,
> I'll also look into whether we need both the perl
> script and the binary of "isohybrid"
If it is for functionality, then not.
If it is about portability, then only if isohybrid.c stays restricted to
the architectures which could boot via isolinux.bin.
If it is about backward compatibili
Hi,
shouldn't the package which offers isohybrid.pl depend on perl ?
Note that isohybrid.pl prepares an ISOLINUX ISO only for BIOS booting.
Not for EFI, as does isohybrid from the C source.
isohybrid from isohybrid.c would have to be in a package with
Architecture: any
to produce binary executa
Hi,
Debian's simpleburn depends among others on cdrskin.
If it asks for cdrecord, then it has not been properly adapted to
this dependency.
A simple workaround would be to create a symbolic link
sudo ln -s /usr/bin/cdrskin /usr/bin/cdrecord
cdrskin understands many cdrecord options as of year
Hi,
adrian15 wrote:
> I think this is highly unlikely because when you build an image designed
> to be used in a hard disk you do not use mkisofs.
It's spelled x o r r i s o nowadays :))
There are use cases like Knoppix: An ISO partition, an EFI partition,
and a writable ReiserFS partition whi
Hi,
adrian15 wrote:
> replace:
> search --set=root --file /live/vmlinuz
> with:
> search --set=root --label \"${LB_ISO_VOLUME}\"
This looks ok for me, as far as GRUB2's work is concerned.
But when the GNU/Linux comes up, it may again be necessary for software
in the initrd to locate the ISO file
Hi,
adrian15 wrote:
> Well, guess what happened... my obvious patch:
> if ! search --set=root --file /live/vmlinuz ; then
search --set=root --file /live/vmlinuz1
> does not boot in my computer because it's still finding /live/vmlinuz in
> the internal hard disk.
That's the second bad
Hi,
adrian15 wrote:
> 2.1.1) The live cd media will be the first one to be found by the
> grub's search command. That's ok, that will work in most systems.
I always wondered why debian-cd and debian-live rely on file paths
with such low entropy. No individual distinction between versions is
reco
Hi,
Steve McIntyre wrote:
> Ady on the syslinux list has repeatedly argued against people
> suggesting that syslinux-efi will work for disk/CD hybrid media.
Ady emphasized that it does work with HDD. It was others and me who
pointed out that nobody ever could show success with CD-ROM on real iron
Hi,
Matthijs Kooijman wrote:
> > > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
I wrote:
> > This describes the equipment of debian-live and debian-cd [...]
> I'm a bit confused by your message. When you say "This", are you
> referring to the syslinux isohybrid page?
Yes. The do
Hi,
Matthijs Kooijman wrote:
> it seems isohybrid can include a small FAT filesystem with the
> bootloader files. [...]
> https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
This describes the equipment of debian-live and debian-cd (DVD-*, BD-*,
netinst) ISOs. See e.g. debian-live-9.5.0-
Hi,
it is not a bug but a feature. In the context of the cdrecord emulation
being "blank" means being writable without further precautions. The
media types DVD-RAM, DVD+RW, BD-RE, and formatted DVD-RW are overwritable
without the need for a blanking run.
If you run xorriso in its native mode:
Hi,
the new ISO of today looks good so far:
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-xfce.iso
The file /.disk/mkisofs shows command -compliance no_emul_toc before -map.
File size 2047475712 matches the output of /sbin/isosize.
(But it is
Hi,
i wrote:
> Add to the xorriso run of live-wrapper the command
>
> -compliance no_emul_toc
Ping ... ?
Have a nice day :)
Thomas
Hi,
i posted a link to the wrong message. Mike Kupfer's observation is in
https://lists.debian.org/debian-user/2018/05/msg00624.html
Have a nice day :)
Thomas
Source: live-wrapper
Version: which made debian-live-9.4.0-amd64-xfce.iso, possibly newer than 0.7
Severity: normal
Dear Maintainer,
as Mike Kupfer pointed out in
https://lists.debian.org/debian-user/2018/05/msg00522.html
the file size of
debian-live-9.4.0-amd64-xfce.iso
is larger than the f
Hi,
i managed to build a live-build ISO.
Its /boot/grub/efi.img contains
/efi/boot/bootia32.efi
/efi/boot/bootx64.efi
which both show by "strings" the embedded configuration with
search --file --set=root /.disk/info
The ISO 9660 filesystem contains a file
/.disk/info
So the riddle is why
Hi,
Luca Boccassi wrote:
> You can build such an image with the default configuration,
Will try to learn from the man pages. (Nevertheless an ISO would be
faster to grasp and also avoid any configuration differences.)
> you'll see that there is no grub.cfg in there, hence this bug report.
A fi
Hi,
Raphael Hertzog wrote:
> I assume that the above image has been
> built with live-wrapper and here the bug report and the patch is about
> live-build
I silently assumed live-wrapper because my examples
debian-live-8.4.0-i386-standard.iso
debian-live-8.4.0-amd64-standard.iso
both tell
Pr
Hi,
i wonder why the built-in configuration of the EFI boot file does not work:
# mount debian-live-9.3.0-amd64-xfce.iso /mnt/iso
# mount /mnt/iso/boot/grub/efi.img /mnt/fat
# strings /mnt/fat/efi/boot/bootx64.efi | tail -4
search --file --set=root /.disk/info
set prefix=($root)/boot/grub
s
Hi,
meanwhile the moment of breaking the kernel has been identified.
It was the mass removal of Big Kernel Lock in 2010 by Arnd Bergmann:
https://lkml.org/lkml/2010/9/14/338
A summary of problem reports and investigations was posted to LKML in 2013
https://marc.info/?l=linux-scsi&m=1357050618
Hi,
Chris Lamb wrote:
> I'm not sure what lintian can do here, indeed.
First to say: I am not aware whether the problem still exists.
But in general it seems that "strings" on the binaries is not the right way
to obtain a list of message texts. After all, the purpose of a compiler is
to put out
Subject: jigdo-lite: Final statement about verified ISO is too affirmative
Package: jigdo-file
Severity: normal
Tags: upstream
Dear Maintainer,
as described in
https://lists.debian.org/debian-cd/2018/01/msg00021.html
jigdo-file verifies the .template file and the resulting ISO image only
by MD5
Package: jigdo-file
Severity: normal
Tags: upstream
Dear Maintainer,
as described in
https://lists.debian.org/debian-cd/2018/01/msg00021.html
jigdo-file verifies the .template file and the resulting ISO image only
by MD5 checksums which stem from the .jigdo file.
This is good enough for recogn
Package: debian-cd
Severity: normal
Tags: upstream
Dear Maintainer,
as described in
https://lists.debian.org/debian-cd/2018/01/msg00019.html
the *.jigdo files are not listed in the checksum files *SUMS.
There is no way provided to check the authenticity of *.jigdo before
downloading by jigdo-li
Hi,
shivgupta wrote:
> > mount: no medium found on /dev/sr0
Steve McIntyre wrote:
> * Did you have a disc in drive sr0?
> * Was it spun up?
The first question was my first thought, too.
But it's not about the drive spinning up, but rather the 10 to 15 seconds
it normally needs to inspect the m
Hi,
Pierre-Elliott Bécue wrote:
> I'm sorry that it broke some backward compatibility with older browsers. :/
At least for me as JavaScript allergic it is still an improvement over
the previous situation. Better ugly than obscure.
Of course, for a Jessie Iceweasel user with JavaScript enabled it
Hi,
> Actually the toggle details is no longer relying on javascript but on a
> HTML5 tag (TitleContent. Maybe
> Iceweasel 31.7.0 does not support such a tag?
It seems so. At least the examples from
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
show up identically in my we
Hi,
Pierre-Elliott Bécue wrote:
> I pushed a patch to have the tracker behaving in a proper way even though
> javascript is disabled.
That's great news. Since today i began to ponder whether pointing to
https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javas
Hi,
i wrote:
> > us.cdimage.debian.org is a quick one.
Nicholas Geovanis wrote:
> From which location? Germany?
Ja.
How about this final message in case that files are missing and that
mismatching downloads were detected ?
(The mismatches shown are fake and recorded twice to get more than 2.)
Hi,
I wrote:
> > > > sed -e 's/^[hH][tT][tT][pP]:\/\///' \
> > > >... more -e for https, ftp, and file ...
Philip Hands wrote:
> > > sed -e 's,^\(https\?\|ftp\|file\)://,,i'
> > > ...
> > > "$imageTmp/${url#[[:alpha:]]*://}"
> > Are these widely porta
Hi,
first a correction of my proposal:
The else-case with
echo "WARNING: File not found after download:" >&2
is not good.
It floods the log if one uses a mirror with few matching files.
Not finding a file after the download is a normal situation.
---
Hi,
i Cc: debian-cd with this follow-up to bug 884526 in the hope to get
some review for the endeavor to detect damaged downloaded package files
during a run of jigdo-lite.
Some disputable aspects remain (plus a possible bug in current jigdo-lite,
which will vanish by my proposal). I put them beh
Hi,
Ouch. In jigdo-lite it is not easy to have the downloaded files verified
with the checksums of the expected FileParts.
Steve, i could need a decision in which direction i should go:
- Check .jigdo MD5s by jigdo-lite.
- Check by jigdo-file, with a new option --warn-unused-file to enable
my
Hi,
i identified a better candidate for detecting non-matching FilePart objects
during scanning. (I learned that jigdo-lite downloads 10 files and then lets
jigdo-file make a scan over the whole image in order to find the places
where they fit. Is this done because jigdo-file has no idea of downlo
Hi,
long live the netinst ISOs !
But my patch is not good. Much too many false positive messages.
At least i now know that the program execution really gets through that
code part. But obviously it does this not only with files which were
actually downloaded.
Also i learned that
mfile->leafNa
Hi,
if i shall place a bet, then i'd say the checksum mismatch in
https://sources.debian.org/src/jigdo/0.7.3-5/src/mkimage.cc/#L508
is where the message should be issued:
...
case JigdoDesc::MATCHED_FILE: {
/* If file present in cache, copy its data to image, if
Package: jigdo-file
Version: 0.7.3-3+b2
Severity: normal
Tags: upstream
Dear Maintainer,
the attempt to create debian-6.0.7-amd64-DVD-1.iso from
http://cdimage.debian.org/cdimage/archive/6.0.7/amd64/jigdo-dvd/debian-6.0.7-amd64-DVD-1.jigdo
and the default mirror http://ftp.de.debian.org/debian
Hi,
I wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881941
Daniel Reichelt wrote:
> He already merged the patch in live-build's git [1]
I missed the tagging mail of november 20th. Sorry for the noise.
> Do you have a conrete example of when the patch fails?
No. My proposal is
Hi,
David Christensen wrote:
> This will restore Debian (and
> derivatives) as a viable option for many millions of older computers. :-)
At least they can now have some good final years.
(Let's be nice to the elderly. We will join their ranks soon enough.)
Have a nice day :)
Thomas
Hi,
the weekly testing ISOs for i386 and amd64 are now equipped with the
new MBR:
https://cdimage.debian.org/mirror/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-netinst.iso
https://cdimage.debian.org/mirror/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
Tester
Hi,
> thanks for pushing this forward :) .
You wrote my name on its item in the changelog.
And somehow i became the drover of this bug, anyway.
> Well, that bug is only solved once we have CD images that are no longer
> affected by this bug.
Given its usual speed of movement i just wanted to g
Hi,
now that a new set of SYSLINUX packages is announced by
https://lists.debian.org/debian-cd/2017/10/msg00025.html
with changelog entry
* Add patch from upstream to fix boot problem for old BIOS firmware from
around 2005 by correcting the C/H/S order (thanks Thomas Schmitt).
what
Package: libconfig-model-perl
Version: 2.108
Severity: normal
Tags: upstream
Hi,
when using a wrong name while trying to remove a package section from
file debian/control, cme indicates no problem, although the desired
section could not be found.
E.g. in the directory of libisofs i tried to remo
Hi,
> Don't worry,
"Don't worry" is not easy to implement near the end of a release week. {:)
> your packages are up to date :-)
Indeed:
/var/cache/apt/archives/libconfig-model-dpkg-perl_2.098_all.deb.deb
Sorry for the wrong Version header.
Have a nice day :)
Thomas
Package: libconfig-model-dpkg-perl
Version: 1.022
Severity: normal
Tags: upstream
Hi,
after
apt-get update ; apt-get dist-upgrade
a run of
cme check dpkg
issues this new warning:
Warning in 'control source Build-Depends:3' value 'libcam-dev
[kfreebsd-any]': package libcam-dev is unknown.
Hi,
a directory relocation loop, indeed.
The root directory has a RRIP entry CL which points to the root directory
itself as relocation target.
The root directory is not supposed to have a CL entry. But in general,
other than with symbolic links, CL is not supposed to be chained.
So i decided to
Hi,
all the testing did not catch the new bug by which i prevented
multi-session reading. It only showed up with the first incremental
backup run after installing the new xorriso version on my workstation.
Hopefully fixed by
https://dev.lovelyhq.com/libburnia/libisofs/commit/a7152f57942c01f468
Hi,
the immediate trigger of the bug is fixed by commit
https://dev.lovelyhq.com/libburnia/libisofs/commit/91490d5f34422d514b042a9e597be8d614a3a1ea
"Preventing use of zero sized SUSP CE entry which causes SIGSEGV.
Debian bug 872590. Thanks Jakub Wilk and American Fuzzy Lop."
Further i ins
Hi,
this is not so eay to fix. Lots of potential holes for the rabbit
to sneak in.
A big problem is this plan of my predecessor developer in libisofs:
/* read all blocks needed to cache the full CE */
The continuation area is allowed to be up to 4 GiB of size.
iter->ce_off is the uin
Hi,
my valgrind even says:
valgrind: the 'impossible' happened:
Killed by fatal signal
The trigger is an AAIP AL entry of length 4. The minimum size of an AL
entry is 6. This assumption made the code too optimistic about the
allocated length.
Fixed by:
https://dev.lovelyhq.com/libburn
Hi,
that snappy little Fluffball created an SL entry with an empty path component.
I understand it looks for suspicious code pieces and then tries to activate
them by submitting a series of nasty input files.
So i will not complain about its character, but only about its harmless
look (*).
The b
Hi,
i see the bug in the code but not the attached ISO.
It would be helpful for testing a fix and might give me more ideas
about what to harden.
Have a nice day :)
Thomas
Hi,
this AFL is such an insidious thing. :))
The test "ISO" is totally screwed up, except a narrow path that leads
to a root directory which bears a Rock Ridge entry "RE". Such an entry
marks a directory as relocated. I.e. its Rock Ridge path of directories
is not the ECMA-119 path which leads to
Hi,
Vladimir Serbinenko has just committed a fix:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e66dc5d71ebfc9763420a76c274e6980d54641c3
Have a nice day :)
Thomas
Hi,
> grub-mkrescue -o asdf asdf
> asdf does not exist
I assume this yields a xorriso error message
xorriso : FAILURE : Cannot determine attributes of source file '.../asdf' :
No such file or directory
...
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
(at least for me it
Hi,
Steve McIntyre wrote:
> Do you have suggested text we can use?
Modulo english language, URL of the binary file, and clarity of mind.
$$...$$ means that properties of the download offer have to be inserted.
The answer is intended to be put after
"How do I write a CD/DVD/BD image to a USB fl
Hi,
if we wait much longer then the machines have died out which need the fix.
How about offering the corrected 432 bytes for download and have
an item in CD FAQ which points to the binary and explains how to
put it onto the first 432 bytes of the USB stick or .iso image ?
Have a nice day :)
T
Hi,
Steve McIntyre wrote:
> *Now* fixed... :-)
The latest debian-testing-amd64-netinst.iso has indeed:
Volume Id: Debian testing amd64 n
...
Creation Time: 2017052004084000
(Now we have to brace for protests from people or software relying on
the volume number 1.)
Have a nice day :
Hi,
i wrote:
> >> How about replacing the volume number "1" by "n" ?
Guido Günther wrote:
> >That would be great!
Steve McIntyre wrote:
> Date: Thu, 18 May 2017 23:40:40 +0100
> I've just committed code to do that, let's see how it looks on the
> next daily/weekly builds.
Seems not to be in eff
Hi,
Guido Günther wrote:
> > Volume id: Debian stretch-DI-rc2 amd64 1
> > [...]
> > >If the netinst variant would contain netinst or similar
Steve McIntyre wrote:
> I understand, yes. The problem we have is that the volume ID is very
> limited in space available. We've run out... :-/
How about
Hi,
i can reproduce this with genisoimage 1.1.11 as of Jessie and with
older 1.1.10.
The problem is in genisoimage/genisoimage.c with this hasty loop:
/*
* The name should begin in the left margin. Make sure it is
* in upper case. Stop when we
Hi,
the wodim device scan bug vanished and re-appeared with the Debian versions
although /dev/scd* did not re-appear. So there must be some other influence.
I think i can prove from the source code that on kernels with minor
revision number below 6 wodim enumerates /dev/sg*, whereas on kernels wi
Hi,
the following patch has been committed to SYSLINUX to fix the C/H/S
addressing problems in isohybrid MBR and isolinux.bin :
http://git.zytor.com/syslinux/syslinux.git/commit/?id=32c09027423f61c305e2423e52f5f69ecad8e2c0
diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S
index 17e1efe..f9e9691 100644
Hi,
David Christensen confirmed that above fixed MBR enabled isohybrid
booting on his legacy system.
Time for a summary of findings.
How to reproduce the bug:
Any BIOS which does not announce "Device Access using the packet structure"
Hi,
more update for Bug#857597:
Correcting the wrong stack address of sectors/head yielded progress
on David's old BIOS.
The MBR code now correctly addresses and loads the first 4 blocks of
boot image file /isolinux/isolinux.bin .
Nevertheless, the stack interface between MBR and loaded isolinux
Hi,
intermediate report:
We found a bug in isohdpfx.bin which spoils the C/H/S address conversion
for BIOSes which do not support LBA addressing.
http://www.syslinux.org/archives/2017-March/025692.html
It turned out that David Christensen's BIOS does not support INT 13 AH 41
which causes isohd
Hi,
David Christensen wrote:
> http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-8.7.1-i386-xfce-CD-1.iso
Background info:
This is an isohybrid made by xorriso, equivalent to a run of
isohybrid --uefi
There is a probably useless Apple Partition Map pointing to the UEFI
System Par
Hi,
> How do I talk to the syslinux developers?
Subscribe on
http://www.zytor.com/mailman/listinfo/syslinux
to
sysli...@zytor.com
and post your report.
Have a nice day :)
Thomas
Hi,
Sam Hartman wrote:
> I'd ask that when interacting with end users, you be more clear about
> what you're trying to do.
I am trying to answer this question from the bug report:
> > Could it be that the hybrid CD/USB iso is causing problems?
The answer is for now:
It might be a problem with M
Hi,
Sam Hartman wrote:
> Why do we care if it mounts on a third mac?
I care in my role as upstream of xorriso.
As for debian-cd, any oddity of installation ISOs should be inspected
and judged whether it demands action.
I see i forgot to Cc: the bug reporter.
Hi ! There are replies to see at:
Hi,
(This is about the aspect Mac mountability, not about the aspect of
suitable performance during or after installation..)
Shirish Agarwal wrote:
> Would it be possible to upload the image to someplace where the OP
> could download and use it and see if that works for him.
It is nearly 4 GB o
Hi,
i made a copy + paste error with the repacking command.
Option -apm-block-size lacks its parameter "2048".
Correct would be:
mount debian-8.6.0-i386-DVD-1.iso /mnt/iso
xorriso -as mkisofs \
-o test.iso \
-V 'Debian 8.6.0 i386 1' \
--modification-date='2016091713290100' \
Hi,
schatzclan wrote:
> unexpectedly larger
> actual file size (642M) vs reported size (613M) for the “i386 8.x.0 LXDE
> CD#1” iso.
This is explainable from the difference of programmer's MiB and IEC's MB:
642.0 / 1024 / 1024 * 1000 * 1000 = 612.2589111328125
> The “i386 8.5.0 XFCE CD#1” ISO
Hi,
the decision to stay with the old shell script's command interface
was made 2 years ago:
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00076.html
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
"I think that old parser is better. The only reason the change happened
is that it'
Hi,
i wrote:
> > i expected naively
Raphael Hertzog wrote:
> It's not the kind of work that I find really useful/enjoyable. :-|
That's why i make no GUI but rather hide behind a 5000 lines man page.
Nobody can claim naivity any more when finally having read up to the
description of a feature.
Hi,
Raphael Hertzog wrote:
> Otherwise, the usual way to deal with that is to put a real link showing
> the details of the action item on a separate page
That's what i expected naively when the mouseover text told me
that details would be available on clicking. I did not get to the
idea that Debi
Package: tracker.debian.org
Severity: normal
Dear Maintainer,
when looking at https://tracker.debian.org/pkg/libisofs i see a text box
"action needed" with the (hopefully soon vanished) item
"Multiarch hinter reports 1 issue(s)". When i hover with the mouse over
the little "v"-arrow, i see a text
Hi,
Raphael Hertzog wrote:
> Let the work continue!
Are there any result ISOs published yet ?
I'd like to include them in my xorriso regression tests.
Have a nice day :)
Thomas
Hi,
Raphael Hertzog wrote:
> I believe that syslinux-efi works for less cases than grub-efi
Discussions on syslinux mailing lists indicate that syslinux-efi does
not work with optical drives. (And i know of no bootable ISO 9660
image which would have syslinux-efi in its El Torito boot image
which
Hi,
Richard Betham wrote:
> ln -s /dev/sg0 /dev/scd0
> ln -s /dev/sg2 /dev/scd2
> [...]
> wodim: Overview of accessible drives (2 found) :
> 0 dev='/dev/scd1' rwrw-- : 'hp' 'DVD-RAM GHD0N'
> 1 dev='/dev/scd2' rwrw-- : 'HUAWEI' 'Mass Storage'
> However I used sg? not sr? .
/dev/sg* enu
Hi,
> ** (xfburn:3769): WARNING **: Read-only profile 0x8!
The drive classified the inserted medium as CD-ROM.
Either because it is really a CD-ROM or a closed CD-R or the drive
is mistaken.
> ** (xfburn:3769): WARNING **: [FATAL] 131357: SCSI error on write(32,16): [5
> 24 00] Illegal request.
101 - 200 of 446 matches
Mail list logo
