मुझे कैसे पता चलेगा कि मैंने किस विभाजन से बूट किया था?


12

मेरे पास एक मशीन है जिसमें बहु-बूट विभाजन हैं। मेरे एक भाग पर Ubuntu 14.04, दूसरे पर Ubuntu 15.04 और तीसरे पर Ubuntu 16.04 है। क्या यह जानने का कोई तरीका है कि कमांड लाइन से, मैंने किस विभाजन से बूट किया था, ताकि आपको यह पता चल सके कि किस विभाजन का /boot/grub/grub.cfgउपयोग बूट प्रक्रिया के लिए किया गया था? मेरे पास /boot/grub/grub.cfg प्रत्येक तीन विभाजन हैं।


3
आप पूरी तरह से सामान्यता और विश्वसनीयता के साथ ऐसा नहीं कर सकते। जो आप जानते हैं, /boot/grub/grub.cfgबूटिंग के लिए उपयोग की गई फ़ाइल को हटाया जा सकता था, उस विभाजन को विभाजन तालिका से हटाया जा सकता था, और उस डिस्क को सिस्टम से भौतिक रूप से हटा दिया गया था।
फेडेरिको पोलोनी

जवाबों:


10

एक बार जब GRUB ने कर्नेल को बूट करना बंद कर दिया है, तो कर्नेल को पता नहीं है कि इसे किसने शुरू किया है, और /bootशायद वह नहीं है जो GRUB उपयोग करता है। आप boot/grub/grub.cfgइनमें से प्रत्येक विभाजन में पहुंच के समय को देख सकते हैं कि कौन सा सबसे हाल ही में एक्सेस किया गया था। यह आपको बता सकता है कि किस विभाजन की कॉन्फ़िगरेशन फ़ाइल GRUB का उपयोग किया गया है।

stat -c %x /boot/grub/grub.cfg

यदि एक्सेस समय अपडेट नहीं किया जाता है, तो आपको विभिन्न GRUB कॉन्फ़िगरेशन फ़ाइलों द्वारा उपयोग किए जाने वाले कर्नेल मापदंडों में कोई अंतर देखना होगा। यदि आप उन्हें बदल सकते हैं, उदाहरण के लिए, जोड़ें foo=1, foo=2आदि, GRUB_CMDLINE_LINUXइनमें से प्रत्येक में, चलाएं sudo update-grub2और रिबूट करें, तो आप यह देखने के /proc/cmdlineलिए जांच कर सकते हैं कि इनमें से कौन से मूल्यों का उपयोग किया गया था।


दिलचस्प! इसका मतलब यह है कि मेरे समाधान में एक बेहतर सटीकता दर है फिर रवेक्सिना और केतु की?
Tatsu

@tatsu IMO अन्य सभी उत्तर गलत हैं - रेवेक्सिना उस विभाजन का पता लगा रहा है जहां /bootस्थित है, लेकिन यह नहीं हो सकता है कि क्या ग्रब का उपयोग किया गया है, और आप और काटू को पता चल रहा है कि विभाजन चालू /है, लेकिन, जैसा कि रवेक्सिना ने कहा है, शायद यहां तक कि एक कनेक्शन के कम
muru

1
हां, लेकिन आपके द्वारा माउंट किए गए विभाजन पर असफल होने के अलावा अन्य कुछ भी कैसे संभव हो सकता है: डिस्क डिवाइस पर चढ़े हुए उपकरण के रूप में ऐसी जानकारी वितरित करता है, किसी भी आईडी की जानकारी जो आपको संभवतः उसी की आवश्यकता हो सकती है, जिसे आपने अनमाउंट करने का प्रयास किया था। मैं पहला उपाय स्वीकार कर रहा हूं कि मेरा समाधान बदसूरत है, लेकिन इसमें 100% सफलता दर सही है?
टेटू

1
@tatsu सफलता दर क्या है? विभाजन का पता लगाना /, निश्चित है। बूट करते समय किस विभाजन के GRUB विन्यास का उपयोग किया गया था? मैं नहीं देखता कि यह कैसे संबंधित है।
मूरू

4
क्या ग्रब वास्तव में उस टाइमस्टैम्प का उपयोग करता है, जो कि उसका अपना डॉस है और लिनक्स फाइलसिस्टम चालक सम्मेलनों से बाध्य नहीं है?
रैकैंडबनमैन

