From Newsgroup: alt.os.linux.suse


does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and you're working in the (artix) installation of choice. Pretty cool.
--
"Peace is better than war; in peace the sons bury their fathers, in wars
the fathers their sons". Croesus

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

bad sector <forgetski@_INVALID.net> Wrote in message:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and you're working in the (artix) installation of choice. Pretty cool.

I don't know about artix, but I've used chroot a few times to
recover the boot files after I've screwed them up. Starting from
a rescue dvd or grub - I forget.
--
Remove numerics from my email address.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 7/26/24 02:49, Dave Royal wrote:

bad sector <forgetski@_INVALID.net> Wrote in message:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and you're
working in the (artix) installation of choice. Pretty cool.

I don't know about artix, but I've used chroot a few times to
recover the boot files after I've screwed them up. Starting from
a rescue dvd or grub - I forget.

Yeh, you can do a chroot but if you don't do it often enough it's easy
to screw up. What the Artix devs wrote is a script that takes care of
the elbow grease. Say you nuke an Artix installation, boot any oyther
one including live or installer or rescue and do 'chroot-artix dev/sdx'
and you're in the toasted system ready to make repairs. Every installer,
live or rescue should have suh a utility.

My desktop is having issues and it's been all traced to a bad AMD video
card I had bought used not long ago. The card before that was nvidia
which I had promised myself never to buy again. So I've bought a new AMD
but am using the nvidia 'interim' waiting for delivery of the new card.
When I booted TW with the nvidia plugged in and there was no login,
would be nice to boot a live DVD and just install the nvidia drivers for
the time being.

Actually, TW should just load the drivers for the existing hardware and
get on with it. I think my Devuan installation did just that.



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

bad sector <forgetski@_INVALID.net> Wrote in message:

On 7/26/24 02:49, Dave Royal wrote:

bad sector <forgetski@_INVALID.net> Wrote in message:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and you're
working in the (artix) installation of choice. Pretty cool.

I don't know about artix, but I've used chroot a few times to
recover the boot files after I've screwed them up. Starting from
a rescue dvd or grub - I forget.

Yeh, you can do a chroot but if you don't do it often enough it's easy
to screw up. What the Artix devs wrote is a script that takes care of
the elbow grease. Say you nuke an Artix installation, boot any oyther
one including live or installer or rescue and do 'chroot-artix dev/sdx'
and you're in the toasted system ready to make repairs. Every installer, live or rescue should have suh a utility.

My desktop is having issues and it's been all traced to a bad AMD video
card I had bought used not long ago. The card before that was nvidia
which I had promised myself never to buy again. So I've bought a new AMD
but am using the nvidia 'interim' waiting for delivery of the new card.
When I booted TW with the nvidia plugged in and there was no login,
would be nice to boot a live DVD and just install the nvidia drivers for
the time being.

Actually, TW should just load the drivers for the existing hardware and
get on with it. I think my Devuan installation did just that.

In Leap 15.6 - maybe also TW - nvidia (or SUSE - I don't know who
decided) have dropped the drivers (designated G04 = v390) for a
group of old cards from the non-free nvidia repo. I had to remove
the old G04 pkgs (from Leap 15.5) to it to work with the nouveau
driver. When I tried the G05 driver pkg it failed to start X.


I bought a more recent card (-u25 at CeX) expecting to have to
configure X to use the nvidia driver, but it did it
automatically. (Though I already had the G05 pkgs
installed.)
--
Remove numerics from my email address.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 7/28/24 02:49, Dave Royal wrote:

bad sector <forgetski@_INVALID.net> Wrote in message:

On 7/26/24 02:49, Dave Royal wrote:

bad sector <forgetski@_INVALID.net> Wrote in message:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and you're >>>> working in the (artix) installation of choice. Pretty cool.

I don't know about artix, but I've used chroot a few times to
recover the boot files after I've screwed them up. Starting from
a rescue dvd or grub - I forget.

