Re: Fixing a Grub Foul-up
Dan Ritter writes:
> Here's what you can do:
>
> On a good system, mount your drive. Let's pretend that it's
> recognized as /dev/sdg, and you have a /boot on /dev/sdg1 and
> a root partition on /dev/sdg2.
>
> ls -al /dev/disk/by-partuuid/| grep sdg
>
> will get you the partition UUIDs for that disk. One of them will
> be for /dev/sdg1 and another for /dev/sdg2.
>
> The kernel really likes these as root filesystems identifiers.
> The kernel parameter that you put in /etc/default/grub is
>
> ROOT=PARTUUID=dddf0dd6-dd6b-d542-9eac-015a765cd6f6
>
> although you will want to substitute in the appropriate
> part-uuid for /dev/sdg2.
>
> Finally, you can run
>
> grub-install /dev/sdg
>
> to get a new copy of grub into the master boot sector of the
> disk.
>
> Hope that helps,
It certainly does!
First, thanks to all who answered so far. I think you have
perfectly described what is causing the problem although grub is
not high in my knowledge base like it probably should be.
When I read /boot/grub/grub.cfg, I see
references to a uuid that isn't any of the partitions that have
UUID's. On my disk, Partition 1 is / and blkid spits out a
number that starts with 9F. Partition 2 was created to get an
extended partition of 5 which is swap space so 1 and 5 have
UUID's. The UUID referenced in grub.cfg starts with 3.
The rest of this message consists
of grub.cfg.
Martin
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
serial --speed=115200 --unit=1 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
play 480 440 1
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-3584c851-6616-464f-8a8e-2d634fca5969' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1
3584c851-6616-464f-8a8e-2d634fca5969
else
search --no-floppy --fs-uuid --set=root
3584c851-6616-464f-8a8e-2d634fca5969
fi
echo'Loading Linux 4.19.0-5-686-pae ...'
linux /boot/vmlinuz-4.19.0-5-686-pae
root=UUID=3584c851-6616-464f-8a8e-2d634fca5969 ro console=tty0
console=ttyS0,115200n8 quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.19.0-5-686-pae
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-3584c851-6616-464f-8a8e-2d634fca5969' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-5-686-pae' --class
debian --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-4.19.0-5-686-pae-advanced-3584c851-6616-464f-8a8e-2d634fca5969' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio;
fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1
3584c851-6616-464f-8a8e-2d634fca5969
e
Re: Fixing a Grub Foul-up
On Mon, Nov 16, 2020, 2:32 PM John Boxall wrote: > You might be running in to the problem that the blkid that is expected > may be changed during boot. As I am running into a similar problem on a > system I upgraded to buster from stretch, this link might help: > > > https://www.thegeekdiary.com/inconsistent-device-names-across-reboot-cause-mount-failure-or-incorrect-mount-in-linux/ I encountered something like this, when installing Stretch (when it was current) onto a USB Stick on a Dell laptop. I was installing to the USB Stick to leave alone the Windows 7 Home installation in the Hard Drive. It didn't come with a DVD Drive, so I used an external USB DVD Drive for the Install. So, during Install, the Hard Drive was /dev/sda, the DVD Drive was /dev/sdb and the USB Disk with Stretch was /dev/sdc. On the Reboot, I, of course removed the USB cable for the DVD Drive and got dumped into the Grub Rescue mode, where it was looking for Stretch on /dev/sdc but it was now on /dev/sdb! My final solution was to backup, and then blow away Windows 7 and Install Buster on the Hard Drive. (Yes, it took long enough for Buster to become the Stable Build). The Geek Diary wasn't available to me when I encountered this issue. Thanks for the link! Kenneth Parker > > > On 2020-11-16 1:48 p.m., Martin McCormick wrote: > > I have goofed, I think. There is a serca-2000-vintage Dell > > Optiplex that has been working fine up to yesterday when I did > > the usual apt-get update followed by the apt-get upgrade on > > buster. The update and upgrade appeared to work. > > > > One of the things that got visited was grub and it was > > then that I was reminded that there was another drive in the > > system that had a bootable image of buster on it also. Grub > > reported seeing it on /dev/sdc which is coorrect. > > > > This particular system has a zip drive that always shows > > up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc. > > > > I rebooted to make sure all was well and waited and > > waited . . . > > > > The system sits there like a bump on a log. > > > > I have a usb device that lets one mount IDE and SATA > > drives that are outside the system so I pulled the sata drive > > which is the boot drive for the now dead system and plugged it in > > to the usb converter. > > > > the drive breezes through fsck and looks perfectly > > normal. > > > > I looked at /boot/grub/grub.cfg which one is not supposed > > to edit as grub builds it based on /etc/default/grub which one > > does edit. > > > > If I was to mount that partition on a working system, it, > > of course, will have a different device number such as /dev/sde1 > > instead of /dev/sda1 which it should have when booting up the > > system it normally runs in. > > > > Is there a safe way to mount this drive, possibly using > > chroot, re-run grub-config and get the drive bootable again? > > > > If I look at grub.cfg and /etc/default/grub, everything > > looks as if it should work but it doesn't. > > > > I think boot problems are some of the most agrevating > > issues. They are true show stoppers. > > > > I've got backups but that's beside the point. Unless I > > can fix whatever happened, it's going to be quite a time waster. > > > > Thanks for any constructive suggestions. > > > > Martin McCormick > > > -- > Regards, > > John Boxall > >
Re: Most maintainable way to install perl modules on Debian sysetms
I would not be surprised if the version number indicated the module in not Pure Perl, but rather includes some C source code. Which would then need to be compiled specifically for the version of Perl installed. mrc
Re: Fixing a Grub Foul-up
On Tue, 17 Nov 2020 at 05:58, Martin McCormick wrote: > If I look at grub.cfg and /etc/default/grub, everything > looks as if it should work but it doesn't. > Is there a safe way to mount this drive, possibly using > chroot, re-run grub-config and get the drive bootable again? Yes, recovering grub is a routine operation, but you have to get all the details correct. > I've got backups but that's beside the point. If you can easily access your backup of grub.cfg, try restoring it to the problem drive and see if it works. If that doesn't work, I suggest to post the grub.cfg that used to work here, together with the output of 'lsblk -f' when all the drives that you need to create a restoration setup are active. That will help us guide you with much less guesswork.
Re: Fixing a Grub Foul-up
Martin McCormick wrote: > I have a usb device that lets one mount IDE and SATA > drives that are outside the system so I pulled the sata drive > which is the boot drive for the now dead system and plugged it in > to the usb converter. > > the drive breezes through fsck and looks perfectly > normal. > > I looked at /boot/grub/grub.cfg which one is not supposed > to edit as grub builds it based on /etc/default/grub which one > does edit. > > If I was to mount that partition on a working system, it, > of course, will have a different device number such as /dev/sde1 > instead of /dev/sda1 which it should have when booting up the > system it normally runs in. > > Is there a safe way to mount this drive, possibly using > chroot, re-run grub-config and get the drive bootable again? Here's what you can do: On a good system, mount your drive. Let's pretend that it's recognized as /dev/sdg, and you have a /boot on /dev/sdg1 and a root partition on /dev/sdg2. ls -al /dev/disk/by-partuuid/| grep sdg will get you the partition UUIDs for that disk. One of them will be for /dev/sdg1 and another for /dev/sdg2. The kernel really likes these as root filesystems identifiers. The kernel parameter that you put in /etc/default/grub is ROOT=PARTUUID=dddf0dd6-dd6b-d542-9eac-015a765cd6f6 although you will want to substitute in the appropriate part-uuid for /dev/sdg2. Finally, you can run grub-install /dev/sdg to get a new copy of grub into the master boot sector of the disk. Hope that helps, -dsr-
Re: Fixing a Grub Foul-up
You might be running in to the problem that the blkid that is expected may be changed during boot. As I am running into a similar problem on a system I upgraded to buster from stretch, this link might help: https://www.thegeekdiary.com/inconsistent-device-names-across-reboot-cause-mount-failure-or-incorrect-mount-in-linux/ On 2020-11-16 1:48 p.m., Martin McCormick wrote: I have goofed, I think. There is a serca-2000-vintage Dell Optiplex that has been working fine up to yesterday when I did the usual apt-get update followed by the apt-get upgrade on buster. The update and upgrade appeared to work. One of the things that got visited was grub and it was then that I was reminded that there was another drive in the system that had a bootable image of buster on it also. Grub reported seeing it on /dev/sdc which is coorrect. This particular system has a zip drive that always shows up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc. I rebooted to make sure all was well and waited and waited . . . The system sits there like a bump on a log. I have a usb device that lets one mount IDE and SATA drives that are outside the system so I pulled the sata drive which is the boot drive for the now dead system and plugged it in to the usb converter. the drive breezes through fsck and looks perfectly normal. I looked at /boot/grub/grub.cfg which one is not supposed to edit as grub builds it based on /etc/default/grub which one does edit. If I was to mount that partition on a working system, it, of course, will have a different device number such as /dev/sde1 instead of /dev/sda1 which it should have when booting up the system it normally runs in. Is there a safe way to mount this drive, possibly using chroot, re-run grub-config and get the drive bootable again? If I look at grub.cfg and /etc/default/grub, everything looks as if it should work but it doesn't. I think boot problems are some of the most agrevating issues. They are true show stoppers. I've got backups but that's beside the point. Unless I can fix whatever happened, it's going to be quite a time waster. Thanks for any constructive suggestions. Martin McCormick -- Regards, John Boxall
Fixing a Grub Foul-up
I have goofed, I think. There is a serca-2000-vintage Dell Optiplex that has been working fine up to yesterday when I did the usual apt-get update followed by the apt-get upgrade on buster. The update and upgrade appeared to work. One of the things that got visited was grub and it was then that I was reminded that there was another drive in the system that had a bootable image of buster on it also. Grub reported seeing it on /dev/sdc which is coorrect. This particular system has a zip drive that always shows up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc. I rebooted to make sure all was well and waited and waited . . . The system sits there like a bump on a log. I have a usb device that lets one mount IDE and SATA drives that are outside the system so I pulled the sata drive which is the boot drive for the now dead system and plugged it in to the usb converter. the drive breezes through fsck and looks perfectly normal. I looked at /boot/grub/grub.cfg which one is not supposed to edit as grub builds it based on /etc/default/grub which one does edit. If I was to mount that partition on a working system, it, of course, will have a different device number such as /dev/sde1 instead of /dev/sda1 which it should have when booting up the system it normally runs in. Is there a safe way to mount this drive, possibly using chroot, re-run grub-config and get the drive bootable again? If I look at grub.cfg and /etc/default/grub, everything looks as if it should work but it doesn't. I think boot problems are some of the most agrevating issues. They are true show stoppers. I've got backups but that's beside the point. Unless I can fix whatever happened, it's going to be quite a time waster. Thanks for any constructive suggestions. Martin McCormick
Re: Connecting a base system via WiFi.
On Du, 15 nov 20, 07:10:36, pe...@easthope.ca wrote: > On Mi, 04 nov 20, 21:45:16, pe...@easthope.ca wrote: > > According to packages.debian.org/buster/all/net, iw is not > > available in the suite. > > From: Andrei POPESCU > Date: Thu, 5 Nov 2020 12:31:25 +0200 > > Where did you find that path? > > > > Or did you mean https://packages.debian.org/buster/net/ > > (the trailing '/' matters)? > > In Debian 10, open Firefox and open http://www.google.ca/. If you are > not in CA (Canada; not California), there's a good chance the browser > will be redirected to the google address for another country; > google.us for example. If that prevents you from reproducing the > search you might resort to some proxy method. That's beyond my > knowledge. > > Search for this string. > > site:packages.debian.org buster iw > > In the returned list, click on the first link. WIth a little luck, > this URL will appear. > > https://packages.debian.org/buster/net I was asking about the /buster/all/net path though (note the 'all' in the middle). It matters only if you got it from some other Debian resource (web page, wiki, etc.) as it would need to be fixed. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How to manage audio volume unattended.
On 2020-11-15, Juan R. de Silva wrote: > >> Normalize the volume of the mp3 files beforehand rather than adjusting >> the volume of the player in real time for each individual file (e.g. >> with an app like python-rgain)? >> >> Or does this not speak to the reason for the volume changes? > > Unfortunately, it does not in this particular case. However, I might find > suggested useful in other cases anyway. Have you tried pactl 'set-sink-volume @DEFAULT_SINK@ +5'? Or is that not useful? > Thanks.