4

जैसा कि आप जानते हैं कि आप जिस फ़ाइल की तलाश कर रहे हैं /bootवह आपके रनिंग सिस्टम की निर्देशिका में स्थित है। या तो /bootएक अलग विभाजन है या यह नहीं है; यदि आपका /bootएक अलग विभाजन है, तो आपको उसके लिए देखना चाहिए:

$ lsblk -r | grep '/boot'
sda2 8:1 0 400M 0 part /boot

grub.cfgजिन साधनों का उपयोग किया गया है, वे स्थित हैं sda2

आप के लिए दिखना चाहिए root:

$ lsblk -r | grep '/$'
sda1 8:1 0 121.2G 0 part /

इस समय यह अंदर स्थित है sda1

या यहां तक ​​कि मनोरंजन के लिए हम बूट समय मापदंडों की जांच कर सकते हैं:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae root=UUID=938495-1fe2-3302 ro quiet

फिर UUIDयह पता लगाने के लिए उपयोग करें कि कौन सा विभाजन आपकी जड़ है।

$ sudo blkid | grep 938495-1fe2-3302
/dev/sda1: UUID="938495-1fe2-3302"

कौन से साधन sda1

आप इन बूट मापदंडों को देखने के लिए भी देख सकते हैं कि आपकी कौन सी grub.cfgफाइल में वे हैं, यह केवल तभी काम करता है जब आपके बूट पैरामीटर grub.cfgएक दूसरे से भिन्न हों।


2
फ़ाइल सिस्टम UUID के पीछे डिवाइस नोड को खोजने के लिए एक आसान तरीका (सुपर-उपयोगकर्ता विशेषाधिकारों की आवश्यकता नहीं है) होगा readlink -f /dev/disk/by-uuid/<UUID>
डेविड फ़ॉस्टर

3

वर्तमान में माउंट किए गए रूट फ़ाइल सिस्टम को पकड़े हुए डिवाइस को प्रदर्शित करने के लिए:

awk '$2=="/"{print $1}' /proc/mounts

वर्तमान में चल रहे Ubuntu रिलीज़ संस्करण को प्रदर्शित करने के लिए:

lsb_release -rs

यह वास्तव में सवाल के संबंध में बहुत कुछ बताता है और लगता है कि अभी तक का सबसे उपयुक्त उत्तर है। मुझे यकीन है कि उसके सेटअप पर कोई दो डिस्ट्रो नहीं दिया गया है, एक ही वर्जन नंबर है जिसे वह lsb_release -rsहर बार इस्तेमाल करेगा । KISS
Tatsu

दुर्भाग्य से यह काम नहीं करता है। मैंने आपके मशीन पर कई OS के साथ अपने कमांड का परीक्षण किया, केवल मेरे "मास्टर-ओएस ने एमबीआर में ग्रब स्थापित किया है, अन्य ओएस के ग्रब को पीबीआर में स्थापित किया गया है, कमांड उस स्थान को दिखाती है जहां ओएस ने ग्रब स्थापित किया है, लेकिन ऐसा नहीं करता है शो जिसमें से OS Grub config-file को लोड करता है।
mook765

@ mook765: मेरे जवाब का ग्रब या एमबीआर (या किसी भी बूट लोडर या विभाजन तालिका प्रकार वास्तव में) से कोई लेना-देना नहीं है। मुझे यकीन नहीं है कि आपने वास्तव में क्या कोशिश की और आपको क्या देखने की उम्मीद थी।
डेविड फ़ॉस्टर

तब इस जवाब का सवाल से कोई लेना-देना नहीं है ...
mook765

@ mook765: यदि आप इसे सचमुच लेते हैं, तो हाँ। हालांकि मेरे लिए यह प्रतीत होता है कि ओपी यह जानना चाहता है कि वर्तमान में उसकी कई उबटन स्थापना में से कौन सा बूट किया गया है और इसके लिए मेरा उत्तर ठीक होना चाहिए।
डेविड फ़ॉस्टर

2

हम प्रत्येक OS में एक साधारण कस्टम मेनू प्रविष्टि जोड़ सकते हैं और हम ग्रब-मेनू में देखेंगे जिसमें से OS Grub ने इसे कॉन्फ़िगरेशन-फ़ाइल लोड किया है।

उदाहरण:

हम 16.04 में बूट करते हैं और /etc/grub.d/40_customमेनू-एंट्री को जोड़ने के लिए फाइल को एडिट करते हैं ।

#! / Bin / श
निष्पादित पूंछ -n +3 $ 0
# यह फ़ाइल कस्टम मेनू प्रविष्टियों को जोड़ने का एक आसान तरीका प्रदान करती है। बस टाइप करें
# मेनू प्रविष्टियाँ जिसे आप इस टिप्पणी के बाद जोड़ना चाहते हैं। बदलने के लिए नहीं सावधान रहें
# ऊपर 'निष्पादित पूंछ' लाइन।
#

मेनेंट्री 'grub.conf 16.04' से लोड        
            रिबूट  
    }

हम यह सुनिश्चित करते हैं कि फ़ाइल निष्पादन योग्य हो और चले sudo update-grub

फिर हम अन्य ओएस में भी वही बदलाव करते हैं, हम सिर्फ मेन्यूएंट्री के लिए अलग-अलग नामों का उपयोग करते हैं, ig हम 16.04इसे 15.04और इतने पर बदलते हैं ।

यदि हम बूट के दौरान ग्रब-मेनू में इस मेनू-प्रविष्टि का चयन करते हैं, तो मशीन सिर्फ रिबूट होगी, हमने उन्हें किसी भी ओएस को बूट करने के लिए नहीं बनाया है, बल्कि यह देखने के लिए कि वास्तव में किस ओएस को लोड करने के लिए उपयोग किया जाता है grub.conf

अतिरिक्त जानकारी

इस तरह का भ्रम तब प्रकट होता है, जब हम कई ओएस स्थापित करते हैं, जो सभी ग्रब का उपयोग करते हैं और ओएस की स्थापना के दौरान हम एक ही बूट-लोडिंग स्थान चुनते हैं। हमें वास्तव में केवल एक ओएस की आवश्यकता है जो ग्रब स्थापित करता है, ग्रब किसी भी लिनक्स वितरण में बूट कर सकता है, इसलिए यदि हमारे पास एक वितरण स्थापित है (ग्रब सहित), तो हम ग्रब स्थापित किए बिना अतिरिक्त ओएस स्थापित कर सकते हैं।

विरासत-संस्थापन में बूट-लोडर इंस्टॉलेशन के लिए स्थान को संभालना बहुत आसान है, क्योंकि हम विभाजन-बूट-रिकॉर्ड को स्थान के रूप में चुन सकते हैं, लेकिन हमें सही विभाजन चुनने के लिए ध्यान रखना होगा। तो एक OS बूट-लोडर को MBR और अतिरिक्त OS के बूट-लोडर को OS-विभाजन के PBR में स्थापित करता है। यह संभावना हमारे पास केवल तभी होती है जब हम Something elseइंस्टॉल के दौरान -ओपशन का उपयोग करते हैं ।

UEFI- इंस्टॉल में यह थोड़ा अधिक अजीब है, बूट लोडर को EFI सिस्टम पार्टीशन (ESP) में एक फ़ोल्डर में स्थापित किया जाएगा और कई बूट-लोडर आसानी से सहवास कर सकते हैं। यहाँ समस्या यह है कि सभी Ubuntu-flavors और कुछ अन्य लिनक्स-वितरण भी ESP में एक ही फ़ोल्डर में ग्रब स्थापित करेंगे और हमारे पास कोई विकल्प नहीं है। इसलिए एक अतिरिक्त लिनक्स-वितरण स्थापित करने से हमारे पहले से मौजूद बूट-लोडर को अधिलेखित कर दिया जाएगा। इससे बचने का एकमात्र तरीका मुझे लाइव सत्र में बूट करना और इंस्टॉलर को शुरू करना है sudo ubiquity -b

एक और सरल उपाय

आइए मान लें कि हमारे पास विभाजन पर तीन लिनक्स वितरण स्थापित हैं sda1, sda2और sda3। अब हम ग्रब के बूट मेनू प्रविष्टियों पर एक नज़र डालते हैं। बूट के दौरान, हम कुछ इस तरह देखेंगे:

1 उबंटू
2 उबंटू के लिए उन्नत विकल्प
3 मेमोरी टेस्ट (memtest86 +)
4 मेमोरी टेस्ट (मेमेस्टी86 +, सीरियल कंसोल 115200)
5 उबंटू (पर / देव / sda2)
Ubuntu के लिए 6 उन्नत विकल्प (/ देव / sda2 पर)
7 उबंटू 17.04 (पर / देव / sda3)
Ubuntu के लिए 8 उन्नत विकल्प (पर / देव / sda3)

पहले दो प्रविष्टियां OS के लिए प्रविष्टियां हैं, जो कि grub.confवास्तव में हम उपयोग करते हैं। फिलहाल # 3 और # 4 प्रविष्टियां दिलचस्प नहीं हैं। प्रविष्टियाँ # 5, # 6, # 7 और # 8 प्रविष्टियाँ हैं जो OS-prober के साथ जनरेट की गई थीं और हम देखते हैं कि इन प्रविष्टियों के लिए OS के किस विभाजन पर रहते हैं। तो इस छोटे उदाहरण के मामले में हम यह निष्कर्ष निकाल सकते हैं कि grub.config-file का हम वास्तव में उपयोग करते हैं जो OS पर sda2या sda3OS पर नहीं है sda1। मामले में एक या एक से अधिक ओएस एक अलग-अलग- /bootइंस्टालेशन के साथ स्थापित होते हैं, हमें यह देखना होगा कि कौन- /bootसे-किस ओएस से संबंधित है, लेकिन यह आसानी से findmntप्रत्येक ओएस में -command चलाकर किया जाता है ।


+1 लंबा होने के बावजूद, इस जवाब में वास्तव में प्रासंगिक बिंदु शामिल हैं। BIOS सिस्टम के लिए, जो उपयोगकर्ता मल्टी-बूट करते हैं, उन्हें अधिक नियंत्रण रखने के लिए इंस्टॉलर में "कुछ और" पसंद करना चाहिए; "GRUB बूट लोडर को स्थापित नहीं करने के लिए" बाध्य करने की कोई आवश्यकता नहीं है ( मेरा पुराना उत्तर देखें )। यूईएफआई प्रणालियों के लिए, बहु-बूट सेटअप बहुत अस्पष्टीकृत या अप्रकाशित लगता है।
क्लीमकमुरा

1
lsblk

और यह जांचें कि डिस्क किसमें आरोहित है /। यदि /bootआपके आरोहित बिंदु हैं तो कृपया नीचे दिए गए या रवेक्सिना के उत्तर पढ़ें ।

यदि आप निश्चित नहीं हैं, तो UUID की जाँच करें

lsblk -o UUID,NAME,SIZE,MOUNTPOINT

2
यह सच नहीं है, क्या होगा अगर मेरा /bootएक अलग विभाजन है? तब विभाजन /boot/grub/grub.cfgमें स्थित नहीं है /
रवेक्सिना

@ रेवेक्सिना तकनीकी हो, यह सच हो सकता है। हालाँकि, इस उपयोगकर्ता के प्रयोजनों के लिए, /विभाजन की गणना नहीं है?

@MarkYisri मुझे लगता है कि मुझे कहना चाहिए कि यह हमेशा सच नहीं है, हालांकि ओपी हमें बता रहा है कि उसे तीन अलग-अलग विभाजन पर फ़ाइल मिली है, इसलिए मुझे लगता है कि /bootपहले एक अलग के लिए जांच करना बेहतर है ।
रवेक्सिना

1
यह इंगित करने के लिए धन्यवाद कि @Ravexina मैंने उत्तर को अपडेट कर दिया है।
काटू

0

यह जानने के लिए कि उपयोगकर्ता ने किस विभाजन को बूट किया था, किसी भी संस्थापित सिस्टम को बूट करने से पहले बूट लोडर मेनू को देखें । बूट लोडर मेनू को देखे बिना बताना मुश्किल है।

जहां देखो

निम्नलिखित संयुक्त स्क्रीनशॉट में, मैंने तीन संकेत दिए हैं जो किसी को पता हो सकता है कि उपयोगकर्ता ने किस विभाजन से बूट किया था।

बहु बूट मेनू एनोटेशन के साथ GNU GRUB PC / BIOS संस्करण का उपयोग करते हुए

लेबल (1): GNU GRUB मेनू प्रविष्टियाँ पहली प्रविष्टि के नीचे

लेबल (2): बूट लोडर मेनू के शीर्ष पर GNU GRUB संस्करण