Yeh, you can do a chroot but if you don't do it often enough it's easy
to screw up. What the Artix devs wrote is a script that takes care of
the elbow grease. Say you nuke an Artix installation, boot any oyther
one including live or installer or rescue and do 'chroot-artix dev/sdx'
and you're in the toasted system ready to make repairs. Every installer,
live or rescue should have suh a utility.

My desktop is having issues and it's been all traced to a bad AMD video
card I had bought used not long ago. The card before that was nvidia
which I had promised myself never to buy again. So I've bought a new AMD
but am using the nvidia 'interim' waiting for delivery of the new card.
When I booted TW with the nvidia plugged in and there was no login,
would be nice to boot a live DVD and just install the nvidia drivers for
the time being.

Actually, TW should just load the drivers for the existing hardware and
get on with it. I think my Devuan installation did just that.

In Leap 15.6 - maybe also TW - nvidia (or SUSE - I don't know who
decided) have dropped the drivers (designated G04 = v390) for a
group of old cards from the non-free nvidia repo. I had to remove
the old G04 pkgs (from Leap 15.5) to it to work with the nouveau
driver. When I tried the G05 driver pkg it failed to start X.


I bought a more recent card (-u25 at CeX) expecting to have to
configure X to use the nvidia driver, but it did it
automatically. (Though I already had the G05 pkgs
installed.)

For my desktop it had been the g04 package but even when working and downloadable it was *always* a pain in the ass! Slow speeds, interrupted downloads, you name it. So one day when it AGAIN became a royal PITA for
any number of by then familiar reasons I got just plain fed up and
swapped it out, still working, for a radeon. There is NO WAY that I will
ever buy another nvidia anything. The replacement 16gb asus-rx-7600
should be here within days, I could struggle with chroot to temporarily backlevel to the nvidia but I will not.



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 07-25-2024 06:46PM, bad sector wrote:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and you're working in the (artix) installation of choice. Pretty cool.

I would like to respond to your message because I recently had an issue
with the Tumbleweed machine here not booting after a 'zypper dup'. The
machine was halted at displayed 'GRUB _' prompt after passing the LUKS passphrase. I was able to boot a live Tumbleweed image into Rescue Mode
and then perform the Chroot.
https://www.suse.com/support/kb/doc/?id=000018770

Notes taken:
Have a problem after 'zypper dup' , displays only GRUB _ after booting.

Suggested help link > https://www.suse.com/support/kb/doc/?id=000018770
-
Trying
-
1. First boot the system into Rescue Mode from the media. For best
results use media that matches the version and service pack of the system.
-
2. Once it's finished loading, log in as root.
-
3. Mount the root partition or logical volume to /mnt
mount /dev/<device name> /mnt
I used > # mount /dev/mapper/system-root /mnt
If it's not known where the root file system is, it needs to be guessed
until found by mounting each possibility and checking its contents. Run
the following command to list all available partitions: > cat /proc/partitions
Display all available logical volums > lvdisplay
After mounting each one check its contents by listing the mounted
directory. For example if mounted to /mnt run: > ls /mnt
Some directories that should be listed to verify it is a root file
system are /root, /boot and /home.
4. Once mounted use the following for-loop to rbind the virtual file
systems: >
for i in proc sys dev run; do mount --rbind /$i /mnt/$i ; done Alternatively, mount them each separately rather than using the for-loop:
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev
mount --rbind /run /mnt/run
-
5. After the root file system and virtual file systems are mounted run
this command to chroot in: >
chroot /mnt
-
After chrooted in it is a best-practice to run this command to make sure
all other necessary partitions are also mounted:
mount -a

I usually do > mount -t -t btrfs < instead of > mount -a
-
corrective action , run > "update-bootloader --reinit"
corrective action, run If the initrd has been damaged or invalid , it
can be recreated : > mkinitrd
-
Exit out of chroot
-
Powercycle the machine
-
Appears to be success
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 8/14/24 14:43, panorain wrote:

