Re: debugging apt-get
On Wed, 12 Oct 2022, Stefan Seefeld wrote: On Wednesday, 12 October 2022 at 01:10:06 UTC-4, tomas wrote: Try doing "apt-cache policy Y", that might shed light on this. This reports ``` Y: Installed: (none) Candidate: 1.0.3 Version table: 1.0.3 500 500 focal/main amd64 Packages 1.0.1 500 500 focal/main amd64 Packages ``` (I'm running on Ubuntu 20.04, using apt-get=2.0.6) (Isn't there a Ubuntu mailing list, btw? They might be doing funny stuff with their packaging which perhaps change the problem space) The repo is actually our own in-house repo (managed via artifactory). Are there any clear semantic rules spelled out in some document that govern what should happen ? I'm surprised that if my package "X" has specific and unambiguous dependencies on an existing package "Y", and that version exists in the repo, it should be installed. Am I missing something ? In your original command you had X as a file on the commandline. Does it work when X is in a repo? I have my own repo and I've had no issues like this. $ apt-mark showauto | grep dump dump $ apt-mark showmanual | grep backup backup $ Is there something strange about what release or architecture X thinks it is in? Perhaps that is why apt won't autoinstall Y but Y can satisfy X's dependencies. This file has all the debugging options for apt: /usr/share/doc/apt/examples/configure-index -o Debug::pkgProblemResolver=yes might show something. (that's a guess, I've not used this option)
MUD
Hi, Is there so user of the mailing list who operate or have interest in MUD style services ? Or even who have some knowledge of solutions using Unix/Linux based BBS ? I'd like to setup such service. Thanks -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
Re: debugging apt-get
On Wednesday, 12 October 2022 at 01:10:06 UTC-4, tomas wrote: > Try doing "apt-cache policy Y", that might shed light on this. This reports ``` Y: Installed: (none) Candidate: 1.0.3 Version table: 1.0.3 500 500 focal/main amd64 Packages 1.0.1 500 500 focal/main amd64 Packages ``` > > (I'm running on Ubuntu 20.04, using apt-get=2.0.6) > (Isn't there a Ubuntu mailing list, btw? They might be doing funny stuff > with their packaging which perhaps change the problem space) The repo is actually our own in-house repo (managed via artifactory). Are there any clear semantic rules spelled out in some document that govern what should happen ? I'm surprised that if my package "X" has specific and unambiguous dependencies on an existing package "Y", and that version exists in the repo, it should be installed. Am I missing something ? Is this an `apt-get` bug ? Is there any way to debug this further ? (For a specific case I can work around the issue by injecting an explicit `apt-get install` command, but this is of course not a scalable solution for the general case.) Would there be another place (perhaps an apt-get - specific mailing list or bug tracker) where I can follow up to try to resolve this ? Thanks,
Re: Some of the parameters used in my genisoimage command don't produce a bootable ISO image
Hello.
What I haven't understood well is if, in your opinion, this "code" is well
written or not :
menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true
initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet
splash "${loopback}"
initrd /d-i/gtk/initrd.gz
It works,but maybe it can work even if it is not the best way to do it.
Il giorno mer 12 ott 2022 alle ore 12:04 Mario Marietto <
marietto2...@gmail.com> ha scritto:
> Actually I'm using only UEFI and the file that I should modify is located
> on
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/grub/grub.cfg.
> What works is this :
>
> menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true
> initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet
> splash "${loopback}"
> initrd /d-i/gtk/initrd.gz
> }
>
> NOT this :
>
> menuentry "English (en)" {
> linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
> initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet
> splash intel_iommu=on "${loopback}"
> initrd /live/initrd.gz
> }
>
> I think because the script that detects the presence of the preseed file
> is inside the /d-i/gtk/initrd.gz and NOT inside /live/initrd.gz. Maybe
> something like this will work ?
>
> menuentry "English (en)" {
> linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
> initrd=/d-i/gtk/initrd.gz boot=live components locales=en_US.UTF-8 quiet
> splash intel_iommu=on "${loopback}"
> initrd /d-i/gtk/initrd.gz
> }
>
> or :
>
> menuentry "Graphical Debian Installer" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
> video=vesa:ywrap,mtrr vga=788 "${loopback}"
> initrd /d-i/gtk/initrd.gz
> }
>
> I'm not interested in modifying the isolinux / menu.cfg file,so I will
> remove from there any reference to the preseed.cfg file.
>
> Il giorno mer 12 ott 2022 alle ore 08:39 Thomas Schmitt
> ha scritto:
>
>> Hi,
>>
>> Mario Marietto wrote:
>> > In the end I found the solution.
>>
>> Congrats.
>>
>> -
>> Some remarks on the way to success:
>>
>> > isolinux/menu.cfg
>> > LABEL English (en)
>> > SAY "Booting English (en)..."
>> > linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
>>
>> I think "APPEND" should be in an extra line. At least it is so in the
>> examples which i saw up to now.
>>
>>
>> > boot/grub/grub.cfg
>> > menuentry "English (en)" {
>> > linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
>>
>> "APPEND" is SYSLINUX/ISOLINUX speech, not GRUB.
>> I assume that this "APPEND" is handed over to the Linux kernel as
>> argument, like the others.
>>
>>
>> > the grub.cfg file
>> > uses two command lines. The second one is "initrd /live/initrd.gz".
>>
>> https://www.gnu.org/software/grub/manual/grub/grub.html#initrd
>> https://www.gnu.org/software/grub/manual/grub/grub.html#linux
>>
>>
>> > What is "${loopback}" in the context below ?
>> > set loopback="findiso=${iso_path}"
>> > export loopback
>> > ...
>> > linux /live/vmlinuz ... "${loopback}"
>>
>> Interesting question, again.
>>
>>
>> > In the end I found the solution.
>> > menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
>> > linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
>>
>> I really wonder what the kernel thinks when seeing this "APPEND", of which
>> i still think is not appropriate.
>> I'd try in any case whether it can be omitted. If this remains as
>> successful end of this thread, then i fear that future readers might get
>> confused by it.
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>
> --
> Mario.
>
--
Mario.
Re: Some of the parameters used in my genisoimage command don't produce a bootable ISO image
Actually I'm using only UEFI and the file that I should modify is located
on
/home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/grub/grub.cfg.
What works is this :
menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true
initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet
splash "${loopback}"
initrd /d-i/gtk/initrd.gz
}
NOT this :
menuentry "English (en)" {
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet
splash intel_iommu=on "${loopback}"
initrd /live/initrd.gz
}
I think because the script that detects the presence of the preseed file is
inside the /d-i/gtk/initrd.gz and NOT inside /live/initrd.gz. Maybe
something like this will work ?
menuentry "English (en)" {
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
initrd=/d-i/gtk/initrd.gz boot=live components locales=en_US.UTF-8 quiet
splash intel_iommu=on "${loopback}"
initrd /d-i/gtk/initrd.gz
}
or :
menuentry "Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
}
I'm not interested in modifying the isolinux / menu.cfg file,so I will
remove from there any reference to the preseed.cfg file.
Il giorno mer 12 ott 2022 alle ore 08:39 Thomas Schmitt
ha scritto:
> Hi,
>
> Mario Marietto wrote:
> > In the end I found the solution.
>
> Congrats.
>
> -
> Some remarks on the way to success:
>
> > isolinux/menu.cfg
> > LABEL English (en)
> > SAY "Booting English (en)..."
> > linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
>
> I think "APPEND" should be in an extra line. At least it is so in the
> examples which i saw up to now.
>
>
> > boot/grub/grub.cfg
> > menuentry "English (en)" {
> > linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
>
> "APPEND" is SYSLINUX/ISOLINUX speech, not GRUB.
> I assume that this "APPEND" is handed over to the Linux kernel as
> argument, like the others.
>
>
> > the grub.cfg file
> > uses two command lines. The second one is "initrd /live/initrd.gz".
>
> https://www.gnu.org/software/grub/manual/grub/grub.html#initrd
> https://www.gnu.org/software/grub/manual/grub/grub.html#linux
>
>
> > What is "${loopback}" in the context below ?
> > set loopback="findiso=${iso_path}"
> > export loopback
> > ...
> > linux /live/vmlinuz ... "${loopback}"
>
> Interesting question, again.
>
>
> > In the end I found the solution.
> > menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
> > linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
>
> I really wonder what the kernel thinks when seeing this "APPEND", of which
> i still think is not appropriate.
> I'd try in any case whether it can be omitted. If this remains as
> successful end of this thread, then i fear that future readers might get
> confused by it.
>
>
> Have a nice day :)
>
> Thomas
>
>
--
Mario.
Re: Issues with audio after updating
Alsa works fine, I'm able to play sound over jack with software that let's you pick the audio device (Reaper in my case) Removing and reinstalling piperwire fixed the issue, but I have no idea why El lun, 10 oct 2022 a las 23:16, Joel Roth () escribió: > > On Sun, Oct 09, 2022 at 10:37:18AM +0200, Maximiliano Estudies wrote: > > After an update yesterday my audio stopped working. I'm currently on > > Linux version 5.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 > > (Debian 11.3.0-6) 11.3.0, GNU ld (GNU Binutils for Debian) > > 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24) > > > > The issue seems to be with pulseaudio, but I'm not really sure. > > pavucontrol shows "no available cards for configuration" on the > > configuration tab, and ```pactl list cards``` returns nothing but > > ```pacmd list-cards``` does returns all the available cards. There is > > a similar behavior when listing the sinks, pactl returns only the > > dummy sink and pacmd returns the alsa sink, but with state: IDLE > > > > I have no idea how to debug this further so any tips are much appreciated! > > Hiya Maximiliano, > > That the two pulseaudio utilities disagree on what devices > are present, it seems plausible that some part of pa is to blame. > > You may like to verify that your ALSA subsystem is working properly, > and include this in your bug report. > > For that, disable pulseaudio[1], > > systemctl --user stop pulseaudio.socket > systemctl --user stop pulseaudio.service > > test play an audio file with aplay, mpv, etc. > to a device listed by aplay -l, or cat /proc/asound/cards > > To start pulse audio again: > > systemctl --user start pulseaudio.socket > systemctl --user start pulseaudio.service > > 1. > https://askubuntu.com/questions/8425/how-to-temporarily-disable-pulseaudio-while-running-a-game-under-wine > > I've not tested this myself. > > cheers, > > -- > Joel Roth >