लेबल (3): GNU GRUB पृष्ठभूमि छवि (मैनुअल सेटअप आवश्यक)

सबसे स्पष्ट संकेत लेबल (3) है, जो बूट लोड मेनू के नियंत्रण वाले सिस्टम पर GNU GRUB पृष्ठभूमि छवि को बदलना है। यह बताना सबसे आसान है, बशर्ते उपयोगकर्ता इसे पहले से सेट कर लें।

लेबल (1) समझाया गया

पहली प्रविष्टि के नीचे मेनू प्रविष्टियों में सूचीबद्ध नहीं हुए विभाजन को देखें। स्क्रीनशॉट में, केवल दो ऑपरेटिंग सिस्टम स्थापित किए जा रहे हैं अर्थात "Ubuntu" और "Ubuntu 14.04.5 LTS"।

Ubuntu
Advanced options for Ubuntu
Memory test (memtest86+)
Memory test (memtest86+, serial console 115200)
Ubuntu 14.04.5 LTS (14.04) (on /dev/sda3)
Advanced options for Ubuntu 14.04.5 LTS (14.04) (on /dev/sda3)

उत्तरार्द्ध ने उल्लेख किया है (on /dev/sda3), जिसका अर्थ है कि पूर्व /dev/sda2या पर स्थित हो सकता है /dev/sda1। यह सुनिश्चित करने के लिए कि सिस्टम "उबंटू" को बूट करने के बाद, उपलब्ध विभाजनों को सूचीबद्ध करने के लिए प्रासंगिक कमांड चलाएं ( lsblkसबसे सीधा प्रतीत होता है)।

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0    13G  0 disk 
├─sda1   8:1    0   976M  0 part [SWAP]
├─sda2   8:2    0     6G  0 part /
└─sda3   8:3    0     6G  0 part 
sr0     11:0    1  55.7M  0 rom 

के आउटपुट की तुलना करने के बाद ही lsblk, हम जानते हैं कि सिस्टम "Ubuntu" में पाया जाता है /dev/sda2(जो मेनू प्रविष्टियों में सूचीबद्ध नहीं था ) जिसमें से बूट लोडर मेनू प्रबंधित किया जाता है।

लेबल (2) समझाया गया

GRUB संस्करण देखें जो बूट लोडर मेनू के शीर्ष पर मुद्रित है। उस संस्करण पर ध्यान दें और GRUB संस्करण की तुलना करें जो बूट सिस्टम "उबंटू" पर पाया जाता है।

स्क्रीनशॉट में (नीचे आधा): GNU GRUB version 2.02~beta2-9

सिस्टम "उबंटू" बूट करने के बाद, GRUB पैकेज के संस्करण ( grub-install --versionप्रासंगिक और सबसे सीधा है) की जांच करने के लिए प्रासंगिक कमांड चलाएं ।

$ grub-install --version
grub-install (GRUB) 2.02~beta2-9

यह कैसे प्रासंगिक है? क्योंकि grub-installऔर update-grubकमांड दोनों एक ही पैकेज द्वारा प्रदान किए जाते हैं grub2-common। यह देखते हुए कि बूट लोडर मेनू एक ही पैकेज से टूल का उपयोग करके बनाया और अपडेट किया गया है, बूट लोडर मेनू के शीर्ष पर मुद्रित संस्करण समान होगा।

लेबल (3) समझाया गया

इस संकेत को मैन्युअल रूप से सेट करने की आवश्यकता है, क्योंकि बूट लोडर मेनू की डिफ़ॉल्ट पृष्ठभूमि छवि कोई भी नहीं है (सिर्फ सादा काला)। पृष्ठभूमि की छवि 8-बिट गहराई होनी चाहिए।

यदि desktop-baseपैकेज आपके सिस्टम पर स्थापित है, तो ऐसी पृष्ठभूमि छवियां जो विशेष रूप से GRUB के लिए बनाई गई हैं *grub.png, लक्ष्य निर्देशिका में फ़ाइल नाम प्रत्यय के साथ आसानी से मिल जाती हैं ।