On 07-25-2024 06:46PM, bad sector wrote:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and
you're working in the (artix) installation of choice. Pretty cool.

I would like to respond to your message because I recently had an issue
with the Tumbleweed machine here not booting after a 'zypper dup'. The machine was halted at displayed 'GRUB _' prompt after passing the LUKS passphrase. I was able to boot a live Tumbleweed image into Rescue Mode
and then perform the Chroot. https://www.suse.com/support/kb/doc/?id=000018770

Notes taken:
Have a problem after 'zypper dup' , displays only GRUB _ after booting.

Suggested help link > https://www.suse.com/support/kb/doc/?id=000018770
-
Trying
-
1. First boot the system into Rescue Mode from the media. For best
results use media that matches the version and service pack of the system.
-
2. Once it's finished loading, log in as root.
-
3. Mount the root partition or logical volume to /mnt
-a-a-a-a mount /dev/<device name> /mnt
I used > # mount /dev/mapper/system-root /mnt
If it's not known where the root file system is, it needs to be guessed until found by mounting each possibility and checking its contents. Run
the following command to list all available partitions: >-a-a-a cat /proc/partitions
Display all available logical volums > lvdisplay
After mounting each one check its contents by listing the mounted
directory. For example if mounted to /mnt run: > ls /mnt
Some directories that should be listed to verify it is a root file
system are /root, /boot and /home.
4. Once mounted use the following for-loop to rbind the virtual file systems: >
-a-a-a for i in proc sys dev run; do mount --rbind /$i /mnt/$i ; done Alternatively, mount them each separately rather than using the for-loop:
-a-a-a mount --rbind /proc /mnt/proc
-a-a-a mount --rbind /sys /mnt/sys
-a-a-a mount --rbind /dev /mnt/dev
-a-a-a mount --rbind /run /mnt/run

Yes, that is very close to or is in fact the canonical procedure. The chroot-artix command DOES footwork like the above for the user leaving
no steps to be missed in error. Actually, chroot in such a form 'could'
really be just an argument for the CD command. When the path of the
mountable but unbootable "/" is let's say /dev/sda8 then it could go
like this

# cd --system /dev/sda8

end of story.

I'm not sure about this but I think that in a conventional chroot the currently loaded kernel continues in use. Even this could be subject of another argument

# cd --system --kernel /boot/vmlinuz /dev/sda8

or words to that effect. Not being familiar with grub2 at cLi level I
would, after a good chroot, just issue the call

yast

and set the boot up all over again in yast ncurses.

Ideally I would also be able to log in as user and just do

~ startx

All the Live, Rescue and Installer DVD's should have such or similar
rescue features designed to operate in an existing but sick partition including a 'dr.suse' command that just looks to find out what's wrong
with an intallation and proposes fixes it can execute.

-
5. After the root file system and virtual file systems are mounted run
this command to chroot in: >
-a-a-a chroot /mnt
-
After chrooted in it is a best-practice to run this command to make sure
all other necessary partitions are also mounted:
-a-a-a-a mount -a

I usually do > mount -t -t btrfs < instead of > mount -a
-
corrective action , run > "update-bootloader --reinit"
corrective action, run-a If the initrd has been damaged or invalid , it
can be recreated : >-a mkinitrd
-
Exit out of chroot
-
Powercycle the machine
-
Appears to be success

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 08-14-2024 05:38PM, bad sector wrote:

On 8/14/24 14:43, panorain wrote:

On 07-25-2024 06:46PM, bad sector wrote:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and
you're working in the (artix) installation of choice. Pretty cool.

I would like to respond to your message because I recently had an
issue with the Tumbleweed machine here not booting after a 'zypper
dup'. The machine was halted at displayed 'GRUB _' prompt after
passing the LUKS passphrase. I was able to boot a live Tumbleweed
image into Rescue Mode and then perform the Chroot.
https://www.suse.com/support/kb/doc/?id=000018770

Notes taken:
Have a problem after 'zypper dup' , displays only GRUB _ after booting.

