Amideb: An Amiga Emulator System

[giantclam]

Continuing AmiDeb testing....

[Tested]

The solution to the above wrt nvidia drivers ...as in fix things when the nvidia driver either doesn't install, or turns out to be the wrong nivdia driver to support a user's GPU...(which can happen, as I have already identified the nvidia chipset support lists are broken in places)...

sudo apt purge "*nvidia*" && systemctl reboot

This used to be ugly years ago, but the above worked fine on AmiDeb x86 build.

There still exists the caveat that it may not work, and another apt command is required, but one could probably combine all together on a 'just in case' basis ...ie; sudo apt purge "*nvidia*" && sudo apt install --reinstall xserver-xorg-core xserver-xorg-video-nouveau && systemctl reboot

That said, the original cmd worked fine... see -> https://wiki.debian.org/NvidiaGraphi...Uninstallation

amiga@AmiDeb-x86:~$ sudo su
[sudo] password for amiga:

...I actually query this, because I'm sick & tired of typing amiga =) I kinda think a passwordless sudo setup may be less ...user intensive =)

I've had the AmiDeb install sitting to one side, knowing that time alone would present a chance to test apt update ...

root@AmiDeb-x86:/home/amiga# apt update
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://ftp.debian.org/debian bullseye InRelease                           
Hit:3 http://ftp.debian.org/debian bullseye-updates InRelease                   
Get:4 http://download.opensuse.org/repositories/home:/FrodeSolheim:/stable/Debian_11  InRelease [1,546 B]
Err:4 http://download.opensuse.org/repositories/home:/FrodeSolheim:/stable/Debian_11  InRelease
  The following signatures were invalid: EXPKEYSIG BF2C3F2504BFEF00 home:FrodeSolheim OBS Project <home:FrodeSolheim@build.opensuse.org>

I was working over ssh, and noticed this ~ I don't believe it's critical, but obviously if there is an fs-uae update, AmiDeb users won't get it =) Likely only matters if there's some big fs-uae update and the user can't get the package (as it may not exist yet =)


//GameMode: Request failed: dlopen failed - libgamemode.so: cannot open shared object file: No such file or directory


...pretty sure fs-uae called this on AmiDeb.... deliberate exclusion? I don't see this on AmiLFS (and certainly I didn't compile libgamemode), but it seems to infer the AmiDeb install is missing libgamemode0 ..? I'll circle back to this next time I have AmiDeb booted =)

[giantclam]

..pretty sure fs-uae called this on AmiDeb.... deliberate exclusion? I don't see this on AmiLFS (and certainly I didn't compile libgamemode), but it seems to infer the AmiDeb install is missing libgamemode0 ..? I'll circle back to this next time I have AmiDeb booted =)

Checked this ~ libgamemode0 does satisfy that dependency, but then it crashes into dbus. I kinda get the impression that 2 packages aren't in sync _or_ it's a multilib vs x86 build thang (going by stuffs read @ gamemode github page)....meh... either way it's non-critical. It revolves around a specific usage scenario, which AmiDeb doesn't quite fit into due to it's custom installation makeup =)

[giantclam]

@vk3heg

...and, we're off...

target machine: Dell Optiplex 9020 USFF Desktop PC i5-4570s @2.90 8GB DDR3 120GB SSD
installed OS : win10 (pre-installed to OOTB point, which was allowed to complete with all fields filled by 'fu' 8)

I just turned it on...

You get double Dell'd by POST bootsplash and (efi?/blootloader?) -- tapping F2/Del will land you in BIOS

*I was hoping for (U)EFI, but this is more custom DellUEFI setup, common to the Optiplex range. There is an onboard bios service jumper you need to set, to be able to access some elements of the bios itself.

**Attempt 1 -- failed.

As the boot media does not contain an UEFI image, bios does not flag the drive as being bootable ; ergo, flip the bios into legacy mode, and then you can get it to boot from usb drive ; the debian installer starts, partitions the drive, but big redscreen as it can't format the drive.

~~ cross check 1: flash stock debian install iso to usb drive, and see how that goes....

**Test 1 -- passed.

Installed debian 11.6 netinst via usb stick -- no problems, could format drive


~~ cross check 2: go back into DellUEFI land, and flick the bios to UEFI mode, and see how debian handles it


**Test 2 -- passed

Debian netinst on USB stick immediately recognized as valid boot device
Note: windows EFI bootmgr gone


**Attempt 2 -- failed.

This was using the usb stick image vk3heg release a little while ago ; this booted, didn't fail the format disks stage, installed necessary packages and fail at grub_install. It's trying to install grub on /dev/sda ...which is the USB stick =) It should be trying to install grub to /dev/sdb. I'd be thinking the windows efi bootmgr somehow had a lock on the hdrive ; debian11 somehow said 'so what' and did it's job.

~~ cross check 3: just nip back into DellUEFI land, and flick the bios to UEFI mode, and see if this AmiDeb installer is recognized

**Test 3 -- failed

Doesn't show up in UEFI as expected, but I noticed bios legacy mode lists the ssd twice if 'diskette drive' is selected. Maybe this is facilitate USB-FDD or something, but I figured I should at least retry Attempt 2 with this switch off -- it still failed at install grub.

**Attempt 3 -- failed

Checking to see if AmiDeb x86 fairs any better ; now gets over mkfs error, installs everything and fails as above, on grub install. FTR, the USB boot drive appears @ SCSI3(0,0,0) [sda] and the ssd appears @ SCSI1(0,0,0) [sdb] on this hw.

**Sanity check -- passed

Installed debian 11.6 netinst via usb stick, twice (minimal base system install) -- once with bios in legacy mode, once with bios in UEFI mode ; both runs passed as debian tends to do.

Conclusions -- TBH when it saw red when mkfs failed (actually, write changes to disk..fdisk fails, and thus there is no partition at the point mkfs is aimed at), for a moment I thought I was going to need open it up, and bridge the bios management jumper. but prudently figured to at least let debian hava'go'ya'mug ...and of course, it's debian, it has no problems with this hw/bios...debian is kinda like the Borg, it'll install to anything if left in proximity of a tinkerer and 'unknown' device =)

The Amideb install process has it 'correct' @ partition device, format, mount $target rootdev (sdb), and installs to that drive, but when it hits grub install, it's on magic mushrooms and concludes $target rootdev is (sda)...hmmm....

...I'm not terribly conversant with debian installer scripting, but, there must be some semantic 'broken' here around the AmiDeb grub install stage, because typically 1) debian gets it right && 2) iirc if the debian installer falls on it's face here, it used to popup another menu allowing you to manually select which drive/partition you actually want to install grub to....(probably or not necessarily a wise option to toss up at unknowing users =) There must be something else deb installer uses here that AmiDeb isn't including, to provide the heuristics required to deduce the 'correct' drive target, as already established in the select/setup drive stage....weird stuff...as in, AmiDeb has no problems at all installing to (real) legacy style bios, but the Dell Optiplex is being a macadamia type hard nut for AmiDeb to crack =)

HTH