$ ls /usr/share/images/desktop-base/*grub.png
/usr/share/images/desktop-base/desktop-grub.png
/usr/share/images/desktop-base/joy-grub.png
/usr/share/images/desktop-base/moreblue-orbit-grub.png
/usr/share/images/desktop-base/spacefun-grub.png

पृष्ठभूमि छवि सेट करने के लिए:

  1. /etc/default/grubसुपरयूज़र के रूप में फ़ाइल खोलें , फिर GRUB_BACKGROUND=पसंद की छवि के लिए पूर्ण पथ के साथ लाइन जोड़ें और उद्धृत करें।

    $ sudo nano /etc/default/grub 
    ...
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
    GRUB_CMDLINE_LINUX=""
    
    # Show background in GRUB boot menu
    GRUB_BACKGROUND="/usr/share/images/desktop-base/spacefun-grub.png"
    ...
    
  2. फिर, sudo update-grubअद्यतन करने के लिए चलाएँ /boot/grub/grub.cfgजिसमें बूट लोडर मेनू शामिल है। उपयोगकर्ता निम्न के समान आउटपुट देखेंगे।

    $ sudo update-grub
    Generating grub configuration file ...
    Found background: /usr/share/images/desktop-base/spacefun-grub.png
    Found background image: /usr/share/images/desktop-base/spacefun-grub.png
    Found linux image: /boot/vmlinuz-3.13.0-24-generic
    Found initrd image: /boot/initrd.img-3.13.0-24-generic
    Found memtest86+ image: /boot/memtest86+.elf
    Found memtest86+ image: /boot/memtest86+.bin
    Found Ubuntu 14.04.5 LTS (14.04) on /dev/sda3
    done
    
  3. मशीन को रिबूट करें और देखें कि क्या बूट लोडर मेनू में सिस्टम से अपडेट कमांड द्वारा किए गए कोई दृश्य परिवर्तन थे।

अन्य, अन्य प्रणालियों के लिए चरणों को दोहराएं, एक समय में एक। दोहराए गए कदम अनावश्यक थे, क्या उपयोगकर्ता को पता होना चाहिए कि बूट लोडर मेनू पर किस सिस्टम का नियंत्रण था (फिर, यह इस बात पर निर्भर करता है कि स्थापना कैसे की गई थी)।

अस्वीकरण

यह उत्तर GNU GRUB PC / BIOS संस्करण का उपयोग करके मल्टी बूट सेटअप के साथ BIOS सिस्टम के लिए सिद्ध और अच्छी तरह से परीक्षण किए गए मानदंड के लिए बताता है। निम्नलिखित अपवाद लागू होंगे।

  • UEFI प्रणाली जीएनयू GRUB EFI संस्करण का उपयोग कर के अपने समकक्ष के लिए, यह है नहीं गारंटी या नहीं जाना जाता है, तो मापदंड के रूप में ऊपर वर्णित एक ही प्रतीत होता।

  • बूट लोडर मेनू के लुक पर जोर दिया जाता है (यह अलग-अलग यानी स्क्रीनशॉट के शीर्ष आधे भाग में कैसे दिखाई दे सकता है) यह दिखाने के बजाय कि चेनलोडिंग कैसे काम करता है। इस प्रकार, "कैसे बहु बूट को स्क्रीनशॉट में देखा गया था" के बारे में इस उत्तर में नहीं समझाया जाएगा।

  • यदि मल्टी बूट सेटअप कभी भी समान ऑपरेटिंग सिस्टम यानी उबंटू 14.04, कुबंटु 14.04, जुबांटु 14.04, आदि की बिल्कुल समान प्रतियों से बना है, तो यह जानने का एकमात्र विश्वसनीय तरीका है कि उपयोगकर्ता ने किस विभाजन से बूट किया था लेबल (3)।

  • लेबल (3) कस्टम बैकग्राउंड इमेज का उपयोग करके बेहतर तरीके से काम कर सकता है जो स्पष्ट रूप से लिखता है कि यह बूट किया गया है "" यह बूट मेनू / dev / sda1 से प्रबंधित है "। इसी तरह, "GRUB के लिए कस्टम बैकग्राउंड इमेज कैसे बनाएं" के बारे में इस उत्तर में नहीं बताया जाएगा।

TL; DR किसी भी संस्थापित सिस्टम को बूट करने से पहले बूट लोडर मेनू को देखें । पता करने का सबसे आसान और विश्वसनीय तरीका लेबल (3) है, जो मैन्युअल रूप से GRUB पृष्ठभूमि छवि सेट करना है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.