Suggested help link > https://www.suse.com/support/kb/doc/?id=000018770
-
Trying
-
1. First boot the system into Rescue Mode from the media. For best
results use media that matches the version and service pack of the
system.
-
2. Once it's finished loading, log in as root.
-
3. Mount the root partition or logical volume to /mnt
-a-a-a-a-a mount /dev/<device name> /mnt
I used > # mount /dev/mapper/system-root /mnt
If it's not known where the root file system is, it needs to be
guessed until found by mounting each possibility and checking its
contents. Run the following command to list all available partitions:

-a-a-a cat /proc/partitions

Display all available logical volums > lvdisplay
After mounting each one check its contents by listing the mounted
directory. For example if mounted to /mnt run: > ls /mnt
Some directories that should be listed to verify it is a root file
system are /root, /boot and /home.
4. Once mounted use the following for-loop to rbind the virtual file
systems: >
-a-a-a-a for i in proc sys dev run; do mount --rbind /$i /mnt/$i ; done
Alternatively, mount them each separately rather than using the for-loop:
-a-a-a-a mount --rbind /proc /mnt/proc
-a-a-a-a mount --rbind /sys /mnt/sys
-a-a-a-a mount --rbind /dev /mnt/dev
-a-a-a-a mount --rbind /run /mnt/run

Yes, that is very close to or is in fact the canonical procedure. The chroot-artix command DOES footwork like the above for the user leaving
no steps to be missed in error.

Artix doesn't use systemD so could the chroot-ArtiX script be used as a
pre installed and available systemD service that could be started and
run? Something "dr.suse" could possibly handle even?

Actually, chroot in such a form 'could'

really be just an argument for the CD command. When the path of the mountable but unbootable "/" is let's say /dev/sda8 then it could go
like this

# cd --system /dev/sda8

end of story.

I'm not sure about this but I think that in a conventional chroot the currently loaded kernel continues in use. Even this could be subject of another argument

Can this cause problems (chrooting with currently loaded kernel), on
live loaded (rescue) media? Such as the chroot attempt failing or
whatnot? If that kernel version is different than the afflicted
filesystems kernel version?

# cd --system --kernel /boot/vmlinuz /dev/sda8

or words to that effect. Not being familiar with grub2 at cLi level I
would, after a good chroot, just issue the call

yast

and set the boot up all over again in yast ncurses.

I don't think you need to "set the boot up all over again" after each
chroot. I did not need to. Are you referring to modifying and updating
Grub?

Ideally I would also be able to log in as user and just do

~ startx

Have you heard anything about "startx" to not be preferably used anymore
and defunk?

All the Live, Rescue and Installer DVD's should have such or similar
rescue features designed to operate in an existing but sick partition including a 'dr.suse' command that just looks to find out what's wrong
with an intallation and proposes fixes it can execute.

What conditions cause this problem (chroot to be required)? Do you know
why possibly the chroot was required on the machine here and not others
that used zypper dup at that time?

This is the openSUSE project managment page > https://progress.opensuse.org/

"dr.suse" sounds like a good thought.

-
5. After the root file system and virtual file systems are mounted run
this command to chroot in: >
-a-a-a-a chroot /mnt
-
After chrooted in it is a best-practice to run this command to make
sure all other necessary partitions are also mounted:
-a-a-a-a-a mount -a

I usually do > mount -t -t btrfs < instead of > mount -a
-
corrective action , run > "update-bootloader --reinit"
corrective action, run-a If the initrd has been damaged or invalid , it
can be recreated : >-a mkinitrd
-
Exit out of chroot
-
Powercycle the machine
-
Appears to be success

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 8/15/24 21:30, panorain wrote:

On 08-14-2024 05:38PM, bad sector wrote:

On 8/14/24 14:43, panorain wrote:

On 07-25-2024 06:46PM, bad sector wrote:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and
you're working in the (artix) installation of choice. Pretty cool.

