|
I am familiar with mdadm tool (Linux /Ubuntu) and so far I cannot see how to SIMPLY accomplish the task.
Is there another tool I can use ?
|
|
|
|
|
What happens when you try the --remove option?
|
|
|
|
|
I hope this question belogs here.
I have asked this many times and still have no real answer.
In multiboot ( all Linux) system "grub" has an option to boot (automatically) last used OS.
When "grub" menu is displayed such " saved " OS is indicated by asterisk (*) as
first character on the line.
However, UEFI gets into the act and FIRST option in "grub" menu is an entry
"*Ubuntu"
and it is marked , incorrectly , as "last saved OS used".
Allegedly, UEFi "boot firmware " also monitors last SUCCESSFULLY used OS...
No matter how often I change "grub" options - and then update grub - the menu ALWAYS set the asterisk next to the "Ubuntu" label.
It only works when I install new , clean Ubuntu using ISO.
...and I do change the OS using other then "Ubuntu" option in "grub" menu...
|
|
|
|
|
I have done this successfully in the past using the edit feature on the grub menu. As far as I am aware UEFI only controls which device the system boots from.
|
|
|
|
|
It does not help me if it works for you.
I need somebody to tell me why it works the way it does on my hardware.
|
|
|
|
|
Member 14968771 wrote: I need somebody to tell me why it works the way it does on my hardware.
And how are we expected to do that, given we have no access to your system?
|
|
|
|
|
|
I did look at the link, it still does not help finding the relations between "hardware" - firmware setting when multiple OS is involved. I am including part of copy of the most recent OS upgrade
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.13.0-40-generic
Found initrd image: /boot/initrd.img-5.13.0-40-generic
Found linux image: /boot/vmlinuz-5.13.0-39-generic
Found initrd image: /boot/initrd.img-5.13.0-39-generic
Found linux image: /boot/vmlinuz-5.13.0-37-generic
Found initrd image: /boot/initrd.img-5.13.0-37-generic
Found Ubuntu 21.04 (21.04) on /dev/sda2
Found Ubuntu 21.10 (21.10) on /dev/sda4
Found Ubuntu 21.04 (21.04) on /dev/sda5
Found Ubuntu 21.10 (21.10) on /dev/sdb22
Found Ubuntu 21.04 (21.04) on /dev/sdb23
Found Ubuntu 21.04 (21.04) on /dev/sdb25
Found Ubuntu 21.04 (21.04) on /dev/sdb3
Found Ubuntu 21.04 (21.04) on /dev/sdb6
Found Ubuntu 21.10 (21.10) on /dev/sdc17
Found Ubuntu 20.10 (20.10) on /dev/sdc2
Found Ubuntu 21.04 (21.04) on /dev/sdc3
Found Ubuntu 20.10 (20.10) on /dev/sdc4
Found Ubuntu 21.10 (21.10) on /dev/sde10
Found Ubuntu 21.10 (21.10) on /dev/sde30
Adding boot menu entry for UEFI Firmware Settings
done
q5@q5-desktop:~$
The upgrade was performed on /dev/sde31 partition , I should be able to manually set the /dev/sde31 grub default file to activate "save last OS used " .
Most of these "upgrades " wipe out this settingn !
I have done that multiple times and it never works. The "grub menu" always select "ubuntu" and in general runs the first menu - such as /dev/sda2.
There are multiple "ubuntu" files in "setup" and I really do not know how to access these "ubuntu" files to determine which one is actually used. Since "ubuntu" selection in grub menu is BEFORE the system is active I cannot simply "cut and copy" the "grub menu" to post here . Anybody who uses multiple OS system (ubuntu) will be able to understand this . Since I have never run single OS my guess is "grub" menu should not show on such system...no need for multiple OS selection...
|
|
|
|
|
Sorry, I cannot offer any suggestions beyond what is in that link. But I am a little concerned as to all those different devices in use on your system. Maybe it's time for a complete reinstall from clean.
|
|
|
|
|
The problem is - as can be seen - I have done the clean install (of OS) many times and the "select last used OS" only works on clean ISO. I do not like new installs because I have to start all over to install all the "support" software I am using. I do manage to keep my software stuff most of the time...
I really need someone to tell me about these "ubuntu" files and how they fit into OS loading process. They seems to reside on different HDD and I do not know how "UEFI " setup manages them.
|
|
|
|
|
Sorry, I have use ubuntu in multi-boot situations a number of times and have never encountered anything like the situation you are showing. I can only suggest you find a specialist Linux support website where you may find someone with a deeper knowledge.
|
|
|
|
|
1. can hci_get_route return anything but 0 or -1 (error) ?
2. does hci_open_dev returns
"socket" or
"device descriptor" ?
3. as coded in an example
can hci_open_dev return 0?
device_id = hci_get_route(NULL);
if (device_id < 0) {
perror("hci_get_route");
return 0;
}
device_sock = hci_open_dev(device_id);
if (device_sock < 0) {
perror("hci_open_dev");
return 0;
}
|
|
|
|
|
|
I do not want to abuse my posting privileges here - but
I need another terminology answer
I use hcitool to "scan for nearby Bluetooth devices " .
In my logic - to physically scan remote devices a connection has to be made.
Now Bluetooth devices as such are also "paired " and or "connected ".
To apply my logic - right or wrong - before hcitool can "scan" should it "pair " AND then "connect " FIRST?
Yes , I need to look at the hcitool source code and hopefully it is commented enough to support my logic.
I actually was hoping to find somebody who uses hcitool option "cc" - connect , but I better heed my own suggestion and read the source code first...
cheers
:
|
|
|
|
|
That's easy enough to test. Turn on a bluetooth device. Do not pair or connect, and run a scan. I think you'll find that the scan reports the device presence.
My expectations are:
scan - find any nearby device with bluetooth receiver turned on - may or may not report devices that are paired to other servers and not soliciting for connection
pair - establish a connection to a scanned device that is soliciting for a connection
connected - a pairing has been established and the server can communicate with the device.
Keep Calm and Carry On
|
|
|
|
|
My primary reason for ditching "brand X " Bluetooth API was its lacking of resetting the discovered Bluetooth devices.
I am now using "hcitool scan flush " which does reset the data and then does
real scan.
The "hcitool" command responds with a message "Scanning" and takes up to 30 seconds to finish.
There is yet another issue here - sometime it gets stuck in "scanning" and only reasonable way to recover is to reboot the system...
( The API I am using monitors the scanning time and can be adjusted , I have not look into that , not yet. )
That is silly and unacceptable.
How safe or dangerous would it be to stop and restart the
Linux Bluetooth service itself ?
|
|
|
|
|
Why should that be dangerous? Windows updated here and there was a power failure.
(Do not turn of your machine?)
It just kept working.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
No, the system is still ruining OK so I just switch to "terminal " and run "sudo reboot" - a "short" version of plain reboot.
|
|
|
|
|
Member 14968771 wrote: How safe or dangerous would it be to stop and restart the
Linux Bluetooth service itself ?
It should not affect the running of the Linux system at all. It might leave any connected bluetooth devices "orphaned", I.E. with a connection that the kernel doesn't know about, but I really do not know. You almost certainly can't damage the linux system beyond needing a reboot to get back to where you were, so if I were you I'd try it and see what effect it has. In particular I'd look to see if currently connected devices keep working, and if the stuck process recovers quickly after the restart. I suspect that restarting the service won't affect the stuck hcitool process. It probably has all it needs to do its work, so restarting the bluetooth service won't affect it. You should probably take a look at what hcitool is doing when its stuck - it may be a bug in the process, which you could report to the developer, or it may be due to some bluetooth device not properly implementing the discovery protocols, which leads to problems, or, well, anything!
Keep Calm and Carry On
|
|
|
|
|
All sounds reasonably safe. I am sure you are correct - I should look into how hcitool scan is implemented.
This is something I will never understand - Bluetooth is "implemented " in Linux kernel.
It uses "blueZ" "stack"... "blueZ" source code is "available" in several versions and ALL of them are lacking code comments or function descriptions ... basically a code nobody maintains...
My Linux version runs a "bluetooth manager " and my QT implementation of "blueZ" library interact with this flaky manager - perhaps by using the Linux " blueZ stack "...
That is why I asked "Bluetooth service " ....
BTW
can you tell what the hell is "stack"?
I had some fun in haystack(s) in my youth...
|
|
|
|
|
A "stack" is the set of programs and/or system services needed to supply a given end-user (in this case) service.
As I understand it, for bluez there's
User programs : e.g. hcitool
System software : e.g. whatever system processes are needed to monitor/provide bluetooth services
System libraries : e.g. libbluetooth this provides interfaces for both system and user programs
Kernel module : e.g. bluetooth module, which provides the kernel side implementation details
As you can see, this forms a "stack", with each layer needing services from the layer below it to provide the services it needs to the layer above.
Keep Calm and Carry On
|
|
|
|
|
I am making sure this forum can accept / discuss and resolve "Bluetooth" as DEVICE.
With that let me make a statement:
For many reasons , irrelevant to the following post,
I do not fancy to utilizing "blueZ" library.
And please let us NOT discuss that.
i do prefer to use one of many open or hidden derivatives of "blueZ" library.
End of story.
I am pretty much done using "hcitool" .
Unfortunately "hcitool" has no easy or visible means to "pair" Bluetooth devices.
It looks as "bluetoothctl" can be used to pair.
HOWEVER -
hcitool and bluetoothctl DO NOT use same terminology describing Bluetooth processes.
device became controller
and who knows what is "agent" ?
q5@q5-desktop $ bluetoothctl
Agent registered
[CHG] Controller 00:15:83:15:A2:CB Pairable: yes
[CHG] Controller 00:50:B6:80:4D:5D Pairable: yes
So
the purpose of this post is :
I am open to reasonable suggestion using another - command based and NOT openly derived from "blueZ" tool.
Preferably "related" to C++ - no Python....
Cheers
|
|
|
|
|
Another OS management question.
My impression of RAID 5 is to prevent hardware AKA HDD failure.
The RAID is dynamically updated , hence any unwanted (file ) changes are faithfully replicated.
With that assumption - Would manual backup , not automatic as RAID does, be more productive>?
Then there are tools which can be optioned to do just backup - sort of semi-automatically.
|
|
|
|
|
Member 14968771 wrote: With that assumption - Would manual backup , not automatic as RAID does, be more productive>?
It takes time to restore a backup, and all of IT at the coffeemachine, waiting for you. That's expensive.
Member 14968771 wrote: Then there are tools which can be optioned to do just backup - sort of semi-automatically.
RAID isn't a form of backup. It's redunancy. And drive may fail, and no user notices. No need to talk backups.
Mine is based on Linux and cheap pendrives. I never backup.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
RAID does not replace the need for a backup.
RAID5 is protects against a SINGLE drive failure. If a second drive fails while a previous drive is still failed or is in the process of rebuilding after replacement, you will lose data.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
