Package: grub-efi-amd64-bin
Version: 1+2.02+dfsg1+20
Severity: wishlist
Dear Maintainer,
I'm trying to use Debian-signed secure boot grub binaries
with Super Grub2 Disk scripts.
Many of the Super Grub2 Disk scripts make use of the probe
command. It makes possible to identify partition uuid gi
Package: shim-unsigned
Version: 15+1533136590.3beb971-7
Severity: normal
Dear Maintainer,
I want to be able to build a live cd that has both ia32 and x64 Secure
Boot UEFI support.
So I need both shim-signed:amd64 and shim-signed:i386 installed.
Those two packages depend on shim-unsigned:amd64 an
Package: pcmanfm-qt
Severity: important
Dear Maintainer,
It does not start - without a meaningful message
* Expected Behavior
it should start as root
* Current Behavior
It does not start at all as root
* Possible Solution
Use:
lxsudo dbus-launch pcmanfm-qt
instead which requires dbus-x11 pa
Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+16
Severity: wishlist
Dear Maintainer,
live-build generated grub.cfg uses grub's cpuid command when
there are two or more kernel flavours.
The final user thanks to the add auto option can choose either
the amd64 kernel or 686 kernel in an
Package: shim-signed
Version: 1.30+15+1533136590.3beb971-5
Severity: normal
Dear Maintainer,
I want to be able to build a live cd that has both ia32 and x64 Secure
Boot UEFI support.
So I need both shim-signed:amd64 and shim-signed:i386 installed.
After adding and apt amd64 architecture to an i
Package: debian-live
Severity: wishlist
Dear Maintainer,
As official Debian Live images are going to be signed
by MS keys that will mean that they can be booted
in MS Secure Boot enabled hardware.
Some people might want to be able to use mokutil
binaries from their live cds to enrol new key
I haven't checked every possible combination you put there I guess it's ok.
So, once again looks good to me.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
)
--bootloaders grub-pc,syslinux-efi
in a hdd target and 'syslinux' installation should be only triggered if
it's the first bootloader.
Well, that's exactly how binary_hdd works right now... although the
multi bootloader part should be improved to have something better than:
https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd#L60-86
All of this above is trying to improve multi bootloader support in the
binary_hdd part of live-build. Not sure if you should deal with this
prior to adding your code.
But if you want to take a look and tell us if binary_hdd should be
updated or not (in the end the efi installation is handled by
binary_syslinux-efi or binary_grub-efi in the filesystem level and not
by binary_hdd).
Having to deal with separate bootloaders, what they add or contribute
that's another reason why I prefer binary_syslinux and
binary_syslinux-efi being in different files.
6.3) Many of your commits seem to need a rebase into the current master
branch. Well, that's to be expected.
>
> Gr.
>
> Matthijs
>
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
to live-build because of reasons? Because grub-efi
enabled Secure Boot to work?
Anyways... Did you ever check buxy's work just in case it has something
that you can recycle?
I'll try to comment on "Improve bootloader configuration checks
(5fb9ab31)" on the
mmit should be in its own pull request and not
the current one.
That way it can opt to be applied inmediately while the rest of your
commits is being studied.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
https://salsa.debian.org/live-team/live-build/merge_requests/19
1) What is the rationale behind removing the --templates option
explanation on manpage?
Do you remove it in any of your commits? Which one?
Or someone else did remove it?
Thank you.
Note: I will make more comments about this bu
El 18/03/19 a las 00:39, adrian15 escribió:
> El 09/03/19 a las 18:06, Thomas Schmitt escribió:>> What I'm saying with
> all of this is that I'm going to propose a fix that
>>> involves not using any earmark (which involves too much work) but just
>&g
Unless you know a place where distributions discuss with each other and
another place where remaster tool developers discuss with each other.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
El 13/03/19 a las 09:01, Raphael Hertzog escribió:
> On Tue, 12 Mar 2019, adrian15 wrote:
>> Is it ok for merging in Debian GIT or is there anything that I can improve?
>
> I think it's OK if this was tested and if it doesn't break anything.
Yeah, I tested it in various c
pport arch autodetection is already present in
binary_loopback_cfg. So I only want isolinux support to be added.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From 13730f7f8db6eb9bdd82a06b5c38148c56b227
"686 amd64:amd64"
in a buster i386 chroot and it works flawlessly.
If you want to avoid the grub> prompt with Secure Boot you should apply
patch from #924053 bug too.
Is it ok for merging in Debian GIT or is there anything that I can improve?
Thank you very much!
adrian15
--
s, as long as we only support binary_iso it's fine for now to
rely on /disk/.info (only generated by xorriso) till we find a better
method (like the one suggested by Thomas).
Thank you.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super
El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> 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 compu
El 09/03/19 a las 16:35, Thomas Schmitt escribió:
> 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 i
"${LB_ISO_VOLUME}"
.
As I said I'll work on the /live/id/12345678.ABC approach later.
adrian15
El 09/03/19 a las 15:18, adrian15 escribió:
> I am currently building and testing a label search approach.
> It works manually on both UEFI USB boot and TianaCore UEFI CDROM boot.
&
El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> 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 compu
El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> 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 compu
n I want to compare grub hard disks / devices being detected with
Secure Boot enabled and Secure Boot disabled.
So that we can conclude if this fallback to minimal grub.cfg is
inevitable and attached to Secure Boot or if it's a Secure Boot bug itself.
adrian15
--
Support free software
ends and the user is presented:
grub> .
3) I'll try to do more tests. Maybe renaming /live/vmlinuz in the
internal hard disk partition to mimic non HP250G6 systems but I already
know what's going to happen. I'll get the grub> prompt too because it
will have no useful grub.cfg
42323fa246840ba9581586ad78a8301629d84c/scripts/build/efi-image
Can anyone more experienced than me take a look at the 'signed packages'
'source package' and check how the EFI are actually built?
I guess they use a different script than efi-image or an update one that
chan
path=(hd0,msdos2)/EFI/BOOT # This might be an additional EFI
partition because it only has 'efi' and 'boot' directories.
prefix=(hd0)/boot/grub # USB ( boot/ , efi/, efi.img, isolinux/, live/ y
md5sum.txt )
root=hd0 # USB ( boot/ , efi/, efi.img, isolinux/, live/ y md5sum.txt )
. Anyways any feedback that can speed up my
testing is welcomed.
Thank you very much!
adrian15
Here there is the bisect just in case you need me to test more commits:
( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
for release
( N/A ) 2fa258cca25d834f7896b7adc648
El 20/11/18 a las 14:19, Raphael Hertzog escribió:
Sorry for the delay in answering but I have been busy.
> Hi,
>
> On Sun, 18 Nov 2018, adrian15 wrote:
>> After testing this change the Grub menu which should have two kernel
>> entries has only one. It might be other of m
El 23/02/18 a las 17:43, Raphael Hertzog escribió:
> Hi,
>
> On Sat, 23 Dec 2017, adrian15 wrote:
>> 3) So I dropped that implementation of the patch and searched for
>> something more elegant. A patch that modified the least possible lines
>> of the live-build code
El 21/12/17 a las 14:32, Raphael Hertzog escribió:
> On Sun, 17 Dec 2017, adrian15 wrote:
>>* What led up to the situation?
>
> The reportbug templates are not always very appropriate when you
> just want to submit a patch... just go straight to the explanation
> of
El 21/12/17 a las 14:11, Raphael Hertzog escribió:
> Hi,
>
> On Sat, 16 Dec 2017, adrian15 wrote:
>> Now using:
>>
>> --linux-flavours="amd64:amd64 686"
>>
>> in a i386 system does install amd64 kernel from amd64 architecture in a
>> transp
Package: live-build
Version: 1:20171207
Severity: normal
Control: tags -1 + patch
Dear Maintainer,
* What led up to the situation?
I was trying to build a live cd that has both two kernels: 686 and amd64
and at the same time which would be any hybrid disk so that I can boot
in a BIOS-only ma
Package: live-build
Version: 1:20171207
Severity: normal
Control: tags -1 + patch
Dear Maintainer,
* What led up to the situation?
I was trying to build a live cd that has both two kernels: 686 and amd64
and at the same time which would be any hybrid disk so that I can boot
in a BIOS-only ma
Package: live-build
Version: 1:20171207
Severity: normal
Control: tags -1 + patch
Dear Maintainer,
* What led up to the situation?
I was trying to build a live cd that has both two kernels: 686 and amd64
and at the same time which would be any hybrid disk so that I can boot
in a BIOS-only ma
Control: tags -1 + patch
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
It uses the current git head ( d33943ea7a71ba5d874eb20f47bb898da485c77d )
* Can also be found at:
** Repo: https://github.com/rescatux/live-build.git
** Branch: foreign-architecture-support-quicktest3
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Do
Package: live-build
Version: 1:20171207
Severity: normal
Dear Maintainer,
* Introduction
Jessie had linux-amd64 package in its own i386 section.
Stretch has linux-amd64 package not in i386 section but in amd64 section
only.
When using live-build with Jessie you could use in an i386 Jessie sys
Control: tags -1 + patch
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Control: tags -1 + patch
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Control: tags -1 + patch
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Control: tags -1 + patch
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
ub.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_10
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From 01a9df8ce325c5df9762f0db86128614b4d3476c Mon Sep 17 00:00:00 2001
Fro
El 26/08/16 a las 13:34, Raphael Hertzog escribió:
On Fri, 26 Aug 2016, adrian15 wrote:
Well, it sucks compared to the default visual appearance of
isolinux/syslinux in live-build.
I know, but the purpose of my patch is to add UEFI support. Not to improve
visual appearance of grub2 so that it
El 26/08/16 a las 09:52, Raphael Hertzog escribió:
On Thu, 25 Aug 2016, adrian15 wrote:
That's how the grub-pc menu (BIOS) shows currently in live-build.
Well, it sucks compared to the default visual appearance of
isolinux/syslinux in live-build.
I know, but the purpose of my patch
El 25/08/16 a las 15:36, Raphael Hertzog escribió:
Hello Adrian,
On Tue, 16 Aug 2016, adrian15 wrote:
Kristian Klausen thinks is a good idea to wait for your tests.
So your feedback is welcome.
I just built a test Kali image with your patch applied. It works:
I can boot the live system in
El 04/08/16 a las 14:51, Raphael Hertzog escribió:
Hi,
On Sun, 31 Jul 2016, adrian15 wrote:
Is there anyone else than can provide feedback on this patch / branch?
Either by:
* Installing live-build with this applied patch
* Building your iso and check if it boots in both BIOS and UEFI mode
El 04/08/16 a las 14:51, Raphael Hertzog escribió:
Hi,
On Sun, 31 Jul 2016, adrian15 wrote:
Is there anyone else than can provide feedback on this patch / branch?
Either by:
* Installing live-build with this applied patch
* Building your iso and check if it boots in both BIOS and UEFI mode
ack.
After that time I'll try to request a proper pull / insertion into
Debian's live-build repo and probably into live-build package binaries.
adrian15
El 31/07/16 a las 10:12, Michal Suchanek escribió:
Hello,
On 31 July 2016 at 09:35, adrian15 wrote:
This new update tries to imp
ranch
and can be found here:
http://www.supergrubdisk.org/2016/07/31/rescatux-0-40-beta-7-released/ .
As always feedback is welcome.
El 22/03/16 a las 07:18, Michal Suchanek escribió:
On 21 March 2016 at 23:06, adrian15 wrote:
El 21/03/16 a las 22:19, Michal Suchanek escribió:
So please con
Installing Debian as a single Operating System for your
computer is rather simple. If you need additional help on this help you
can check our tour "Installing Debian".
CSA. 6. Enjoy your Debian
As per your technical role we recommend you to discover the
differen
El 21/03/16 a las 22:19, Michal Suchanek escribió:
Hello,
On 21 March 2016 at 21:09, adrian15 wrote:
The branch which include specifically the commits I attach here as patches
is:
https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5
.
About the variable
El 21/03/16 a las 22:19, Michal Suchanek escribió:
Hello,
On 21 March 2016 at 21:09, adrian15 wrote:
The branch which include specifically the commits I attach here as patches
is:
https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5
.
About the variable
(E.g. please test it on actual hardware, in your
distro builds, even if you don't use UEFI does the ISO boot as always in
BIOS mode?) And give us feedback on it.
Thank you.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://
Package: live-build
Version: 5.0~a11-1
Severity: minor
Dear Maintainer,
* What led up to the situation?
I was trying to use @VERSION@ string in splash.svg.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I used @VERSION@ string in splash.svg.
* What was
erent available binary_bootloaders available.
What's wrong with referencing variables we have so that we know
what's going on in l-b?
Thanks
Michal
Well, basically, my design rationale behind this is that with the
current way of doing things you need to update binary_iso file each
El 25/01/16 a las 16:12, Michal Suchanek escribió:
On 25 January 2016 at 03:05, adrian15 wrote:
El 24/01/16 a las 16:51, Michal Suchanek escribió:
What you are describing here is what it's actually implemented in my patch
(Well, actually the first patch version because the curren
ining what goes into the mkisofs options.
If you check current: binary_iso file it just relies on existing
binary_bootloaders without having an agnostic bootloader approach.
Here it's what I'm talking about:
https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767
functions to binary_bootloader files so
that we have some sort of Object-Oriented / Hook programming when
defining what goes into the mkisofs options.
If you check current: binary_iso file it just relies on existing
binary_bootloaders without having an agnostic bootloader
t;Main bootloader"
and
"Alternate bootloader".
Or maybe even better:
"Main eltorito entry"
and
"Alternate eltorito entry"
?
So that we can force a given bootloader to be used only as a "Main
eltorito entry" ?
What do you think about this idea?
(based on live-build master
branch) here:
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased_4
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org
catux was graphical oriented and that I
left out some cli tools from it. Some sysadmins might consider using
grml instead of Rescatux for cli purposes just for that.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk.
El 21/01/16 a las 12:57, Thomas Schmitt escribió:
adrian15 wrote:
Do you mean if you have:
xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
you could just re-arrange them as:
xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1
and it would be fine?
From the
s refering to USB stick then.
adrian15 wrote:
Grub-pc would be the one installed to be boot but syslinux files would be
there for Multi-USB tools to know how to understand the iso and put it into
an USB.
You mean the capability to boot the ISO via BIOS from USB stick ?
(Known with SYSLINUX as
El 18/01/16 a las 13:38, Thomas Schmitt escribió:
Hi,
adrian15 wrote:
* What is it a secondary bootloader?
It's what happens when you request mkisofs that your bootloader to be
boot in second place or as a second partition. I don't know how it
actually works.
An ISO may contain sev
nse if, as I have stated earlier (although I might have missed
something there) they would overwrite their /efi/boot/boot*efi files ?
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
So that part is solved.
(I'll send a proper rebased set of patches in the future).
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
fix this situation on:
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
and
https://github.com/adrian15/live-build/commits/syslinux-efi-2016
.
(I will probably do another rebase in another branch in the future with
other of your suggestions and these fixes.)
2
El 18/01/16 a las 07:31, Michal Suchanek escribió:
Hello,
thanks for working on this.
On 18 January 2016 at 05:24, adrian15 wrote:
In my last message I forgot to CC many people who are involved in this bug
so I'm going to refer to my former message, CC some people and finally point
you
ad to
your email program and reply from there) can be found at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153
2) Repo / Branches:
* efi_support_based_on_debian_cd (
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd
) : Original dirty branch where I work
droms with syslinux-efi.
The quick and dirty branch where I worked on both grub-efi and
syslinux-efi is here:
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd
That branch is handy to understand the changes between Raphael's
original patch and what I present h
an-installer
scripts which let you translate syslinux configuration files into grub
configuration files.
Feedback is welcome!
P.S.: I am going to release soon: Rescatux 0.40b3 which will be based on
these commits so you will be able to see how it would perform the final
product.
adrian15
--
Sup
I attach a patch based on your work (which I have not tested so feedback
is welcome).
You can find the specific modifications to your original commit/patch
(which I had to cherry-pick) on branch:
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd
Now I'm goi
binary to do such task.
* What outcome did you expect instead?
To have a binary that allows me to unlock a windows user from the
command line.
The two patches that allows the new samunlock binary are:
https://github.com/adrian15/chntpw/commit/b24f36061493ae674dbbcf815e314c6c90103311
https
_USER}" ${SAM_FILE};
* What was the outcome of this action?
The windows user password was not changed.
* What outcome did you expect instead?
I expected the user password to be changed.
You can find the patch that solves this problem in upstream here:
https://github.com/adrian15/chn
es this issue can be found at:
https://github.com/adrian15/chntpw/commit/dc1c6edf135d9d628ab4230605bd778efd7c5dba
Additional note: I already contacted upstream author but received no
answer for
about half a year, so I guess it's fine pushing this to Debian.
-- System Information:
Debian R
issue can be found at:
https://github.com/adrian15/chntpw/commit/684d32504e4875fcb647544cb83903b375f22505
Additional note: I already contacted upstream author but received no
answer for
about half a year, so I guess it's fine pushing this to Debian.
-- System Information:
Debian Releas
El 18/08/15 a las 19:28, Andreas Cadhalpun escribió:
Hi adrian15,
On 18.08.2015 10:47, adrian15 wrote:
Can you please explain why you are using: get_fstype () function which it's
based
on blkid instead of just using the old method of relying in auto function from
the kernel itself?
s is used in both cdrom-detect.patch and mountmedia.patch.
Please, be aware, that I'm not telling you your approach is incorrect.
It seems we are lacking the explanation or rationale on why you made
that decision in order to evaluate that change in a fair manner.
Thank you very much!
adria
Right. Grub does not need to be inside the iso.
Your example is right is the filename is loopback.cfg and not
looback.cfg which I think it's a typo.
El 14/08/15 a las 08:41, Daniel Baumann escribió:
Hi,
just to be sure: loopback.cfg support means that the iso doesn't
necessarily has to have
ck_templates
function in functions/templates.sh, this looks for a local config
template directory and sets the location in the TEMPLATE variable, which
is used later in binary_grub2.
I don't really see the point in grub/grub2 stuff being treated
differently in this way though...
I did not know
El 17/01/15 a las 02:21, jnqnfe escribió:
On 15/01/2015 14:52, adrian15 wrote:
I just write down here that I will have to review your mentioned: #1,
#2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for
loopback.cfg file) so that it matches your improvements and fixes.
No problem, I
ily replace Debian to e.g. Kali from a config file
without too much effort.
As of this moment I have written patches for 11 of these issues, some of
which have already been posted separately. More to follow soon.
Thank you again for your hard work.
adrian
three or more than three
different kernels?
I prefer not to implement i486 vs i686-pae.
I think it's better the patch to be accepted as-is and later to be
improved if someone finds out a reasonable way of improving it for
enabling i486 vs i686-pae.
Thanks
Michal
adrian15
--
Support
Package: grub-common
Version: 2.02~beta2-20
Severity: normal
Dear Maintainer,
* Summary
grub-common not being dependent on mtools package breaks the build of
EFI based
ISOs (thanks to grub-mkrescue) for those of us who did not have mtools
package
installed in first place.
* What led u
El 15/08/14 a las 13:04, Daniel Baumann escribió:
On 08/15/2014 07:12 AM, adrian15 wrote:
I attach a patch for Isolinux / Syslinux implementation for cpu detection.
nice, thanks.
from a quick look, sounds good. will check, test, and apply next week.
As suggested (by another bug) I attach
the kernel filenames.
Just in case you want the detailed commits from debian-old-3.0 to
debian-next they can be found here:
https://github.com/adrian15/live-build/commit/b907d5ca4cfac5407e4231a202b5b84cfcf8c56c
https://github.com/adrian15/live-build/commit/5c7636f8848b3d1d058bb2ed7fd69e01ad05
enames. That's what it's currently implemented.
Any thoughts on how to approach the binary_syslinux renaming the kernel
filenames or is it ok the way I'm doing it?
Thank you.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super
I know that:
git push --force
is kind of forbidden when working in public with other people.
As this is my kind of personal repo I did it.
So the replaced commit (which only fixes file permissions) is found at:
https://github.com/adrian15/live-build/commit
Just in case it's easier for you to accept my patch you can also find it
in this git repo commit based on live-build git repo:
https://github.com/adrian15/live-build/commit/c6da5ff61bb46cb66b23fcb66daa83e23fc8a36b
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el sof
I have these same patches available for live-build package on my
live-build git repo here:
Isolinux:
https://github.com/adrian15/live-build/commit/4419638ab9cdfb1bacd98593e31d7f700b15a2dc
Grub2 :
https://github.com/adrian15/live-build/commit/a06085381ba346b576064ee84b325de54a81e33d
Just in
ease 1 GB, 2 GB and 4 GB size images
for each one of the usb media size you want to provide to.
Have a nice day :)
Thomas
Thank your for input. Somehow I thought that my 4 GB hard disk test
after dding the ~ 500 GB image would have been detected as a 500 GB size
only hard disk.
adrian15
#656135.
Feel free to make depend this bug on #724931 if that it makes sense (not
very experienced on BTS and Debian policies).
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
--
To UNSUBSCR
me tests in the next days to prove if the minimal
functionality needed actually works or if it would need hacks on how Gnu/Linux
kernel reads devices bigger than its partition table suggested size.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a
ourse).
9) You should boot into your Debian Live without problems (thanks to
findiso boot parametre).
If you ever wanted to test from your grub2 installation instead from
Super Grub2 Disk check: http://www.supergrubdisk.org/wiki/Loopback.cfg
for an example.
adrian15
--
Support free software. D
I attach a patch for CPU detection when Debian Live uses grub2 as its
bootloader.
Please advise how to improve it so that it gets included upstream.
Thank you.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http
=deb15c765e2b34fe587c96ca590981a59a278922
Upstream documentation: http://www.syslinux.org/wiki/index.php/Ifcpu64.c32
Thank you!
I attach a patch for Isolinux / Syslinux implementation for cpu detection.
Please advise how to improve the implementation so that it can be
accepted upstream.
Thank you.
adrian15
First of all I've managed to fix the problem on the fly inspired from
the related bug.
So you boot with break=init and I run:
mkdir -p live
mount -t tmpfs tmpfs /live
exit
and the system seems to boot ok.
El 09/09/12 19:14, Daniel Baumann escribió:
On 2012-09-09 18:55, adrian15
Package: live-boot
Version: 3.0~b2-1
Severity: important
When building an Squeeze debian live cd inside an Squeeze system and
trying to use live-boot* packages from unstable seems to be broken.
When I boot I get:
Loading, please wait..., run-init: nuking initramfs contents: Directory
not emp
ings about what doesn't work on stable make
easier your work.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.o
ONE)
as background.
That fits into Case A.
Not sure what causes this bug yet.
El 20/01/12 00:28, adrian15 escribió:
I have done more tests and this is what I have found:
Case A: When I get a black background:
==
/home/user/.config/pcmanfm/LXDE
1 - 100 of 125 matches
Mail list logo