I would like to respond to your message because I recently had an
issue with the Tumbleweed machine here not booting after a 'zypper
dup'. The machine was halted at displayed 'GRUB _' prompt after
passing the LUKS passphrase. I was able to boot a live Tumbleweed
image into Rescue Mode and then perform the Chroot.
https://www.suse.com/support/kb/doc/?id=000018770

Notes taken:
Have a problem after 'zypper dup' , displays only GRUB _ after booting.

Suggested help link > https://www.suse.com/support/kb/doc/?id=000018770
-
Trying
-
1. First boot the system into Rescue Mode from the media. For best
results use media that matches the version and service pack of the
system.
-
2. Once it's finished loading, log in as root.
-
3. Mount the root partition or logical volume to /mnt
-a-a-a-a-a mount /dev/<device name> /mnt
I used > # mount /dev/mapper/system-root /mnt
If it's not known where the root file system is, it needs to be
guessed until found by mounting each possibility and checking its
contents. Run the following command to list all available partitions:

-a-a-a cat /proc/partitions

Display all available logical volums > lvdisplay
After mounting each one check its contents by listing the mounted
directory. For example if mounted to /mnt run: > ls /mnt
Some directories that should be listed to verify it is a root file
system are /root, /boot and /home.
4. Once mounted use the following for-loop to rbind the virtual file
systems: >
-a-a-a-a for i in proc sys dev run; do mount --rbind /$i /mnt/$i ; done
Alternatively, mount them each separately rather than using the
for-loop:
-a-a-a-a mount --rbind /proc /mnt/proc
-a-a-a-a mount --rbind /sys /mnt/sys
-a-a-a-a mount --rbind /dev /mnt/dev
-a-a-a-a mount --rbind /run /mnt/run

Yes, that is very close to or is in fact the canonical procedure. The
chroot-artix command DOES footwork like the above for the user leaving
no steps to be missed in error.

Artix doesn't use systemD so could the chroot-ArtiX script be used as a
pre installed and available systemD service that could be started and
run? Something "dr.suse" could possibly handle even?

I've used that script once but never read it (above my pay grade). As
for systemd Suse is the last distro using it that I put up with.

Actually, chroot in such a form 'could'
really be just an argument for the CD command. When the path of the
mountable but unbootable "/" is let's say /dev/sda8 then it could go
like this

# cd --system /dev/sda8

end of story.

I'm not sure about this but I think that in a conventional chroot the
currently loaded kernel continues in use. Even this could be subject
of another argument

Can this cause problems (chrooting with currently loaded kernel), on
live loaded (rescue) media? Such as the chroot attempt failing or
whatnot? If that kernel version is different than the afflicted
filesystems kernel version?

I've only done chroot about 4 times in 30 years (which is why I never
remember all the required steps). As far as I know the loaded kernel
operats but what it operates ON is an unbooted system partition.

# cd --system --kernel /boot/vmlinuz /dev/sda8

or words to that effect. Not being familiar with grub2 at cLi level I
would, after a good chroot, just issue the call

yast

and set the boot up all over again in yast ncurses.

I don't think you need to "set the boot up all over again" after each chroot. I did not need to. Are you referring to modifying and updating
Grub?

Yast is the ONLY way that "I" know to set up grub2 (when they killed
grub legacy I decided I would never spend time learning it). At least
they should have kept a KISS and editable menu similar to what existed
before, that gave me all I needed but more I'm not interested in).

Ideally I would also be able to log in as user and just do

~ startx

Have you heard anything about "startx" to not be preferably used anymore
and defunk?

yes, too often, about DOS being dead also :-)

All the Live, Rescue and Installer DVD's should have such or similar
rescue features designed to operate in an existing but sick partition
including a 'dr.suse' command that just looks to find out what's wrong
with an intallation and proposes fixes it can execute.

What conditions cause this problem (chroot to be required)?

I must have gone throught at least a couple of dozen 'installations'
only because I could not salvage an existing and otherwise perfect and
tweaked system ...that just would not boot.

