Hi,
i opened a separate bug with my wish for not needing a second zeroizing dd
run when the ISO is already on the USB stick:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1977644
"Please preserve MBR partition entries 2 to 4 when creating persistent
partition"
Have a nice day :)
Public bug reported:
Hi,
i propose to let function find_or_create_persistent_partition in
scripts/casper-helpers preserve the MBR partition entries 2 to 4 when
it applies sfdisk to create the persistent partition.
Currently it writes an MBR partition entry 2 with start LBA 0, size 1,
and boot
Hi,
tlk wrote:
> which post details the "removing MBR partition 2"?
#112 by me, confirmed by #114 by Chris Guiver:
If the USB stick with the the slowly booting ISO is overwritten
meanwhile:
# Patch the ISO already as image on hard disk
ISO=ubuntu-22.04-desktop-amd64.iso
dd if=/dev/zero
Hi,
Chris Guiver wrote:
> This confirms what I believe you wanted.
Yes.
The stick needs the remedy once again after casper created the persistent
partition.
sudodus wrote:
> This is like development of physics ;-)
Like a unification of relativity theory and quantum mechanics ?
My apologies
Hi,
Chris Guiver wrote:
> On j3400; pressed ENTER (at grub) at 13:10 (room clock).. I didn't note
> time of plymouth but I had maybe-ubiquity @ 13:13 (room clock) for
> altered version of 2022-04-19 ISO
> [...]
> so I'll now boot twice
> [...]
> alas should have noted clock.. it 'feels' slow...
Hi,
i wrote towards Chris Guiver:
> it would
> be a good base if you could confirm that j3400 boots after the plain
> procedure with no other experiments inbetween
I should have written:
it would be a good base if you could confirm that j3400 boots without
the extra delay of ~6 minutes
Hi,
Chris Guiver wrote:
> libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied
Oops. No read permission for normal users on USB sticks.
(I should really operate my workstation with a more conventional setup
so that i better anticipate other's adventures.)
> My
Hi,
Chris Guiver wrote:
> └─sdb4 8:20 1 4G 0 part /media/guiverc/writable
So it seems that casper added its persistent partition without creating
a dummy MBR partition with boot flag.
This simplifies the task of making current Ununtu ISOs digestible for
the j3400. One run of
dd
Hi,
Chris Guiver wrote:
> I performed the command
> `sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462`
> to Ubuntu Desktop 22.04 LTS thumb-drive (K)
> Booted on j3400
> BOOT1:
> it was fully-operational at 2 min 45 secs
So it looks like the dd run brought about the best
Hi,
i have to correct a statement of mine in #104:
> Last year this worked only once, because casper added the partition again
> during "persistent partition creation". This could be fixed now:
> https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/60
It's probably not fixed.
The
Hi,
Chris Guiver wrote:
> BOOT2: LIVE
> 00:25 secs & screen blanks & messages
> 00:35 plymouth visible
> 01:11 message(s) again & plymouth gone
> 02:23 system fully-operational
The overall boot time is still very long. But no particular stage stands
out as the big time waster.
>...> motion
Hi,
Chris Guiver wrote:
> lubuntu (jammy) plymouth seen at 7:27 (#90)
> ubuntu (jammy) plymouth seen at 8:20 (#101)
So it is not about the "huge amounts of time" which ubuntu.seed wants
to avoid.
Are those times stable or do they vary by minutes ?
We know that the firmware executes GRUB
Hi,
sudodus wrote:
> http://cdimage.ubuntu.com/lubuntu/releases/22.04/release/
The "Try or Install" menu item of grub.cfg in lubuntu-22.04-desktop-amd64.iso
differs from the one of ubuntu-22.04-desktop-amd64.iso mainly by kernel
parameter file=/cdrom/preseed/lubuntu.seed instead of
Hi,
sudodus wrote:
> The grub comes from a compressed tarball,
Well, then the hope to find a simple explanation from tweak 3 was an
illusion.
I am staring at the /boot/grub/grub.cfg of ubuntu-22.04-desktop-amd64.iso
and compare it with Chris Guiver's comment #90:
>...> "00:10 secs enter
Hi,
sudodus wrote:
> # tweak 3: search by UUID
> sed -i '/set isofile/'a" search --set=root --fs-uuid $uid3"
> "$targ1"/boot/grub/grub.cfg
> sed -i 's/(hd0,3)/($root)/' "$targ1"/boot/grub/grub.cfg
Where does the grub.cfg come from, in which you find "set isofile"
and "(hd0,3)" ?
I looked into
Hi,
Chris Guiver wrote:
> The ISO wasn't cloned to thumb-drive; but written using
> `sudo -H dus-iso2usb kinetic-desktop-amd64.iso /dev/sdb msdos grub-2.0.4
> persistent`
Ahum. Congrats to sudodus then. :))
I read in
https://help.ubuntu.com/community/mkusb#Installation
"The main function
Hi,
> > *Do you experience the problem with CD-R or CD-RW media ?*
> Yes. The exact same error message as when I tried to make a DVD.
Then it is not exactly the same problem as with the DRW-24D5MT of
Mauro Sacchetto and my BW-16D1HT as of Debian bug 998718.
Your Brasero version 3.12.1-4ubuntu2
Hi,
C. Clear wrote:
> What does doing a power off/on cycle entail ???
Just a shutdown so that the burner drive has no electrical power.
If in doubt whether the power is really off, press the drive's eject
button. The drive should not react.
Have a nice day :)
Thomas
--
You received this
Hi,
C. Clear wrote:
> Drive type : vendor 'ASUS' product 'BW-16D1HT' revision '3.10'
That would match the Debian bug of last year.
> Did try Nero for Linux and had the same
> result as I did with Brasero.
Keep in mind that in the Debian bug scenario Brasero's bad read attempt
spoiled the
Hi,
the error message stems from the burner drive and was forwarded by libburn
to Brasero. Strangely the code ASC=21 , ASCQ=04 is not specified in in
the SCSI specs for optical drives (MMC).
In the overall error code list
https://www.t10.org/lists/asc-num.htm
it is listed for other device
Hi,
the last openat() calls in the strace look like the drive is mounted
(or in use by another burn program):
openat(AT_FDCWD, "/dev/sr0", O_RDWR|O_EXCL|O_NONBLOCK) = -1 EBUSY
(Device or resource busy)
Does it help to unmount /dev/sr0 before running Xfburn ?
Have a nice day :)
Thomas
--
Another way to circumvent the DAO end bug of growisofs is to pad up the ISO
image
to an integer multiple of 32 KiB.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1945585
Title:
Cannot burn Kubuntu
This is probably
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794868
lingering around since 2015.
The fix would be simple, but somebody would have to convince Debian
to add the patch in above bug report to its growisofs package.
Alternatively try to burn the ISO by help of Xfburn which
Hi,
> I noted Thomas (scdbackup) asked for firmware details
The motivation is to find enough affected hardware so that the delay
can be reproduced by developers. Obviously it did not happen with the
regular testing machines.
So my request/proposal was for the general public:
Tell which machines
Hi,
since the majority of machines seems to work with the current Ubuntu ISOs,
it would be helpful to have manufacturer, model name, and firmware versions
of machines where the ISOs cause long delays or fail.
The problem does not sit in the recognition of boot entry points by the
firmware but
Hi,
José Marinho wrote:
> I can't believe it... it boots fine again but once, twice, three
> times... and there is no MBR partition anywhere.
Let me make up a theory:
> - Burn on stick the iso that was builded with xorriso-1.5.5.
> - Boot it for the first time --> Success.
During this run of
Hi,
it comes to me that while no single ISO can serve all firmwares, it would
be possible that one casper can serve the original ISO and an ISO without
MBR partition 2 alike.
The trick would be to let casper memorize the 16 bytes 462 to 477 before
it runs the partition editor, and to let it
Hi,
the Ubuntu system really manipulates the installation stick's partition
table if i choose to try out Ubuntu.
It looks like i was involved as adviser when the addition of MBR
partition 2 was introduced to "casper's persistent partition creation".
See
Hi,
Lucap wrote:
> https://gitlab.gnome.org/GNOME/gnome-disk-utility
> Would the code be worth you looking through for any insight for the
> legacy bios option?
Seems not necessary. Your diff in comment #44 shows the few changes which
gnome disks made for you.
José Marinho's boot1.txt shows
Hi,
José Marinho wrote:
> changes only work at first boot [...]
> This happened today with the new version of xorriso and yesterday with
> "dd if=/dev/zero bs=1 count=16 of="$NEW" conv=notrunc seek=462" command.
> [...]
> the output of two xorriso commands BEFORE trying to boot from
> the stick,
Hi,
i uploaded a new development snapshot of GNU xorriso which can create a
GPT similar to the result of Lucap's gnome disks run.
cd "$HOME"/xorriso_dir
wget http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz
tar xzf xorriso-1.5.5.tar.gz
cd xorriso-1.5.5
./configure --prefix=/usr
Hi,
José Marinho wrote:
> GPT PMBR size mismatch (5505347 != 7907327) will be corrected by write.
> ...
> /dev/sdd1 1 7907327 7907327 3,8G ee GPT
> /dev/sdd2 * 0 01 512B 0 Vacía
Looks like fdisk reports to you what would be the result if you let
Hi,
José Marinho wrote:
> 4- [...] I assume that the usb drive shoud have an original ubuntu
> 21.04 ISO burned.
The "$STICK" in the setting of Lucap at comment #44 was additionally
treaded with gnome disks: "edit partition and tick the box that says
Legacy BIOS bootable".
This yielded GPT flags
Hi,
José Marinho:
> Well, I try the first method (compiling xorriso) and removing the if
> condition from grub.cfg keeping grub_platform command. The usb drive now has
> a GPT partition table but unfortunately, the issue persists so, it seems
> that the grub_platform thing is not the cause.
Hi,
Lucap wrote:
> gnome disks no longer says it's a GPT layout and
> says the first partition is Linux (Bootable)(0x83)
José Marinho wrote:
> in this last experiment I see with Gnome disks that the usb drive with
> the modified iso has a MBR partition table instead the GPT partition table
> of
Hi,
regrettably the display of launchpad's website eats blanks.
This mutilates my proposed grep 'GPT partition flags: 1' by condensing
three blanks before "1" to a single blank.
So i change the inspection proposal to
xorriso -indev stdio:"$NEW" -report_system_area plain | \
grep 'GPT
Hi,
Lucap wrote:
> < MBR partition : 1 0x00 0xee1 5508391
> < MBR partition : 2 0x80 0x0001
> ---
> > MBR partition : 1 0x00 0xee1 15649199
So gnome disks expanded the range of the protective MBR partition to
Hi,
José Marinho wrote:
> I made the experiment you proposed modifying grub.cfg file.
> [...]
> So it seems that you find the cause of the problem.
By luck and 14 years of xorriso development. :))
Can i talk you into a second test ?
This time only disable the part in grub.cfg which evaluates
Hi,
just in case somebody wants to make experiments with changed grub.cfg,
here are instructions how to create a modified ISO from an Ubuntu amd64
original (but not from a "powerpc" ISO):
Set paths to the original ISO image and for the emerging ISO image:
ORIG=ubuntu-21.04-desktop-amd64.iso
Hi,
Lucap wrote:
> If i look at the USB sticks first partition with gnome disks , edit
> partition and tick the box that says Legacy BIOS bootable then the USB
> stick no longer shows "cannot find grub_platform" and goes straight to
> the grub menu , then it boots to a black screen with a
Hi,
José Marinho wrote:
> Marking the first partition as bootable legacy BIOS:
> - Plymouth --> 54 seconds.
> - Desktop environment --> 1 minute 45 seconds
Without converting to GPT ?
That would be really strange and surely no solution for the gerneral public.
(It is not allowed by GPT specs to
Hi,
Chris Guiver wrote:
> Delay occurs regardless of ISO being written using mkusb, dd, or gnome-
> disks..
Hmm. IIRC mkusb offers to unpack the ISO into a filesystem of the USB stick.
If the problem survives that conversion, then it is far inside the GRUB
equipment.
It should be possible to
Hi,
Michael Hudson-Doyle wrote:
> I'm going to
> subscribe Thomas Schmitt, xorriso upstream, who knows enormously more than
> I do about all this stuff.
Well, firmware can always outsmart any preparation in an ISO.
My personal expertise is restricted to ISO 9660 and ends when firmw
Hi,
Paride Legovini wrote:
> see https://github.com/canonical/subiquity/pull/900
where i see:
- opts="$(xorriso -indev ${OLD_ISO} -report_el_torito as_mkisofs
2>/dev/null)"
+ opts="$(xorriso -indev ${OLD_ISO} -report_el_torito as_mkisofs)"
Consider to reduce verbosity by xorriso command
Hi,
> /usr/bin/mkisofs -r [...]
If xorriso shall be used, then the following HFS-specific options need
to be omitted:
--netatalk
-hfs
-probe
-map /srv/cdimage.ubuntu.com/debian-cd/data/hfs.map
-part
-no-desktop
-hfs-bless CD1/install
-hfs-volid Ubuntu-Server_PPC64EL_focal
Hi,
i forgot to propose that make-edge-iso.sh should look in stderr of the
"xorriso -report_el_torito as_mkisofs" run for this message:
xorriso : SORRY : Cannot make proposal to produce APM of loaded image
and/or that it should check for the exit value of the xorriso run, which
in this case
Hi,
> 1. download [2]
> 2. xorriso -indev focal-live-server-ppc64el.iso -report_el_torito as_mkisofs
The adventure moves to the question how this ISO got its partition
table.
$ xorriso -indev focal-live-server-ppc64el.iso -report_system_area plain
...
ISO image size/512 : 2440600
...
Hi,
> xorriso : FAILURE : Image size 409295092s exceeds free space on media
127778488s
So you already found out that the ISO would contain
409295092s = 409295092 * 2048 bytes ~= 781 GiB
and spotted this option with its arguments:
> -append_partition 4 0x8 --interval:local_fs:1718121313d-
I wrote:
> "d" is index 512 (disk block).
That was meant as
"d" is indeed 512 (disk block).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914587
Title:
make-edge-iso.sh fails on focal/ppc64el
Hi,
Steve Langasek (vorlon) wrote:
> I've manually run through the steps of casper's persistent partition
> creation [...]
> it also "fixes" the protective MBR, removing the empty bootable partition.
That explains why the machines which demand the boot flag boot exactly
once.
sudodus
Hi,
> Please tell me which partition editor commands to run
One might need superuser autority for reading the device file:
device=/dev/sdd
/sbin/fdisk -l "$device"
xorriso -indev stdio:"$device" -report_system_area plain
Have a nice day :)
Thomas
--
You received this bug
Hi,
sudidus wrote:
> Later on, in the HH series, you can revert back from 'nopersistent' and
> let the system create an ext4 partition again (in a USB drive behind the
> image of the iso file),
So the software in the ISO fiddles with the USB stick partitioning ?
That would be a prime suspect
Hi,
Chris Guiver (guiverc) wrote:
> (1) wiped thumb-drive
> (2) `mkusb-plug groovy-desktop-amd64.iso` (option N or non-persistent
> was selected)
Is (2) equivalent to a plain copy by dd or cp ?
> I booted again (still same thumb-drive) without issue on
> - hp dc7700
> and booted successfully on
Hi,
i now am boss of my mainboard ASUS ProWS C246-ACE EFI firmware 1401,
at least as long i do not want to disable Secure Boot.
The hardware provider was of not of help with USB sticks, but remembers
to have inserted Debian 10.4.0 netinst on CD-RW when SSD and HDD were
still without bootable
Hi,
i confirm that
groovy-desktop-amd64.iso1 1 5740827 5740827 2.8G ee GPT
groovy-desktop-amd64.iso2 *0 0 1 512B 0 Empty
is the indication that the --mbr-force-bootable hack is applied.
A nearly non-existend MBR partition not overlapping the partition of
Hi,
sudodus wrote:
> I also tested the tweak in comment #15 on the current Ubuntu Groovy iso file.
> When cloned the USB drive fails to boot the Lenovo V130,
> ...
> $ sudo gdisk test_mbr.iso
> MBR: MBR only
Obviously the production of "test_mbr.iso" did what the file name says
and made a MBR
Hi,
> xorriso \
> ...
> -outdev test_mbr.iso \
> ...
> -boot_image any appended_part_as=gpt \
> ...
> HOWEVER it did NOT boot on
> hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
> hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)
The only flaw i see is that the ISO's name
Hi,
this is a one-time tangent about the xorriso replay run which i advised
in comment #10.
I found at least the trigger of the xorriso replay flaw about the size
values in ISO 9660 superblock, protective MBR, and GPT header block.
It is the multi-session emulation for overwritable media which
Hi,
> You are a wizard Thomas,
I lurk at boot loader mailing lists since more than a decade.
But as sysadmin i am lame enough to not knowing how to make ASUS ProWS
C246-ACE EFI firmware 1401 offer me any external storage device for
booting, or how to disable its Secure Boot setting.
I will have
Hi,
> So I am sure that we have identified the problem.
There is still the possibility that only a boot flag is missed by the
firmware.
So please test also an ISO made by
...
-boot_image any replay \
-boot_image any appended_part_as=gpt \
-boot_image any mbr_force_bootable=on
Hi,
so the world might begin to split into incompatible camps.
New Lenovos versus old HPs.
Debian still has the "mac" amd64 ISOs which simply have no EFI equipment
in order to please some old Apple machines:
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
But this GPT allergy would
Hi,
> Thinking it through, I am happy for us to make this change from MBR to
> GPT.
Me not so much. GPT has that backup at the end of the device. But when
an image is made, the size of the storage device is not known. So after
putting (cloning) the image onto the USB stick, the backup GPT is
Hi,
> on the V14IIL Lenovo in
> all 3 modes- Legacy BIOS,UEFI,and UEFI+secure boot- success rate 100%.
> 2. mkusb cloning iso file
> 3. rufus in Windows 10 (dd mode)
So now it looks like valid GPT does the trick for Ubuntu ISOs on Lenovo.
There remain riddles:
Why does the grub-mkrescue ISO
Hi,
> There was a problem with permissions.
Hm. I should make xorriso report this. No read permission should not
count as blank pseudo-medium.
What kind of permission was missing and which change fixed it ?
> This test.iso file modified according to comment #181, when cloned,
> makes USB drive
Hi,
> $ xorriso \
> -indev groovy-desktop-amd64.iso \
> ...
> -boot_image any replay \
> ...
> xorriso : NOTE : No proposals available for boot related commands
This means that xorriso did not recognize any boot equipment in
groovy-desktop-amd64.iso .
> Drive current: -indev
Hi,
Leó Kolbeinsson wrote:
> Booting in minimal device on Lenovo V14 fails in all modes [...]
> Tested on Acer machine - media recognized and boots to grub prompt in all
> modes/BIOS/UEFI/UEFI+secure boot.
I assume that this was the grub-mkrescue ISO. Right ?
It is a bit a surprise that Secure
Hi,
> 3. The Dell boots to the grub prompt both in BIOS mode and UEFI mode.
> Success :-) What's next :-P
You could try a GPT partitioned groovy.iso.
In the hope that the automat knows best:
test -f test.iso && rm test.iso
xorriso \
-indev groovy-desktop-amd64.iso \
-outdev
Hi,
has it already been tested whether a grub-mkrescue ISO boots to a
GRUB prompt ?
To try it, install
grub-common grub-pc-bin grub-efi-amd64-bin
run
mkdir minimal
touch minimal/empty-file.txt
grub-mkrescue -o output.iso minimal
and use output.iso like groovy-desktop-amd64.iso.
No
Hi,
so for now -partition_offset 16 is not to blame ?
The only tangible report was back in 2011 about a Macbook Pro
https://lists.debian.org/debian-cd/2011/04/msg00029.html
with decisive test in
https://lists.debian.org/debian-cd/2011/04/msg00060.html
and (deplorable) success report in
Hi,
> https://launchpad.net/ubuntu/+source/cd-boot-images-amd64/7
Oh. This explains why there is still an invalid GPT in
http://cdimage.ubuntu.com/daily-live/current/groovy-desktop-amd64.iso
which i downloaded 2 days ago.
Above change has at its end:
+ echo 'xorriso -as mkisofs [...]
Hi,
sorry for your drive.
But good for Linux burn programs that MS-Windows does not know something
essential about drive error messages which we Linuxers don't know.
> the srange this is that if you use the Disks program in utilities.
That's probably a message from the kernel via systemd and
Hi,
well, at least we got over the strange error code.
> libburn : SORRY : Timeout exceed (3 ms). Retry canceled.
> libburn : SORRY : Command: READ DISC INFORMATION #63,[2 04 00] : 51 00
> 00 00 00 00 00 00 22 00 : dxfer_len= 34
The command READ DISC INFORMATION was retried 63 times. The
Correction:
The single command READ DISC INFORMATION probably did not timeout, but was
repeated
with intermediate waiting until 30 seconds had elapsed. So the drive probably
reacts swiftly but
always says that it is not yet ready.
--
You received this bug notification because you are a member
Hi,
> libburn : SORRY : Asynchronous SCSI error on waiting after START UNIT
> (+ LOAD) [6 28 81] Drive event. Unknown ASCQ with drive event ASC 28.
Grr. A higher level intervened.
In line 198 of file
~/xorriso/xorriso-1.5.3/libburn/spc.c
there is
if (key == 0x6 &&
The line with the absolute address was meant to be:
/home/chris/xorriso/xorriso-1.5.3/xorriso/xorriso -outdev /dev/sr0
-toc
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1896804
Title:
CD/DVD
Hi,
> Sense Key 6 "Drive event", ASC 28 ASCQ 81.
This SCSI error reply is not listed in SCSI specs SPC or MMC or in the
summary of T10 committee
https://www.t10.org/lists/asc-num.htm#ASC_28
So the drive's firmware programmers were overly creative.
If it was ASCQ 0 or 2, then libburn would
I forgot to ask for putting in the desired medium before performing
xorriso -outdev /dev/sr0 -toc
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1896804
Title:
CD/DVD drive detected as read only,
Hi,
i understand from the category "brasero package" that you inspect the drive
by Brasero.
Which burn backend is it using (cdrecord, wodim, libburn ) ?
What kind of medium did you try (CD-R, DVD+R, DVD-R, DVD+RW, BD-R, ...) ?
Which task of Brasero do you want to perform (Audio project, Data
Hi,
Steve Langasek wrote:
> Reading https://lists.debian.org/debian-cd/2019/07/msg7.html was very
> helpful in clarifyingthe options needed to get the image structure we
> are looking for.
At least the ISO would comply to the specs, although this is in no way
mandatory for boot success. :))
Hi,
> avoiding characters like '*', '?', '<', '>', ':', '|'... That's all.
Except ':' the others have a meaning to the shell and thus would be a
controversial choice.i
In case of Debian it is nearly defined what characters are allowed in a
package name.
Hi,
> the EDK2/UEFI folks are more inclined to have the existing EDK2 code
> drive the specs, especially for boot, than the opposite.
It really was supposed to be the other way round this time. :))
But well, firmware is as firmware is.
As said, having a copy of the ESP tree in the ISO should be
Hi,
i am the developer of xorriso. If there are problems after changing
the xorriso arguments i am ready to help identifying the cause.
My own opinion about how Debain (and Ubuntu) ISOs for BIOS|EFI from CD|HDD
should look like is to see in
Hi,
i made experiments with shell variable IFS which can declare '=' to
be white space.
When i do
echo -n x"$IFS"x | od -c
i get
000 x \t \n x
005
(The 'x' are for better recognizing the gaps of blank characters.)
Contrary to my expectation, the shell loop "for" does
Hi,
this looks as if the '=' in /dev/sr0=ubuntu-16.04.6-desktop-amd64.iso
is interpreted by the shell parser as whitespace.
I get the message about genisoimage only if i do
growisofs -speed=1 -dvd-compat -Z /dev/sr0
ubuntu-16.04.6-desktop-i386.iso
Then it says
About to execute
Hi,
the first message about lack of permissions is common and should be
harmless. The failure happens possibly with the attempt to get 16 MiB
of memory via call mmap(2). But it is not obvious why this only succeeds
if you are superuser.
So this might too be a red herring and the actual reason for
Hi,
yes, this all looks like the respective desktops need to bind the key to
some more or less smart program which either ejects unconditionally
or determines the tray state and sends the appropriate command to load
or eject it.
Command
eject -T /dev/sr0
should be a smart toggler between
Hi,
> So, the first command [program "eject"]did work;
This proves that it is not a problem of the drive.
Afaik, it is quite usual that contemporary Linux kernels forget to unlock
the drive tray. (I did not yet find the exact reason in my oldish kernel
and thus cannot tell whether it has been
Hi,
what happens if you perform one of these shell commands:
eject /dev/sr0
xorriso -outdev /dev/sr0 -eject all
In case of failure please report all error messages of the programs.
Have a nice day :)
Thomas
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Hi,
regrettably there is no debugging facility in libisofs which one could
enable without modifying Brasero. Further the Joliet mangler of libisofs
does not produce messages even if i enable DEBUG verbosity when it runs
underneath xorriso.
The problem with libisofs is only that it does not
Hi,
> Is there a way to place a DVD burner into simulation mode as with CD
> recording so as to test the commands without wasting the disc?
Not with DVD+R and DVD+R DL, i fear.
Only DVD-R and unformatted DVD-RW can simulate.
> nodao.log
Now that's a short one.
It can hardly be that growisofs
... and there is a copy+paste error with
{{{
GET CONFIGURATION
46 01 00 00 00 00 00 00 08 00
From drive: 8b
00 00 00 9c 00 00 00 00
From drive: 8b
00 00 00 9c 00 00 00 00
8 ms
}}}
Of course, the drive replied only once.
--
You received this bug notification because you are a
Hi,
attached is a patch which enables SCSI logging to stderr in dvd+rw-tools.
It is based on dvd+rw-tools-7.1.tar.gz (MD5 8acb3c885c87f6838704a0025e435871).
There is no run-time control for this feature yet. Define or undefine
macro Libburnish_scsi_log_to_stderR and run "make" to enable or
Urm. The last stement should have been:
"... i will probably _not_ get to doing it soon."
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1757030
Title:
Lite-On DS8A1H Slimline fails to record dual
Hi,
> With -tao option, xorrecord has no trouble at all.
I am out of ideas, for now.
> Is there an easy way to dump the raw commands before the one that
failed?
I am not aware whether the Linux kernel has a logging facility for
ioctl(SG_IO). That's the system call by which we perform the SCSI
Hi,
this time the layer break position was not set by growisofs.
Now i wonder what is the difference between the commands sent by growisofs
and libburn underneath xorriso.
Looking at the source code of growisofs it seems that no command RESERVE
TRACK is sent for DVD+R DL. libburn sends it if it
Hi,
the problem looks like it is triggered by growisofs' habit to explicitely
set the layer break position. See its message
/dev/dvdrw: splitting layers at 2009552 blocks
and its error message
4115562496/8231090176 (50.0%) @0.0x, remaining 16:15 RBU 100.0% UBU 100.0%
:-[ WRITE@LBA=1ea9d0h
Hi,
the initial error report of 2009 is probably due to a hardware problem
in the computers bus controller, or the cabling, or the drive's bus
controller.
> BraseroWodim stderr: CDB: 2A 00 00 01 6C 7E 00 00 1F 00
> ...
> BraseroWodim stderr: Sense Key: 0x0 No Additional Sense, Segment 11
> ...
>
Hi,
congrats to the success.
I have to stress, though, that cdrskin and xorriso are not forks of cdrecord
or growisofs, but applications of libburn, an independent implementation
of an SCSI/MMC driver in userspace.
In the end it depends on what the drive's firmware makes out of the SCSI
Hi,
yes, DVD-R and DVD+RW are treated quite differently by the drives.
The former is a sequential multi-session medium, the latter is a
random-access read-write medium. Firmware procedures inside the drive
differ. The laser used is the same, afaik. But the dye on the media is
quite surely not
Hi,
this looks like a bad relationship between drive and medium.
OPC (Optimum Power Calibration) is preparation stage of burning were the
drive makes experiments about the laser settings. The media have an
especially reserved data area for that.
Those experiments did not yield a satisfying
1 - 100 of 178 matches
Mail list logo