Do you know
why possibly the chroot was required on the machine here and not others
that used zypper dup at that time?

Same as above, zypper dup (on TW) CAN make a system unbootable,
sometimes does.

This is the openSUSE project managment page >
https://progress.opensuse.org/

"dr.suse" sounds like a good thought.

the race is ON :-) (but don't hold your breath)


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 8/15/24 21:30, panorain wrote:

On 08-14-2024 05:38PM, bad sector wrote:

On 8/14/24 14:43, panorain wrote:

On 07-25-2024 06:46PM, bad sector wrote:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and
you're working in the (artix) installation of choice. Pretty cool.

I would like to respond to your message because I recently had an
issue with the Tumbleweed machine here not booting after a 'zypper
dup'. The machine was halted at displayed 'GRUB _' prompt after
passing the LUKS passphrase. I was able to boot a live Tumbleweed
image into Rescue Mode and then perform the Chroot.
https://www.suse.com/support/kb/doc/?id=000018770

Notes taken:
Have a problem after 'zypper dup' , displays only GRUB _ after booting.

Suggested help link > https://www.suse.com/support/kb/doc/?id=000018770
-
Trying
-
1. First boot the system into Rescue Mode from the media. For best
results use media that matches the version and service pack of the
system.
-
2. Once it's finished loading, log in as root.
-
3. Mount the root partition or logical volume to /mnt
-a-a-a-a-a mount /dev/<device name> /mnt
I used > # mount /dev/mapper/system-root /mnt
If it's not known where the root file system is, it needs to be
guessed until found by mounting each possibility and checking its
contents. Run the following command to list all available partitions:

-a-a-a cat /proc/partitions

Display all available logical volums > lvdisplay
After mounting each one check its contents by listing the mounted
directory. For example if mounted to /mnt run: > ls /mnt
Some directories that should be listed to verify it is a root file
system are /root, /boot and /home.
4. Once mounted use the following for-loop to rbind the virtual file
systems: >
-a-a-a-a for i in proc sys dev run; do mount --rbind /$i /mnt/$i ; done
Alternatively, mount them each separately rather than using the
for-loop:
-a-a-a-a mount --rbind /proc /mnt/proc
-a-a-a-a mount --rbind /sys /mnt/sys
-a-a-a-a mount --rbind /dev /mnt/dev
-a-a-a-a mount --rbind /run /mnt/run

Yes, that is very close to or is in fact the canonical procedure. The
chroot-artix command DOES footwork like the above for the user leaving
no steps to be missed in error.

Artix doesn't use systemD so could the chroot-ArtiX script be used as a
pre installed and available systemD service that could be started and
run? Something "dr.suse" could possibly handle even?

I fear Dr.Suse has every one of his fingers up his bazooka as it is :-))

But I did attempt another chroot session to see if I could cheat that
utility into fixing my mess, It did,n work but I'll paste it here for
anyone who might be searching for chroot stuff (I actually logged in and operated the chrooted but unbooted partirtion, unfortunately one of my
alter users could NOT log in.

============================================

YASAUCHR
Yet another salvage attempt using chroot ========================================

Boot Tumbleweed DVD {openSUSE-Tumbleweed-DVD-x86_64-Snapshot20240827-Media.iso}

locks up with blueish dialog inherited from Slackware back in the day:
"Please make sure your installation medium is available. Choose the URL
to retry"

except for the "Boot Linux System" option which ends in a red flag
failure: "no bootable system found" {NB there are 8 bootable Linux
distros on disk 1, 1tb ssd}

"Boot from Hard Disk" {Slackware https://imgur.com/screenshot-ltu3Fxc}
#mount /dev/sda14 /mnt
#for i in proc sys dev run; do mount --rbind /$i /0/sa14/$i ; done
#chroot /mnt

#sddm
(NB lots of sddm-* installed but NO sddm proper, so I had installed it
during an update with the DVD iso file fed to Yast as a repo)

log-in as dummy user (created with every distro, home in parent partition)
set up USB WiFi.. OK
Start Yast to check nvidia/nouveau packages installed
...see images
https://paste.opensuse.org/pastes/b9471637194f https://paste.opensuse.org/pastes/387b0811e420


The booted Slackware install from where I chrooted (as all my other
distros) uses the 4tb data ssd to store data including some HOME folders
so kdiskfree SHOWS the data partition mounted but with NO content. I
mount it again and now kdiskfree shows content as well, verified in
dolphin. This step is important because I really want to log in as
UserMe and my home IS on that data drive in folder TW with a
/home/UserMe link pointing to it.

So since everything seems otherwise cool I log out and try to log in as UserMe: the log-in FAILS and sddm's login menu returns. I understand
that a chrooted system is NOT a booted system but am curious why this
login is failing.

Log back in as u0
# zypper dup
46 packages updated

Run Yast boot-loader withOUT graphic menu andf 40 second timeout
(existing menu was graphic and 99secs)

Reboot (noted 40 sec timout and no graphic menu) to see if the TW
install is bootable...

IT STILL ISN'T!!!!

Boot Devuan {https://paste.opensuse.org/pastes/d1932f34ea4d}
Mount TW partition
plymouth debug log:
https://paste.opensuse.org/pastes/0dc0d62a8ced

THAT's as far as I got.
The approximately 10th TW DVD is not bootable, the TW partition is still
not bootable.

============================================



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 7/28/24 17:20, bad sector wrote:

On 7/28/24 02:49, Dave Royal wrote:

bad sector <forgetski@_INVALID.net> Wrote in message:

On 7/26/24 02:49, Dave Royal wrote:

bad sector <forgetski@_INVALID.net> Wrote in message:

does this exist at all, like artix-chroot?

You just issue the command from an artix installer or rescue and
you're
working in the (artix) installation of choice. Pretty cool.

I don't know about artix, but I've used chroot a few times to
-a-a recover the boot files after I've screwed them up. Starting from
-a-a a rescue dvd or grub - I forget.

Yeh, you can do a chroot but if you don't do it often enough it's easy
to screw up. What the Artix devs wrote is a script that takes care of
the elbow grease. Say you nuke an Artix installation, boot any oyther
one including live or installer or rescue and do 'chroot-artix dev/sdx'
and you're in the toasted system ready to make repairs. Every installer, >>> live or rescue should have suh a utility.

My desktop is having issues and it's been all traced to a bad AMD video
card I had bought used not long ago. The card before that was nvidia
which I had promised myself never to buy again. So I've bought a new AMD >>> but am using the nvidia 'interim' waiting for delivery of the new card.
When I booted TW with the nvidia plugged in and there was no login,
would be nice to boot a live DVD and just install the nvidia drivers for >>> the time being.

Actually, TW should just load the drivers for the existing hardware and
get on with it. I think my Devuan installation did just that.

In Leap 15.6 - maybe also TW - nvidia (or SUSE - I don't know who
-a decided) have dropped the drivers (designated G04 = v390) for a
-a group of old cards from the non-free nvidia repo. I had to remove
-a the old G04 pkgs (from Leap 15.5) to it to work with the nouveau
-a driver. When I tried the G05 driver pkg it failed to start X.

I bought a more recent card (-u25 at CeX) expecting to have to
-a configure X to use the nvidia driver, but it did it
-a automatically. (Though I already had the G05 pkgs
-a installed.)

For my desktop it had been the g04 package

I believe for the GT640 it was the g05 package

but even when working and
downloadable it was *always* a pain in the ass! Slow speeds, interrupted downloads, you name it. So one day when it AGAIN became a royal PITA for
any number of by then familiar reasons I got just plain fed up and
swapped it out, still working, for a radeon. There is NO WAY that I will ever buy another nvidia anything. The replacement 16gb asus-rx-7600
should be here within days, I could struggle with chroot to temporarily backlevel to the nvidia but I will not.

--- Synchronet 3.21d-Linux NewsLink 1.2